l'architecture n-couches - BLL, DAL et interfaces. Quelle est la meilleure pratique?

Question

J'ai une question concernant l'architecture n-couche. Je pensais que long et difficile avant de poser cette question car il y a beaucoup de questions semblables ici déjà ... mais, après littéralement une journée et demie regarder et lire ces autres réponses que je suis toujours pas sûr. La variété des approches de terminologie et différentes en apparence semblables m'a confus.

Si j'avais un BLL et DAL dans différentes bibliothèques de classes, une façon de communiquer entre le BLL et DAL serait d'utiliser une interface, un peu comme un DTO défini dans une autre DLL séparée qui a été référencé par les deux BLL et DAL . Mes entités du modèle de domaine dans le BLL mettrait en œuvre cette interface et ainsi tous les objets seraient générés ORM dans le DAL. Pour enregistrer mes entités d'affaires que je pourrais alors les transmettre à la DAL qui les accepterait bien parce qu'ils mettent en œuvre l'interface commune. Je pourrais aussi passer des objets Retour à la BLL qui mettent en œuvre cette interface. Cette fois comme BLL et DAL semble raisonnable, alors que doivent être conscients de l'interface de base, pas les uns les autres la mise en œuvre concrète.

Ma question est ce qui est ce qui est la meilleure méthode pour créer l'objet de l'autre côté? Par exemple, si j'avais un objet Personne dans le BLL qui a mis IPerson, et un PersonDataObject ou quoi que dans la DLL qui implémente également IPerson, je passe personne à une méthode dans la DAL qui prend un paramètre de IPerson, puis dans le DAL I » d ont pour reconstruire une PersonDataObject persister. Est-ce même la meilleure méthode?

Désolé je n'ai probablement pas expliqué trop bien que je suis assez confus. Une meilleure pratique pour la réponse des mannequins serait très apprécié.

Answer 1

D'une manière générale, les objets dans le BLL consommera les interfaces - ne pas les mettre en œuvre:

  

Par exemple, si j'avais un objet Personne   dans la mise en œuvre BLL que IPerson,   et un PersonDataObject ou quoi que dans   la DLL qui a également des outils IPerson

Faire une « personne » comme un exemple: réfléchir sur les différentes opérations de données associées à une personne (Obtenir toutes les données pour une seule personne, une collection de données peu profondes pour de nombreuses personnes, les opérations CRUD, la recherche, etc.) - puis interfaces de conception ainsi que des regroupements logiques (voir la Interface Segeragtion Principe ).

Les interfaces peut représenter des opérations dans une perspective centrée sur BL -. Ou un "service" une base

Quoi qu'il en soit, pour répondre à votre question spécifique ...

Je définir mon équivalent de ce DTO dans une assemblée commune, et l'interface de données dans un contrat distinct et - donc j'ai 4 ensembles: BL, définition d'accès aux données Inteface, la mise en œuvre et l'interface commune; tous les ensembles de référence d'une commune.

Je travaille en C # .Net, je définis les DTO comme struct (mais vous pouvez utiliser des classes); et toutes les propriétés de ceux-ci sont en lecture seule - vous nourrissez des données en eux dans le constructeur -. Ainsi les années de DTO sont effectly enveloppes « muets » de l'information

Answer 2

En suivant l'architecture n-tier, il est très fréquent de partager les objets de données entre BL et DAL. Parfois, le même objet de données peut être utilisé dans la couche UI.

En général, j'ai un modèle de données (ou objets de données ou d'un modèle de domaine, tout ce que vous nommez) que l'assemblage des maisons tous les objets modèle comme interfaces. Prenant votre exemple des gens, je vais créer l'assemblage d'une interface iPeople dans le modèle. DAL renverra une instance de iPeople à BL. BL consommera cette instance et si nécessaire transmettre ce message à la couche d'interface utilisateur après l'application de la logique métier.

Answer 3

Google pour la conception Domain Driven et le modèle référentiel. Il soumnds comme vous dirigez dans cette direction avec votre architecture et selon que les bons de souscription de scénario, j'utiliseraient cette approche sur le code plus complexe.