Meilleures pratiques: architecture à 3 niveaux dans LINQ

Question

Je travaille sur un projet personnel (C # / ASP.NET) qui utilisera LINQ to SQL. La solution aura (jusqu'à présent) un projet Webform, un projet Namespace (logique métier) et un projet Tests. Je suis encore dans les toutes premières étapes (clairement en phase de conception).

Y at-il un paradigme pour l’architecture à 3 niveaux ici? Il semble que le DAL soit totalement inutile dans ce cas; pense que je devrais exécuter la requête LINQ directement à partir de la logique métier.

Il me semble également que si je ne conservais qu'un seul résident DataContext et que je le transmettais, il me suffirait d'une connexion ouverte. Cela aurait l’avantage supplémentaire d’engager des modifications en une fois et non de manière granulaire. Des idées à ce sujet?

J'ai trouvé ce fil , mais il semble peindre une image incomplète. Existe-t-il des articles de fond sur le sujet?

Answer 1

Vous pouvez considérer LINQ-to-SQL comme votre DAL, utilisez-le donc & "directement à partir de la logique applicative &"; n'est pas nécessairement une mauvaise chose.

http://dotnetlog.com/archive/2008/03/18/best-practice-and-effective-way-of-using-datacontext-in-linq.aspx a présenté quelques approches populaires de L2S. .

Dans notre projet, nous ne voulions pas contourner le contexte de données, nous avons donc utilisé un modèle similaire au n ° 3 du lien ci-dessus (Ambient DataContext, voir ci-dessous). Il y avait quelques problèmes, mais cela a fonctionné assez bien; au moins pour notre projet web.

  

Ambient DataContext (utilisant actuellement cette fonctionnalité)

     

L’idée de ambient datacontext est que le contexte soit créé pour un thread particulier ou un httpcontext (en asp.net) dès qu’il y a un premier appel pour le DataContext. Ensuite, le même contexte est utilisé pour ce thread ou cette demande, à moins qu'il ne soit supprimé manuellement. Pour ce faire, stockez le contexte dans le magasin de données de requête / thread. L'approche de ce modèle est similaire à celle de DataContext statique, toutefois, une séparation est fournie pour chaque thread et chaque demande. Cela fonctionne très bien dans Asp.Net, cependant, est à nouveau affecté par certains problèmes de contexte statique.

     

Problèmes avec ce modèle:

* The context is available for manipulation at any level. And quickly becomes very hard to maintain unit of work
* Portability across thread is very hard
* Unit of work pattern is not transparent enough

Answer 2

Vous pouvez en savoir plus sur la conception pilotée par le domaine.

Avec la pratique du DDD (Domain Driven Design), vous disposez d’un riche "modèle de domaine", dans lequel vous exprimez le domaine du problème que vous souhaitez aborder. Ce modèle de domaine est constitué de classes (et de structures) avec lesquelles vous modélisez vos entités métier. Le modèle de domaine comprend également des référentiels.
Un référentiel est une sorte d'abstraction que vous utilisez dans votre modèle de domaine (et dans votre application). Le référentiel est une abstraction de votre magasin de données. À travers le référentiel, vous pouvez récupérer des entités et vous pouvez utiliser le référentiel pour conserver des entités.

Dans votre cas, vos référentiels pourraient utiliser Linq To SQL en interne pour communiquer avec la base de données. Notez cependant que votre référentiel ne devrait pas être responsable de la gestion (ouverture / fermeture) de la connexion et de la transaction (démarrage / validation / restauration). Pourquoi ? - > parce que le référentiel n'a aucune connaissance ou notion du contexte dans lequel il est utilisé. C'est votre couche d'application ou de service (la couche qui utilise votre modèle de domaine et donc votre référentiel) qui devrait être responsable de l'ouverture d'une nouvelle connexion et du démarrage / de la validation des transactions. (Ou dans votre cas, ouvrez un nouveau DataContext). Vous pouvez ensuite transmettre le DataContext au référentiel.

(Eric Evans a de temps en temps un excellent livre sur la DDD, bien que difficile à casser).

Answer 3

Vous devez faire attention à votre terminologie. Quand vous dites LINQ, vous voulez dire Linq-to-sql et quand vous dites 3 tiers, cela signifie généralement que vous parlez d'un scénario de déploiement avec 3 machines distinctes. Je ne sais pas si c'est ce que vous voulez dire.

Une architecture à trois couches est toujours une bonne idée lorsque vous utilisez un outil ORM tel que linq-to-sql. Le DAL devient juste un endroit pour stocker votre logique de requête. C’est une bonne idée de supprimer vos requêtes de votre couche métier, car elles posent un problème de persistance et non de logique logicielle.

La technique habituelle de gestion du contexte de données consiste à avoir un seul contexte de données par requête.

Pour ce qui est des autres articles sur le sujet, vous pouvez consulter n’importe quel guide d’architecture pour n’importe quel outil ORM - linq-to-sql n’est pas différent. Recherchez des articles sur l'architecture pour NHibernate.

Answer 4

La bibliothèque LINQ to SQL est votre DAL dans ce cas. Au lieu de passer des appels d'API traditionnels à partir de votre couche métier (par exemple, DAL.GetObjectById (id)), vous avez la possibilité de faire des requêtes beaucoup plus expressives dans le DAL.

Si vous aviez d'autres besoins, par exemple votre propre fournisseur LINQ qui se connecte à un support de données non-MSSQL, vous devez alors implémenter votre propre DAL.

De plus, en ce qui concerne le DataContext, il n'est pas recommandé d'utiliser un modèle de singleton avec & "un résident DataContext &"; Un objet DataContext doit représenter une transaction logique unique, quelle que soit sa signification pour votre application. (Paraphrased from http://weblogs.asp.net/despos/archive/2008/03/19/more-on-datacontext-in-hopefully-a-rrealistic-world.aspx )