Architecture n-tiers requise

Question

J'ai lancé mon site Web, comme Stackoverflow, avec une petite dette technique que je tente de rembourser. En tant que développeur contractuel, j'ai visité de nombreux endroits et constaté de nombreuses méthodes pour parvenir à ce résultat, mais je vais dans la bonne direction.

Présentation (Web)

Couche de gestion (classes d'entités et couche BL à l'ancienne)

Couche de données (classes DA vers SQL Server via Stored Proc)

Ma question concerne principalement la couche de gestion. À l'heure actuelle, j'ai un espace de noms Entity et un espace de noms BusinessLogic.

Le BL a une référence au DA et à l'entité. L'entité a une référence au DA (Le DA n'est "pas au courant" du BL ou de l'entité)

Je souhaite vraiment que tous mes efforts pour transformer des données en entités se produisent au sein du BL - et donc de la logique applicative. Cependant, je souhaite que l'entité puisse accéder au BL si besoin est - et supprimer ainsi la référence de l'entité à la liste de distribution.

Alors ...

Est-ce qu'il est "incorrect"? avoir les objets BL et Entity dans le même espace de noms pour pouvoir travailler ensemble?

Essentiellement, j'essaie d'avoir un objet entité comme Employé (exemple classique, hein?) et que l'employé ait un

public Hashtable[] SubordinateEmployees

propriété qui retourne une table de hachage d'autres objets Employé qui relèvent de cet employé. Mais je ne veux pas le charger avant que ce ne soit nécessaire. Donc, pour la plupart des employés, la propriété n’aurait jamais accès à cette propriété, mais elle le chargera automatiquement avec un appel au BL, qui appellera le DA.

La question a-t-elle un sens?

Si oui, ma solution?

Merci beaucoup d'avance!

Answer 1

La manière habituelle de traiter le type de situation que votre exemple représente consiste à utiliser des façades. Au lieu d'essayer d'obtenir les employés subordonnés à partir de l'objet Employé, vous utilisez un appel à la logique applicative pour l'obtenir.

hashtable = BL.GetSubordinateEmployees(supervisor);

De cette manière, vous n’avez qu’un seul point d’accès pour les subordonnés, et il n’ya qu’une chose (le BL) qui accède à la couche de données et crée des entités.

Answer 2

Laissez-moi voir si je peux vous montrer une meilleure façon de penser à cela

vous avez accès à vos données (serveur SQL, mysql, fichiers xml à plat, etc.), tout cela doit être résumé, rien d’autre dans votre application ne doit vous préoccuper ou savoir comment vous obtenez vos données, mais seulement si tout le reste sait comment vous obtenez vos données que vous avez une violation de couche. Si le DAL dose quelque chose d'autre, alors obtenir des données, vous avez une violation de couche. Ensuite, vous implémentez une interface d'accès aux données, similaire à IDAL, utilisée par votre couche métier. Cette opération est très importante pour rendre votre code testable en vous obligeant à séparer vos couches.

Vos entités de données peuvent être placées dans l’espace de noms DAL ou leur être attribuées propres, en leur attribuant la séparation de leurs propres forces. Les entités de données sont des objets stupides et ne doivent contenir que peu ou pas de logique. Elles ne sont conscientes d’eux-mêmes et des données qu’elles possèdent. ILS NE CONTENENT PAS BUSINESS LOGIC !, LOGIC LOCAL D’ACCÈS AUX DONNÉES OU LOGIQUE UI. si c'est le cas, vous avez une violation de couche. La seule fonction d'une entité de données est de contenir des données et d'être transmises d'une couche à l'autre.

La couche Biz implémente une interface d'accès aux données telle que l'IDAL dont nous avons parlé avant de pouvoir l'instancier avec une fabrique, un conteneur IOC ou tout autre élément qui échoue dans un type concret, mais en ajoutant une propriété de définition afin qu'elle puisse être modifiée à des fins de test. La couche Biz ne gère que la logique commerciale, elle ne sait ni d'où proviennent ni où vont les données, elle ne s'occupe que de manipuler les données pour se conformer aux règles commerciales, cela inclurait la validation de la date, le filtrage (en partie en indiquant au DAL les données dont il a besoin, laissez-le déterminer comment l'obtenir). Fondamentalement, le BIZ gère toute la logique qui n'est pas liée à l'interface utilisateur ou à la récupération de données. Tout comme le DAL, le Biz devrait implémenter une interface pour la même raison.

La couche d'interface utilisateur Accède à la couche Biz de la même manière que la couche Biz accède au DAL pour la même raison. La couche UI se soucie uniquement d’afficher des données et d’obtenir des données de l’utilisateur. La couche UI ne doit rien savoir des règles commerciales, à l'exception peut-être de la validation des données requise pour renseigner les entités de données.

L’avantage de cette architecture est qu’elle force la séparation des préoccupations, facilitant ainsi les tests, la flexibilité et la maintenance. Aujourd'hui, vous construisez un site Web, mais vous souhaitez permettre aux autres d’intégrer un service Web, il vous suffit de créer un service Web qui implémente l’interface IBIZ et c’est chose faite lorsque vous devez corriger un bogue dans le BIZ. couche, elle est déjà corrigée dans votre site Web et votre service Web.

Si nous passons à un autre niveau, disons que vous faites beaucoup de calculs et que vous avez besoin de serveurs plus puissants pour le gérer. Il vous suffit donc d'implémenter une interface IDal et IBIZ qui sont vraiment des enveloppeurs pour WCF qui gère la communication entre vos serveurs, votre application est maintenant répartie entre plusieurs serveurs et vous n'avez pas besoin de changer votre code pour le faire.