Y a-t-il un avantage à utiliser un DTO plutôt qu'une référence partagée aux Entités dans un assemblage commun?

Question

J'essaie d'obtenir une réponse finale claire à une question qui m'a rendu fou pour une longue période.

Il est communément exprimé que BLL doit contenir Business Logic et Business Objects (BO) et avoir une référence à la couche DAL. Le DAL, d'autre part, ne peut pas avoir une référence à la BLL, donc il ne peut pas accepter les BO comme arguments, ou retourner les BO comme valeurs de retour.

La réponse la plus traditionnelle à ce problème consiste à:

a) Accepter des paramètres simples et retour (de préférence dactylographié) DataSets et DataTables pour renvoyer des données: espace de noms DAL { public class Contacts DataTable publics GetContacts () {...} public UpdateContacts (Contacts DataTable) {...}

b) La deuxième solution la plus recommandée consiste à définir des objets de transfert de données (DTO) temporaires et sérialisables (parfois appelés objets de valeur (VO))) qui n'ont que des champs et des propriétés, pas de méthodes, et ne sont utilisés que pour transférer brièvement les données remontent à la couche BLL, où il est utilisé pour peupler les nouveaux BO, à quel point ils sont ensuite mis au rebut.

c) Utilisez un troisième ensemble commun (par exemple appelé Entities.dll), qui définit les BO, et est référencé par les trois couches: l'interface utilisateur, BLL et DAL.

L'option a) prend le moins de travail à implémenter (pas besoin de construire un autre assemblage), d'où la raison souvent proposée, mais les DataTables ont un câblage supplémentaire qui n'est pas nécessaire uniquement pour les opérations simples.

Pourtant, il est très peu claire, à laquelle de b) ou c) est mieux ...

Je vois b) offert parfois, et presque jamais c), même si c) semble être le plus facile des deux .

Qu'est-ce qui me manque? Pourquoi c) est-il si rarement proposé, même s'il semble logiquement le plus facile, et pourquoi a) est-il offert quand il n'est clairement pas adapté à tous les scénarios (par exemple, le retour d'objets uniques)?

Merci!

Answer 1

Eh bien, je ne vois guère (b) employé dans la pratique. J'utilise l'approche décrite en (c) la plupart du temps (l'autre fois c'est quand je ne sépare même pas entre le BLL/DAL ou que j'ai un modèle de domaine du tout). Après tout, les composants d'entreprise et de données sont généralement regroupés physiquement, il est donc facile pour le BO d'être partagé par ces deux éléments. En fait, les frameworks tels que Hibernate, Entity Framework, Linq2Sql etc. encouragent (c) en permettant d'effectuer des ORM pour un modèle de domaine complexe.

DTO est plus généralement utilisé pour transmettre des données de la BLL à l'interface utilisateur, en particulier. lorsque l'interface utilisateur et BLL sont déployés dans des serveurs distincts. Dans ce cas, l'interface utilisateur aura probablement besoin d'une vue simplifiée du modèle de domaine pour réduire les allers-retours inter-processus et minimiser l'impact du changement (lorsque le modèle de domaine change).

Answer 2

ADDENDA à la question initiale:

Je pense que (après la première réponse, par Buu Nguyenthat le modèle de référence suivant est tout à fait acceptable, et peut-être même recommandé avec LINQ, etc:

BLL > 

v Business Entities Layer (BEL) 

DAL > 

À moins BLL et DAL sont sur différents niveaux, et BLL communique à DAL via WCF ...? Dans ce cas, cela ne fonctionnera pas (les entités commerciales retournées par DAL via WCF seront sérialisées, et du côté BLL seront désérialisées en Proxies des BE d'origine ... et non mappées sur BE elles-mêmes. ou est-ce fait faux, et le modèle de référence ci-dessus fonctionnera quand BLL et DAL sont en même niveau, ainsi que dans différents niveaux

ADDENDA # 2: trouvé un lien intéressant pour expliquer pourquoi son fait bon He states que "c'est une violation de la règle que la couche devrait seulement connaître la couche immédiatement ci-dessous, mais la base de données qui dicte les noms de colonnes n'est pas directement en dessous de BLL elle est en dessous de DAL. DataSets non typé ne protège pas y ou de la base de données et c'est pourquoi je pense qu'ils ont tort. Une meilleure solution serait d'utiliser un objet fortement typé défini dans un projet séparé. Ainsi, par exemple, il y aura une classe Teacher dans le DTO avec une propriété Name mais sans une méthode Grade. "

Answer 3

Je ne serais pas surpris si (c) était assez commun et si votre BLL et votre interface utilisateur sont sur un serveur différent vous pouvez également passer des entités sur le fil si vous utilisez WCF Jetez un oeil à cet exemple pour savoir comment faire la sérialisation des entités here [zip] et voici un lien vers le downloads page. Ce message pourrait également aider avec serializing with WCF