Objets métier et couche de données

Question

Ce site m'a fourni de nombreuses réponses utiles, mais après une recherche d'une heure, je n'ai rien trouvé qui réponde spécifiquement à mes besoins. Alors voilà ...

La société pour laquelle je travaille est en train de concevoir un nouveau calque Business Objects et un calque d'accès aux données - ceux-ci se trouveront dans des assemblages séparés. Le problème est que j'ai de la difficulté à comprendre l'interaction entre ces deux couches. En particulier, si le DAL connaissait le BOL, j'ai lu de nombreux articles qui ont dit que l'ordre de dépendance devrait aller quelque chose comme ceci:

GUI/Présentation -> BOL ---> DAL

Mais pour autant que je peux voir, le DAL a besoin d'une référence au BOL afin de pouvoir les objets « de retour » à la couche BOL. Je vais pour un assemblage intermédiaire entre le BOL et DAL qui sera fondamentalement une couche mince remplie d'interfaces pour découpler ces deux DLL, de sorte que le cadre peut utiliser différents DAL si le besoin s'en fait sentir. Ceci m'amène à l'idée d'introduire une autre couche mince avec un tas d'interfaces implémentées par les BO, puis quand la BOL appelle l'interface DAL, elle lui passe un objet qui implémente une de ces interfaces BO puis la DAL procède à remplir l'objet. Cela supprime toutes les dépendances entre le BOL et le DAL - cependant, j'ai du mal à le justifier pour être honnête. Idéalement, nous aimerions utiliser un ORM car il supprime simplement la nécessité d'écrire des choses CRUD mais nos clients ont l'habitude de jouer avec les longueurs de colonne sur leur base de données et c'est la cause de la plupart de nos erreurs à ce jour en utilisant les DataTables fortement typés. J'ai entendu dire que Linq2SQL stocke aussi les longueurs de colonnes au moment de la compilation, pas sûr que NHibernate le fasse ou non (mais je ne suis pas sûr que notre schéma de base de données soit assez bien conçu pour NHibernate, les pièges des anciens systèmes). Donc, tout aperçu sur la relation entre un BOL et un DAL serait très bienvenue - excuses si ce qui précède est mal écrit, si quelqu'un a besoin de clarification, je serai heureux de fournir plus de détails.

Marlon

Answer 1

La façon dont le je fais est la BO attend une DataReader ou un DataContext ou tout retrait de la DAL, et non l'objet formé réelle. C'est alors le travail de la couche BO à prendre et se remplir de l'objet qui revient. Le DAL ne renvoie pas un BO terminé. La principale chose à retenir est que changer quelque chose dans la couche BO ne devrait pas causer de problèmes pour la couche DAL, mais changer quelque chose dans la couche DAL pourrait causer des problèmes pour la couche BO.

Un court exemple de ce que je fais habituellement

Dans la couche BO

FillData(){ 
    DataReader dr = DataLayer.GetData("SomePropertyForAStoreProcedure"); 
    If dr.Read(){ 
    Property1 = dr.GetValue("Property1"); 
    //So on and so forth 
    } 
} 

Dans le DAL

DataReader GetData(String SPProperty){ 

} 

Answer 2

un coup d'oeil à SubSonic http://subsonicproject.com/ il fait la plupart des accès aux données travail fastidieux pour vous et c'est plus facile que la plupart des ORM là-bas

Answer 3

Le DAL a besoin d'une référence au BOL pour qu'il puisse remplir les objets.Ce que vous ne voulez pas avoir, c'est une référence ou un couplage du BOL à la DAL - ce qui fait que votre BOL est couplé à une implémentation de base de données spécifique. Quand vous y réfléchissez, cela a du sens. Votre DAL connaît les détails des objets métier jusqu'au niveau des propriétés et comment récupérer leurs données dans la base de données - bien sûr, le DAL est intrinsèquement couplé au BOL. Donc, la référence de cette façon est bien. Et si vous y réfléchissez, que se passe-t-il de l'autre côté? La base de données. "Couplage étroit" allant de vos données d'objet à votre base de données? Ouais, c'est juste sacrément serré. Le concept n'est même pas très significatif.

C'est dans l'autre sens que vous devez vous découpler. Donc oui tant qu'il n'y a pas de couplage direct du DAL dans le BOL, vous pouvez changer votre plate-forme de données comme vous le souhaitez.

