Communication entre BLL et DAL

Configuration de la solution:

  • DAL (bibliothèque de classe)
  • BLL (bibliothèque de classes)
  • Common (bibliothèque de classes (certaines fonctionnalités communes – énumérations, journalisation, exceptions, …))
  • Application1 (application Windows)
  • Application2 (application Windows)
  • WebApp (application Web)

Disons que j’ai une entité client , qui est:

  • une table dans le serveur SQL
  • un CustomerDataTable dans DAL
  • une classe de clients dans BLL
  • une classe BLL.Customer dans toutes les applications

Quels types d’objects doivent être utilisés par BLL et DAL pour la communication – DataTable ou List (par exemple)? Dans le premier cas, la logique BLL doit transformer l’object client en DataTable et l’envoyer à DAL. Dans certains cas, la couche DAL doit connaître la classe client, qui se trouve dans la couche BLL. Mais les DLL d’origine font référence à DAL et non l’inverse …

Devrais-je placer toutes les classes dans une assemblée séparée, référencée par toutes les autres (Common, BusinessObjects, …)? Dans ce cas, je pourrais utiliser la classe Client dans tous mes projets.

Dois-je même prendre la peine de séparer DAL et BLL quand je sais que seul un BLL utilisera mon DAL. Dans ce cas, je pourrais les fusionner en un seul projet.

PS – Je lis au sujet de DataTables et beaucoup de gens disent que nous ne devrions pas les utiliser du tout. Quelles sont les meilleures options? Peut-être qu’il est temps pour moi d’apprendre quelques outils de cartographie ORM 🙂

À mon avis, vous devriez avoir une autre couche (dll séparée). Comme “domaine”, où garderiez-vous toutes les entités comme Client? Ensuite, incluez simplement tous les niveaux supérieurs (DAL, BLL, UI et autres) dans la hiérarchie de cet assemblage.

L’échantillon d’architecture peut ressembler à ceci:

(Base de données) <-> DAL <-> BL <-> UI

et à tous les niveaux, vous aurez access à la couche “domaine”. DAL doit renvoyer List pas un DataTable. À certaines étapes de votre processus de développement, vous voudrez peut-être utiliser dans DAL des OMR comme NHibernate avec également une liste, probablement.

Il est difficile de répondre à cette question générale sans connaître suffisamment le domaine d’application. Je commencerais par réfléchir aux domaines où les changements futurs sont les plus probables et d’essayer de déterminer à partir de là où la flexibilité est requirejse.

mes pensées suivantes ne sont qu’une suggestion. n’hésitez pas à les prendre en compte et à modifier / ignorer ce que vous estimez être hors de propos.

séparer le DAL du BLL est presque toujours une bonne idée. le schéma de données est une chose qui doit être encapsulée et cachée du rest de l’application, laissez donc vos DataTables, DataSets, ORM ou toute autre solution cachés dans le DAL. le BLL (et les couches au-dessus) doit utiliser des types de données simples (signifiant des classes simples). Je pense que ce serait une bonne idée de placer ces classes dans une bibliothèque de classes Model qui ne contient aucune référence et peut être utilisée partout.

il semble que vous ayez un peu trop de superposition … avez-vous vraiment besoin d’une classe Client dans la bibliothèque de bande de crédit et d’une autre dans la couche application? pourrait être, mais je voudrais m’assurer et y réfléchir à deux fois.

Fort de mon expérience dans l’un de mes projets récents (site Web météorologique comptant 200 000 visiteurs uniques par jour), nous avons utilisé link2sql pour l’access aux données (principalement des données en lecture seule) et des classes de données simples dans l’ensemble de notre application ASP.Net MVC (bien sûr, partie des modèles / voir les modèles). cela fonctionnait assez bien et nous pouvions facilement changer le schéma de données sans décomposer les autres couches.

Quant à votre dernière question à propos de DataTables, ces objects, si vous décidez de les utiliser (je voterais contre), appartiennent uniquement à votre DAL. ils ne doivent pas être exposés à d’autres couches car cela créerait un couplage avec cette classe spécifique. Et si demain MS inventait une bien meilleure classe? basculeriez-vous maintenant que vous avez un million de références dans vos projets vers les DataTables, leur méthode et leurs propriétés? serait plus agréable de changer votre DAL pour qu’il fonctionne avec la classe NewAwsomeDataTable et le rest de votre application est parfaitement ignorant.

J’espère que ça a aidé 🙂

J’utiliserais le modèle suivant, car il vous permet de mettre à niveau ultérieurement une stratégie de persistance différente.

 UI/Consumer <--- (view models) --> BLL <--- Models ----> DAL/Persistence 

Ici, les modèles View sont consommés en dehors de la BLL et les modèles sont communiqués aux couches BLL / DAL.

Dans votre cas, le modèle peut être tout ce que le DAL utilise – DataTables par exemple ou ultérieurement, peut-être des entités ORM. Le BLL est responsable de la correspondance entre le modèle et le modèle de vue.

Pour ce qui est de conserver les types dans leurs propres assemblages – oui pour les modèles de vue et pour maintenir une cohérence, oui pour les modèles également.

Le fait de conserver les modèles et d’afficher les modèles séparément permet d’éviter toute fuite des stratégies de persistance en dehors de la règle de niveau de solvabilité et permet ainsi des modifications de conception futures de la persistance.

L’un des avantages de cette séparation est que différents consommateurs de modèles de vue peuvent avoir différents modèles de vue pour le même modèle / entité de persistance. Certaines pourraient être petites et avoir peu d’atsortingbuts, d’autres grandes et riches en fonctionnalités. Il vous permet également d’introduire une fonctionnalité hors connexion / déconnectée, car les modèles de vue peuvent être renvoyés à des moments différents, ce qui vous permet de choisir des stratégies de fusion de données. Cela vous permet également de conserver des entités de persistance (par exemple, les tables grandissent et changent de forme). Comme cela ressemble à une implémentation .net, des fonctionnalités telles qu’AutoMapper fourniront de nombreuses fonctionnalités prêtes à l’ emploi.

Bien sûr, cela peut être excessif pour votre application – mais je maintiendrais tout de même un mappage BLL qui parle uniquement des modèles avec tous les consommateurs BLL. Cela devrait vous donner suffisamment de découplage.

Pousser les entités du domaine dans la dal est une option qui supprimerait la dépendance circulaire, mais pourrait ne pas correspondre à votre intention. Ce n’est pas inouï, cependant; Par exemple, les entités générées LINQ-to-SQL résident dans le DAL.

Autres options:

  • mettez-les dans un assemblage inférieur commun (mais cela peut laisser votre BL plutôt vide)
  • utiliser IOC pour supprimer / inverser la référence entre BL / DAL

Il n’y a pas de bonne réponse ici.

Re DataTable; Personnellement, je suis d’accord – je ne suis pas un fan;) Cependant, ils peuvent être utilisés avec succès et de manière raisonnable. Mais si je devais les utiliser, je les conserverais dans le DAL en tant que détail de la mise en œuvre, sans les exposer plus haut.