approche de correctif pour le site asp.net

Question

Je travaille sur un nouveau projet qui est en .net 3.5.

Actuellement, le client utilise des procédures stockées et nous aimerions vraiment utiliser LINQ to SQL à la place. La principale raison pour laquelle ils utilisent proc stocké est parce qu'ils croient qu'ils sont plus faciles à mettre à jour et tels, ils n'utilisent pas d'autorisations spéciales ou telles que je peux voir justifier l'utilisation de procédures stockées sur LINQ à SQL, mais ils ne veulent pas changer. Je pense que si je peux leur présenter une solution par laquelle ils peuvent facilement déployer des changements à la LINQ to SQL, ils pourraient être plus ouverts à changer d'avis. En tant que tel, je suis curieux avec un projet asp.net (pas mvc) comment faire pour mettre à jour les différents assemblages qui sont créés pendant le processus de construction.

Supposons par exemple que tout mon code LINQ se trouve dans un projet System.DataAccess et qu'il soit déployé en production, un bogue prod est ensuite identifié avec le LINQ. Il est difficile de simplement déployer le projet DataAccess modifié (ou plutôt tout projet ayant subi des modifications importantes depuis le déploiement de l'outil). Une chose que je ne suis pas sûr que cela aidera la situation est que chaque fois qu'il y a une construction, le numéro de build est mis à jour sur tous les projets, qu'il y ait eu des changements ou non, juste en regardant le numéro de version des projets ne suffirait pas à déterminer les projets à redéployer.

Je ne suis même pas sûr s'il est possible de modifier une build pour que seuls les projets modifiés aient leur version mise à jour? Donc, fondamentalement, je suis juste curieux de connaître les différents processus de correction et les avantages et les inconvénients (c'est-à-dire qui nécessite une réinitialisation, etc.).

Salutations

Answer 1

Il ya des avantages et des inconvénients pour les deux.

Les process stockés SQL sont rapides et efficaces. Vous pouvez faire des opérations SQL lourdes avec un proc stocké qui s'exécutera bien plus vite que tout ce que vous pouvez faire dans le code, mais c'est une autre couche.

LINQ ne nécessite pas autant de travaux de maintenance en cas de modification. C'est facile à coder.

Vous n'avez pas besoin de réinitialiser IIS du tout pour une méthode. Il est recommandé de mettre à jour vos versions de fichier d'assemblage pour chaque version, uniquement si vous modifiez le code de cet assembly. Mise à niveau des versions juste parce que sera désordonné et pas nécessaire.

La réparation est facile avec les deux. Je trouve LINQ plus facile à mon humble avis. Si une structure de table change, je n'ai pas besoin de modifier les procédures stockées et les fonctions qui utilisent ces procédures stockées. C'est un script de changement rapide, votre DBML devrait déjà être mis à jour parce que vous avez testé avec la nouvelle version, alors c'est un déploiement.

J'ai toujours mes classes de données LINQ et partielles dans le même assemblage, donc c'est une version DDL facile.

Answer 2

Les procédures stockées SQL et LINQ-SQL ne s'excluent pas mutuellement.

Généralement pour les opérations complexes, gourmandes et intensives en ressources, vous utilisez toujours les procédures stockées SQL (par exemple, une opération INSERT reposant sur des sous-requêtes complexes/logique db) et les faites glisser vers le canevas LINQ-SQL.En termes de correctifs - vous pouvez certainement patcher ces procédures stockées directement dans SQL Server, et les classes LINQ-SQL n'ont pas besoin d'être recompilées - tant que la signature ne change pas (params/type de retour).

En termes de mise à jour des numéros de version de certains assemblages - pas idéal. Obtient très salissant, peut même causer des problèmes (nom fort).

Vous devez placer toutes vos opérations DB/LINQ/CRUD dans un ensemble (DAL).

Si vous voulez vraiment isoler la logique LINQ et activer le déploiement indépendant de ces assemblages, vous devriez peut-être envisager de partitionner votre solution en serveurs web/app? Vous avez votre assemblage LINQ DAL et un assemblage semblable à une façade qui expose ces opérations sur un serveur d'application, puis votre site Web sur un serveur Web distinct. En fonction de votre architecture, vous pouvez utiliser ASMX/WCF/.NET Remoting pour faciliter les appels entre les serveurs Web/App. (WCF ne fonctionne pas cross-domaine). Cela dit, si vous avez bien fait vos classes LINQ-SQL (bon mélange d'opérations LINQ CRUD, de vues, de procédures stockées), vous pouvez toujours facilement patcher les procédures stockées sans affecter votre application.