Stratégie d'accès aux données pour une application volumineuse

Question

Je suis sur le point d'entreprendre une réécriture d'une application VB6 dans .NET 3.5sp1. L'application VB6 est plutôt bien écrite et la couche de données est entièrement basée sur les procédures stockées. Je voudrais aller avec quelque chose d'automatisé comme Linq2SQL/Entity Framework/NHibernate/SubSonic. Certes, je n'ai utilisé aucun de ces outils dans autre chose que des projets jetables.

Le problème potentiel que je crains d'avoir avec tous ces choix est la vitesse. Par exemple, en ce moment pour récupérer une seule ligne (ou la liste entière), j'utiliser la procédure stockée suivante:

ALTER PROCEDURE [dbo].[lst_Customers] 
@intID  INT = NULL 
,@chvName VARCHAR(100) = NULL 
AS 

SELECT Customer_id, Name 
FROM dbo.Customer 
WHERE (@intID IS NULL OR @intID = Customer_id) 
AND (@chvName IS NULL OR Name like ('%' + @chvName + '%')) 
ORDER BY name 

Pour récupérer une seule ligne dans le Cadre Linq2SQL/Entité/NHibernate/subsonique, ce que ces solutions doivent apporter la liste entière au client et trouver la rangée dont j'ai besoin? Alors, quel est le consensus sur la stratégie d'accès aux données pour une application avec un grand domaine de données?

Answer 1

Je vais jouer à l'avocat du diable et je vous recommande au moins de vous en tenir aux procédures stockées. Ceux-ci représentent un morceau de code que vous n'avez pas à réécrire et déboguer. This article de notre très propre [tm] Joel Spolsky donne un argument cohérent pour éviter les réécritures complètes. Étant donné un projet 'greenfield', vous pouvez utiliser ce que vous voulez, et un mapper O/R pourrait bien être un bon choix. Cependant, vous avez déjà déclaré que l'application VB6 est bien écrite. Si les sprocs sont bien écrits, alors vous obtenez gratuitement une partie de votre application et elle est déjà déboguée. De plus, vous récupérez le schéma de la base de données et évitez la plupart des problèmes liés à la migration des données.

Le Patterns of Enterprise Application Architecture de Fowler devrait vous donner quelques bons conseils pour concevoir une couche d'accès aux données qui jouera bien avec les procédures stockées sans causer de problèmes de maintenance.

Ceci est fait assez couramment sur les applications Oracle/Java. De nombreuses applications Oracle héritées disposent d'un grand nombre de codes de procédure stockée dans PL/SQL. Il s'agissait d'une architecture standard dans les versions client-serveur d'Oracle Forms. Il est courant d'écrire un wrapper pour les sprocs en Java et de construire l'interface utilisateur sur le wrapper.

L'une des autres affiches mentionnait que Subsonic pouvait générer des enveloppes pour les sprocs.

Il était une fois j'ai eu l'occasion de faire un hack de dictionnaire de données qui a généré un wrapper Java/JDBC preuve de concept pour les sprocs PL/SQL - IIRC a pris seulement un jour. Étant donné que ce n'est pas si difficile à faire, je serais surpris de constater qu'il n'y a pas beaucoup de choix dans ce genre de choses. À la rigueur, écrire le vôtre n'est pas si difficile non plus.

Answer 2

Je ne peux pas parler sur Linq-to-SQL, Entity Framework, ni NHibernate, mais je suis amoureux de SubSonic. Mon expérience avec elle a été extrêmement positive. En général, ces outils fonctionnent de la manière suivante: ils génèrent des requêtes paramétrées pour vous dans le code managé, encapsulent cet accès dans les classes, puis les exposent à vos applications. DALs entièrement généré. En utilisant les requêtes paramétrées, vous craignez de devoir "apporter la liste complète au client et trouver la ligne dont j'ai besoin". Ils prennent en charge les clauses where et d'autres filtres pour obtenir uniquement les lignes dont vous avez besoin. Vous pouvez faire l'équivalent de select * from foo, mais vous n'êtes pas bloqué dans ce mode. Cela dit, SubSonic - lorsqu'il est utilisé hors de la boîte pour un accès direct table/vue - réduit les lignes entières, ce qui pourrait être un inconvénient dans certains scénarios. Cependant, votre accès via procs stocké n'est pas un problème - je ne peux pas parler aux autres, mais SubSonic crée utilement une classe SPs encapsulant tous vos procs, vous permettant de les appeler comme méthodes, et renvoyant le DataTable s, qui vous pouvez ensuite analyser manuellement si nécessaire. Il existe également des moyens d'initialiser des listes de classes DAL à partir de procs, donc si la proc retourne un ensemble de données qui correspond directement à une table/vue, vous pouvez toujours avoir la syntaxe du nettoyeur sans traitement manuel. (SubSonic, en passant, m'a guéri de "procs pour tout." Je maintenant, en général, passons presque pas de temps à faire des procédures CRUD comme je l'ai fait dans le passé, et finis par les utiliser pour des rapports compliqués. votre kilométrage peut varier, et en fait, varier.)

Answer 3

SubSonic, même selon Rob Connery, l'un des auteurs, est écrit plus pour soutenir le développement rapide d'applications et moins sur les grandes applications. Je dirais aller avec NHibernate que vous trouverez le plus de soutien de la communauté ainsi que le cadre testé et éprouvé. Vous pouvez obtenir de bonnes informations de www.dimecasts.net sur la configuration de vos trucs NHibernate.

Answer 4

Je vous recommande d'utiliser SubSonic pour générer tout le code pour accéder à vos procédures stockées existantes, de cette façon vous réduisez les chances de régression en raison d'une nouvelle couche d'accès aux données. Toutes les nouvelles fonctionnalités peuvent ensuite être accédées en utilisant les classes ActiveRecord générées par SubSonic. Cela me semble être l'approche la plus sûre et la plus rapide pour procéder,

Je ne suis pas d'accord avec la recommandation de NHibernate parce que ce n'est pas vraiment approprié pour travailler avec des procédures stockées.

Answer 5

Nous avons essayé d'utiliser le framework d'entité comme un orm et avons rencontré plusieurs problèmes lors de l'utilisation de Domain Driven Development. Linq to Sql a également quelques limitations et Microsoft va arrêter de le soutenir dans la prochaine version, je crois.

Answer 6

Si les requêtes sont dans des procédures stockées, il y a de bonnes chances qu'elles aient déjà été bien optimisées. Et probablement qu'ils utilisent libérale des expressions SQL pour les jointures, les sous-requêtes, etc.

Dupliquer ce genre d'efficacité et d'expressivité, avec précision, avec une couche d'abstraction de type ORM que je pense être un défi - surtout si vous n'êtes pas totalement familier avec les outils.

Vous pouvez toujours refactoriser les requêtes après avoir obtenu le reste de l'application directement. Et le monde de l'ORM évolue assez vite pour que les options soient différentes lorsque vous y arrivez.