Il ne sert à rien de créer des interfaces pour les BO et de les transmettre à DAL dans ce scénario. Vous devrez peut-être parfois aller dans l'autre sens cependant. En règle générale, les objets métier ne doivent rien savoir de la manière dont ils sont créés ou conservés. En pratique, même avec la plupart des ORM, la création d'une couche de gestion totalement exempte de toute sorte d'artefacts de persistance peut devenir très difficile, parfois impossible. Il arrive donc que vous ayez quelque chose de trop difficile à contourner, et vous pourriez vous apercevoir qu'éviter strictement d'avoir des connaissances dans les BO vous conduit à une complexité qui est dégradante plutôt que d'ajouter de la valeur. Si vous pensez qu'il n'y a pas de meilleure solution et que vous avez besoin de quelque chose de persistant à l'intérieur du BOL, créez une interface simple pour que la fonctionnalité DAL puisse être transmise au BOL. De cette façon, vous pouvez toujours garder le BOL découplé de l'implémentation spécifique de la base de données au moins.

Aussi, bien qu'il s'agisse de beaucoup de travail supplémentaire, à moins que ce ne soit une application très simple, je vous recommande fortement d'ajouter un autre calque entre l'interface utilisateur et le BOL. Le modèle MVP (Model-View-Presenter) est un modèle de conception général destiné à réduire le couplage entre l'application principale et l'interface utilisateur. Il y a beaucoup de variantes sur les présentateurs, ne soyez pas trop pris dans les détails spécifiques, commencez simplement avec le MVP simple si vous ne l'avez jamais utilisé. Les modèles ne sont pas si difficiles, c'est juste que l'interface utilisateur elle-même est si désordonné qu'il peut vous prendre au moins quelques itérations/applications majeures avant que vous sentiez que le code que vous écrivez à tout moment est systématiquement et méthodiquement travailler pour découpler l'interface utilisateur. Continuez à travailler dessus, commencez à acquérir un arsenal de techniques, et ne vous attardez pas sur le fait que vous n'avez pas encore réussi une séparation nette et nette. Tout et n'importe quoi que vous apprenez et pouvez faire cela contribue même un peu à la création de créer une limite bien définie à l'interface utilisateur est un grand pas dans la bonne direction.

Answer 4

Cela dépend également de la bibliothèque if/what/ORM (Object-Relational Mapper) que vous utilisez. Lors de l'utilisation d'un (bon) ORM, le DAL devrait être une préoccupation très éloignée, car il est presque complètement caché par l'ORM; Cependant, les meilleures pratiques indiquent que même dans ce cas, pour les applications de taille moyenne à grande, vous devez introduire une autre couche entre le BOL et l'ORM, généralement DTO (Data Transfer Objects). Les DTO peuvent également être utilisés sans ORM, car ils sont simplement des objets idiots définis dans une bibliothèque séparée, et le DAL peut être responsable de leur persistance (en les transformant de/vers les structures de base de données), tandis que le BOL peut interroger le DAL objets.

Le découplage des couches peut être réalisé de diverses manières, le plus souvent par le biais d'interfaces et/ou de MEF ou d'un autre cadre DI/IOC. Une telle technique permet un découplage plus que suffisant si elle est utilisée efficacement. En outre, en fonction de la technologie utilisée, comme l'a dit Sisyphe, l'un des motifs architecturaux en couches aidera à bien séparer les préoccupations: MVC, MVP, MVVM, etc.Personnellement, je recommande MVVM avec WPF (bureau) ou Silverlight (web), mais je suis très partial - c'est-à-dire que je les aime tous les deux à mourir :)

Answer 5

L'approche «correcte» va varier en fonction des besoins de l'entreprise. Pour être honnête, il y a beaucoup de projets où je pense que les anciens jeux d'enregistrements ado de style ont subi moins de temps de développement et étaient plus faciles à entretenir que beaucoup de ORM sortent maintenant. Prenez le temps d'identifier vos besoins et rappelez-vous que le temps de développement et la maintenabilité sont des objectifs de conception qui doivent être correctement évalués.

Answer 6

Ce sont mes conclusions,
1. Utiliser les interfaces
2. Utilisez DTO [Objets de transfert de données] entre DAL & BLL
3. BLL de Split en deux,
a. BLL
b. Service Layer
4. Utilisation Conteneur Inversion of Control (IoC) pour maintenir le couplage le plus bas possible.