question d'architecture à trois niveaux

Question

J'ai une application ASP.NET avec une architecture à trois couches:

• couche de présentation: ASP.NET

• Bussiness couche:. Bibliothèque C #

• Accès aux données couche: bibliothèque C # avec
  objets ADO.Net Entity Framework.

Certaines méthodes sur couche Bussiness retourneraient objets d'entité ADO.NET mais, couche d'accès aux données ne sont pas visibles sur la couche de présentation, je ne peux pas le faire.

Ma question est: Sur une vue de la conception, est-il correct d'exposer les objets entité dans la couche de présentation? Je pense que je dois seulement relier la bibliothèque de la couche de données avec l'application ASP.NET.

Merci!

Answer 1

Je vous suggère de regarder dans les concepts de vue des objets ... ou des objets de transfert de données (DTO). Vous pouvez envisager d'utiliser un outil comme AutoMapper ou similaire qui va créer une vue objet de domaine spécifique de vos entités. En général, vous pouvez avoir des écrans qui ont besoin d'une entité présente pour effectuer son travail. Mais plus souvent qu'autrement, vous aurez besoin de passer plusieurs entités différentes. Dans ce cas, vous êtes mieux de créer un DTO qui contient toutes ces entités. En faisant cela, vous ajoutez une couche de séparation entre votre couche de présentation et votre couche d'affaires. Souvent, vos entités ont plus de pouvoir que vous voudrez peut-être exposer à votre couche de présentation. Et vice versa. vous pouvez souvent besoin d'obtenir des messages interface utilisateur vers la couche de présentation basée sur une validation signalé dans votre couche d'affaires. Plutôt que de rendre votre ui plus complexe qu'il doit être (en passant dans vos entités complètes) vous ne pouvez passer ce que l'interface utilisateur a besoin sous la forme de la DTO. En outre, il n'y a jamais besoin de vos objets métier se soucier de quoi que ce soit spécifique à la couche de présentation. Je vous suggère de ne pas Databind directement à quoi que ce soit d'aussi loin que la couche d'accès aux données. Techniquement, votre couche de présentation devrait savoir aussi peu que possible au sujet de votre couche d'affaires. Dans le cas cela est très facile à réaliser de MVP ou MVC en débranchant l'extrémité avant et l'arrière par l'intermédiaire de cette séparation supplémentaire!

Answer 2

Il est tout à fait souhaitable d'avoir votre entité des objets disponibles pour l'utilisation et la consommation dans votre niveau de présentation. C'est ce que tout le travail est pour.

• collection d'objets de liaison à une grille / liste image / déroulante
• Éclaboussures un seul objet (à savoir le client) sur un formulaire de lecture / mise à jour / supprimer

Cela rend votre vie plus facile de loin. Sinon, vous auriez à passer chaîne après int après un double après la chaîne entre vos couches présentation et affaires.

Ceux-ci peuvent être des objets d'entité ou même vos propres objets POCO qui ont été hydratés à partir des objets d'entité.

J'irais même jusqu'à dire que vos devraient être Entités mises leur propre assemblée distincte de la DAL.

Answer 3

Je pense pas, ce n'est pas, la meilleure façon de le faire est de séparer les classes de données de comportement et référence uniquement des classes de données dans la présentation level.The bonne approche, je pense à utiliser WCF voir cette lien

Answer 4

Voir Controller et superviseur Voir passif

Si vous passez l'entité, vous êtes essentiellement la supervision contrôleur. Sinon, vous êtes passif Voir.

est le contrôleur de supervision moins de travail, mais moins testable. Contrôleur surveillant dit aussi databinding est OK. vue passive est testable, mais beaucoup plus de travail. Non databinding. Beaucoup de propriétés.

En général, je bâton avec contrôleur de supervision. En général, vous n'avez pas besoin de ce niveau de testabilité et il ne vaut pas la peine supplémentaire.