La communication entre BLL et DAL

Question

Configuration Solution:

• DAL (bibliothèque de classes)
• BLL (bibliothèque de classes)
• commune (bibliothèque de classes (certaines fonctionnalités communes - énumérations, exploitation forestière, des exceptions, ...))
• Application1 (application Windows)
• Application2 (application Windows)
• WebApp (application Web)
• ...

Disons que j'ai un Client entité, qui est:

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

Quel genre d'objets devraient utiliser BLL et DAL pour la communication - DataTable ou List<Customer> (par exemple)? En premier cas, la logique BLL doit transformer l'objet client à DataTable et l'envoyer à DAL. En cas secod, la couche DAL doit être au courant de la classe à la clientèle, qui est dans la couche BLL. Mais les références DLL Originaly DAL et non en face ...

Dois-je mettre toutes les classes dans l'assemblage séparé, qui est référencé par tous les autres (Common, BusinessObjects, ...)? Dans ce cas, je pourrais utiliser la classe client dans tous mes projets.

Devrais-je pris la peine de DAL et séparé BLL quand je sais que seul BLL utilisera mon DAL. Dans ce cas, je pourrais les fusionner en un seul projet.

PS - Je lis à propos 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:)

Answer 1

À mon avis, vous devriez avoir une autre couche (séparée dll). Comme « domaine », où iriez-vous garder toutes les entités comme client. Ensuite, il suffit d'inclure dans tous les niveaux plus élevés (DAL, BLL, interface utilisateur et d'autres) dans la hiérarchie de cette assemblée.

L'architecture échantillon peut ressembler à ceci:

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

et à tous les niveaux, vous aurez accès à la couche « domaine ». DAL doit retourner Liste non un DataTable. Sur un certain stade de votre processus de développement, vous voudrez peut-être utiliser dans DAL certains comme NHibernate avec OMR redonnerait aussi une liste, probablement.

Answer 2

il est difficile de répondre à cette question générale sans connaître le domaine d'application assez bien. Je voudrais commencer par réflexion sur où les changements futurs sont les plus probables et essayer de comprendre de celui où la flexibilité est nécessaire.

ma pensée suivante sont juste une suggestion. ne hésitez pas à les considérer et le changement / ignore ce que vous ressentez est hors de propos.

séparant le DAL de la BLL est presque toujours une bonne idée. le système de données est une chose qui doit être encapsulé et caché du reste de l'application, laissez donc votre DataTables, datasets, ORM ou toute autre solution cachée dans la DAL. le BLL (et les couches au-dessus) doivent utiliser des types de données simples (ce qui signifie des classes simples). Je pense que ce serait une bonne idée de mettre ces classes dans une bibliothèque de classe modèle qui n'a pas de références et peut être utilisé partout.

il se sent comme vous avez un peu trop ... couches avez-vous vraiment besoin d'une classe à la clientèle dans le BLL et un autre dans la couche d'application? pourrait être, mais je veillerais et de penser deux fois plus.

de mon expérience dans l'un de mon projet récent (un site web météo avec 200K visiteurs uniques par jour), nous avons utilisé link2sql pour l'accès aux données (lecture seule des données pour la plupart), et les classes de données simples sur tout notre application ASP.Net MVC ( bien sûr, dans le cadre de modèles / voir les modèles). il fonctionnait très bien, et nous pourrions facilement changer le schéma de données sans se décomposer d'autres couches.

que pour votre dernière question sur DataTables, ces objets, si vous décidez de les utiliser (je voterais contre), appartiennent uniquement dans votre DAL. ils ne devraient pas être exposés à d'autres couches comme qui permettrait de créer un couplage à cette classe spécifique. Et si demain MS invente une classe beaucoup mieux? seriez-vous passer plus maintenant que vous avez une des références gazillion sur tous vos projets au DataTables, sa méthode et les propriétés? serait plus agréable de simplement changer votre DAL pour travailler avec la classe NewAwsomeDataTable et le reste de votre application est parfaitement ignorants.

espoir qui a aidé:)

Answer 3

J'utiliser le modèle ci-dessous car il vous permet de passer à une stratégie de persistance différente plus tard.

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 à travers les couches BLL / DAL.

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

En ce qui concerne les types garder dans leurs propres assemblées - oui pour les modèles de vue et afin de maintenir une cohérence, oui pour les modèles aussi bien.

Garder les modèles et les modèles de vue séparer les fuites d'arrêts des stratégies de persistance en dehors des BLL et permet ainsi des changements de conception de futurs à la persistance.

L'un des avantages de cette séparation est que les consommateurs que les différents modèles de vue peuvent avoir différents modèles d'affichage pour le même modèle / entité persistance. Certains pourraient être petits et ont peu d'attributs et d'autres grandes et riches en fonctionnalités. Il vous permet également d'introduire hors ligne / capacité disconnectedness que la vue des modèles peuvent être retournés à des moments différents vous permettant de décider la fusion des données des stratégies. Cela vous permet également de persistance des entités êtes des (par exemple des tables de croissance et de forme de changement). Étant donné que cela ressemble à une mise en œuvre des choses comme .net AutoMapper fournira un grand nombre de fonctionnalités hors de la boîte

Bien sûr, cela peut être le moyen surpuissant pour votre application - mais je maintiens encore une cartographie BLL qui ne parle que voir les modèles à tous les consommateurs de BLL. Cela devrait vous donner un découplage suffisant.

Answer 4

Repousser les entités de domaine dans le dal est une option qui supprimerait la dépendance crcular, mais peut ne pas correspondre à votre intention. Ce n'est pas rare, cependant; par exemple des entités LINQ to SQL gnerated habiteraient dans le DAL.

Autres options:

• les mettre en commun Baissez Assemblée (mais qui peut laisser votre BL plutôt vide)
• CIO utiliser pour supprimer / inverser la référence entre BL / DAL

Il n'y a pas de bonnes réponses simples ici.

Re DataTable; Personnellement, je suis d'accord - je ne suis pas fan;) Cependant, ils peuvent être utilisés avec succès et raisonnablement. Mais si je HAD pour les utiliser, je serais de les maintenir dans le DAL comme un détail de mise en œuvre -. Et ne pas les exposer ci-dessus que