Comment transmettre des données entre BLL et UI dans une application à trois couches (à un seul niveau)?

Question

Je suis un programmeur assez novice qui essaie d'apprendre les bases de l'architecture n-layered (DAL, BLL, UI). L'application que je suis en train de programmer est une application à trois niveaux, écrite en VB.NET (.Net 3.5). Couches comme suit:

DAL

BLL

UI

COMMUN - contient le droit de DTO maintenant.

Je n'arrive pas à déterminer ce qu'il faut passer entre ma BLL et l'interface utilisateur. Mon instinct me dit que je devrais seulement transmettre des données à l'interface utilisateur, et non pas l'objet métier complet de la BLL. Considérez deux scénarios:

1) Passez le BO directement de BLL à UI. Cela expose les méthodes BO et permet à l'interface utilisateur d'accéder directement au BO, ce qui semble mauvais.

2) Ne transmettre que les données pertinentes du BO à l'interface utilisateur. Par exemple, un client a un nom et une adresse. Ces données sont vraiment ce que nous voulons montrer/éditer dans l'interface utilisateur, donc nous ne retournerions ces données à l'interface utilisateur au lieu de l'intégralité de BO. L'interface utilisateur appelle ensuite la BLL pour mettre à jour un BO spécifique.

Je suis enclin à utiliser # 2, mais je ne connais pas la meilleure façon de l'implémenter. De la façon dont je l'ai programmé maintenant, si je retourne seulement des données de la BLL, toutes les références à mes BO seront perdues et le GC les réclamera. Sur cette base, j'ai quelques questions:

1) Devrais-je conserver les objets métier en vie entre les appels à la BLL? L'alternative est de les recréer chaque fois que je transmets des données à travers la BLL, ce qui me semble faux.

2) Quelle est la meilleure façon de garder un BO vivant dans une architecture à palier unique (comment tenir une référence si nous ne le transmettre à l'interface utilisateur?)

3) Comment les applications n-tier font ce? Est-ce qu'ils gardent les BO vivants dans le BLL et attendent une mise à jour de l'interface utilisateur? Cela ne nécessite-t-il pas beaucoup de «comptabilité» dans la BLL pour s'assurer que les BO sont libérés quand ils ne sont plus nécessaires?

Merci pour toute idée, et pardonnez-moi si je demande quelque chose de stupide. Je me suis appris la petite programmation que je connais, alors je pose peut-être une question stupide et je ne le sais pas.

Answer 1

Voir Pet Shop comme exemple de l'architecture à 3 couches. Je vais implémenter à la fois BLL et DAL comme objet de service, qui à lui seul ne contient aucun état. Puisqu'ils sont apatrides, je peux utiliser le motif singleton et laisser un factory s'y accrocher pour faciliter la consultation.

Voici quelques méthodes CRUD exemple vous pourriez avoir:

FooInfo DALFactory.FooService.Retrieve(int id); 
FooInfo BLLFactory.FooService.Retrieve(int id); 

IList<FooInfo> DALFactory.FooService.RetrieveAll; 
IList<FooInfo> BLLFactory.FooService.RetrieveAll; 

FooInfo DALFactory.FooService.Create(FooInfo entity); 
FooInfo BLLFactory.FooService.Create(FooInfo entity); 

FooInfo DALFactory.FooService.Edit(FooInfo entity); 
FooInfo BLLFactory.FooService.Edit(FooInfo entity); 

void DALFactory.FooService.Delete(FooInfo entity); 
void BLLFactory.FooService.Delete(FooInfo entity); 

Comme vous pouvez le voir dans les deux cas, vous passez le même objet d'entité (aka objet de transfert de données) qui n'a pas de logique que ce soit. Cette architecture vous permet de déconnecter la couche d'interface utilisateur de BLL sur toute la ligne vers un combo client riche et services Web. L'objectif de la méthode Retrieve et RetrieveAll est de saisir les données de la base de données et de les insérer dans l'objet entité. La méthode Create ajoute une nouvelle ligne à la base de données en fonction de l'entité donnée. Dans cette architecture, il n'y a pas d '"objet métier" en plus de BLLFactory.FooService de Business Logic Layer et de l'objet entité FooInfo.

En termes de durée de vie de ces objets, l'état BLLFactory.FooService sans état est créé une seule fois et sera réutilisé tant que l'application est active. FooInfo a pu être créé une fois par objet, puis a persisté dans la session ASP.NET ou quelque chose.

Answer 2

Voici comment je l'ai toujours fait:

UI - ASP.Net ou Windows fait appel à un service Web
SERVICE - C'est la couche de service que l'interface utilisateur appelle
COMMUN - DTO - Données transfert objet la clé est au nom
BLL - Contient Business Objects et le code de la carte DTO à Business Objects et retour seulement DTO sont passés à la couche de service
DAL - accès aux données