Quelle stratégie d'accès aux données pour une grande application

Question

Je suis sur le point de réécrire une application VB6 dans .NET 3.5sp1. L'application VB6 est assez bien écrite et la couche de données est entièrement basée sur des procédures stockées. J'aimerais utiliser quelque chose d'automatisé tel que Linq2SQL / Entity Framework / NHibernate / SubSonic. Certes, je n'ai utilisé aucun de ces outils dans d'autres projets que des projets à jeter.

Le problème potentiel que je crains d’avoir avec tous ces choix est la rapidité. Par exemple, pour récupérer une seule ligne (ou la liste complète), j’utilise le sproc suivant:

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 Linq2SQL / Entity Framework / NHibernate / SubSonic, ces solutions devront-elles afficher la liste complète sur le client et trouver la ligne dont j'ai besoin?

Alors, quel est le consensus pour la stratégie d'accès aux données pour une application avec un grand domaine de données?

Answer 1

Je vais me faire l'avocat du diable et vous recommander au moins d'envisager de vous en tenir aux procédures stockées. Celles-ci représentent un bloc de code que vous n'avez pas à réécrire ni à déboguer. Cet article de notre très propre [tm] Joel Spolsky donne un argument cohérent pour en évitant les ré-écritures complètes.

Avec un projet "greenfield", vous pouvez utiliser ce que vous voulez, et un mappeur O / R pourrait bien être un bon choix. Cependant, vous avez déjà indiqué que l'application VB6 était bien écrite. Si les sprocs sont bien écrits, vous obtenez une partie de votre application gratuitement et elle est déjà déboguée. Vous devez également recycler le schéma de la base de données et éviter ainsi la plupart des problèmes liés à la migration des données.

Les Schémas de l’architecture d’applications d’entreprise de Fowler devraient vous donner de bons indicateurs concevoir une couche d’accès aux données qui fonctionnera bien avec les procédures stockées sans causer de problèmes de maintenance.

Cela se fait assez souvent sur les applications Oracle / Java. De nombreuses applications Oracle héritées ont des corps volumineux de code de procédure stockée en PL / SQL - il s’agissait d’une architecture standard à l’époque des systèmes client-serveur d’Oracle Forms. Il est courant d'écrire un wrapper pour les sprocs en Java et de construire l'interface utilisateur par-dessus le wrapper.

Une des autres affiches a mentionné que Subsonic peut générer des wrappers pour les sprocs.

Jadis, j’ai eu l’occasion de faire un hack du dictionnaire de données qui générait un wrapper Java / JDBC de validation de principe pour les sprocs PL / SQL - IIRC n’a pris qu’une journée environ. Étant donné que ce n'est pas si difficile à faire, je serais surpris de constater qu'il n'y a pas beaucoup de choix en ce qui concerne les solutions que vous pouvez obtenir pour cela. À la rigueur, l'écriture de la vôtre n'est pas si difficile non plus.

Answer 2

Je ne peux pas parler de Linq-to-SQL, d'Entity Framework ni de NHibernate, mais je suis amoureux de SubSonic. Mon expérience avec elle a été extrêmement positive.

La façon dont ces outils fonctionnent en général est qu’ils construisent pour vous des requêtes paramétrées dans du code managé, encapsulent cet accès dans des classes, puis exposent ces classes à vos applications. Les DAL entièrement générés basculent.

En utilisant les requêtes paramétrées, vous craignez peut-être qu'elles "devront afficher toute la liste vers le client et trouver la ligne dont j'ai besoin". est gérée. Ils prennent en charge les clauses où 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 étant dit, SubSonic - lorsqu'il est utilisé tel quel pour un accès direct à une table / à une vue - supprime des lignes entières, ce qui pourrait être un inconvénient dans certains scénarios. Cependant, votre accès via des procs stockés 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 en tant que méthodes, et renvoyer les DataTable appropriés, que vous pouvez ensuite analyser manuellement si nécessaire. Il existe également des méthodes pour initialiser les listes de classes DAL à partir de procs. Ainsi, si la procédure retourne un jeu de données correspondant directement à une table / vue, vous pouvez toujours utiliser la syntaxe de nettoyage sans traitement manuel.

(SubSonic, en passant, m'a guéri de "procs pour tout". Maintenant, en général, je ne passe presque pas de temps à faire les procs CRUD comme je le faisais dans le passé, et je ne finis par les utiliser que pour des rapports compliqués. Cependant, votre kilométrage peut varier, voire changera.)

Answer 3

Je recommanderais d'utiliser SubSonic pour générer tout le code permettant d'accéder à vos procédures stockées existantes, afin de réduire les risques de régression en raison d'une nouvelle couche d'accès aux données. Toutes les nouvelles fonctionnalités sont ensuite accessibles via les classes ActiveRecord générées par SubSonic. Cela me semble être l’approche la plus sûre et la plus rapide,

Je ne suis pas d'accord avec la recommandation NHibernate car elle n'est pas vraiment adaptée au travail avec des procédures stockées.

Answer 4

Nous avons essayé d'utiliser le cadre d'entité en tant qu'entreprise et nous avons rencontré de nombreux problèmes lorsque nous avons essayé de l'utiliser avec le développement dirigé par le domaine. Je crois que Linq to Sql a aussi quelques limitations et Microsoft va cesser de le supporter dans la prochaine version.

Answer 5

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

Dupliquer ce type d’efficacité et d’expressivité, avec précision , avec une couche d’abstraction de type ORM, constituerait un défi, surtout si vous n’êtes pas totalement familiarisé avec les outils.

Vous pouvez toujours refactoriser les requêtes après avoir récupéré le reste de l'application. Et le monde de l'ORM évolue suffisamment rapidement pour que les options soient certainement différentes lorsque vous y arriverez.

Answer 6

SubSonic, même selon Rob Connery, l’un des auteurs, écrit davantage pour prendre en charge le développement rapide d’applications et moins pour les applications volumineuses. Je dirais que vous allez chez NHibernate car vous y trouverez le plus de soutien de la part de la communauté et un framework éprouvé et éprouvé. Vous pouvez obtenir de bonnes informations sur www.dimecasts.net sur la configuration de vos outils NHibernate.