faire passer des données dans une application nTier

Question

Comment passez-vous des données à des couches dans une application n-tier? J'ai tracé 3 méthodes différentes.

A) objets génériques .net tableaux de données génériques, Hashtables, jeux de données génériques, cordes, etc ... ints puis en utilisant les ensembles de données pour remplir vos objets métier qui sont envoyés à la couche d'interface utilisateur.

texte alt http://img11.imageshack.us/img11/460/generic. PNG

http://dabbleboard.com/draw?b=eiu165&i=26&c=54eef6f1ac01f03c85919518f4a24e798e57e133

Pro - Aucune couche supplémentaire nécessaire Con - doivent travailler avec des ensembles de données génériques et des tables dans la couche d'affaires

B) en utilisant une couche d'entités que les autres couches se référencer. Cette couche contiendra soit des ensembles de données fortement typés ou objets Plain Old C. Les objets seraient principalement des données de conteneurs et très peu de logique. ceux-ci seraient les mêmes objets envoyés à la couche d'interface utilisateur.

texte alt http://img8.imageshack.us/img8/6454/entities. PNG

http://dabbleboard.com/draw?b=eiu165&i=6&c=d0c2b346894a96b12bd3867f630e474a2af098fa

Pro - travailler avec les mêmes classes dans toutes les couches Con - ajouter une référence à entities.dll à toutes les couches

C) utiliser des objets de transfert de données (objets conatiner uniquement) définies dans la couche d'DataAccess. puis utiliser ces objets pour remplir des objets d'affaires qui sont envoyés à la couche d'interface utilisateur.

alt texte http://img43.imageshack.us/img43/1236/transferp. PNG

http://dabbleboard.com/draw?b=eiu165&i=27&c=f886efa3f9d5eb4b45ddb02361c79cdcdaec0a9b

Pro - la couche d'affaires ne serait pas travailler avec des classes génériques Con - travailler avec deux types d'objets et vous auriez à hydrater les objets d'affaires avec les objets de transfert

Nous avons eu une discussion au travail et je voulais voir ce que la communauté pensait. J'ai également ajouté un lien vers le Dabbleboard. S'il vous plaît copier et créer au lieu d'édition.
Merci

Answer 1

Si vous utilisez un couches approche, ce qui signifie toutes les couches sont (essentiellement) exécutaient dans le même espace de processus et il n'y a donc pas marshalling / sérialisation, je vais à l'approche B. Créer un module séparé pour vos entités sur lesquelles tous les aspects de votre programme dépendent, et deux à cela.

Par contre, si vous utilisez un à plusieurs niveaux approche que votre titre l'indique, ce qui signifie qu'il sont processus et / ou les limites du réseau qui croisaient, je vous suggère d'aller à l'approche C. Vous n'êtes pas vraiment des cas qui passe autour, vous copies en passant, donc tous les avantages que vous obtenez le couplage au même objet, comme les options observables pour, par exemple, une approche MVC, sont perdus de toute façon. Mieux vaut définir les API de données à tous les niveaux de niveau que d'essayer d'utiliser la même classe tout autour.

Answer 2

Grande question -. Comme toujours, la réponse doit être "ça dépend"

Sur le type d'application, et s'il est vraiment nécessaire d'avoir des objets d'affaires (entités), par opposition à transférer des objets (c.-à-objets métier dumbed-down qui correspondent plus à des entités de base de données).

Traditionnellement, je l'aurais fait valoir que vous avez toujours besoin d'ensembles de données génériques (ou tableaux de données), uniquement pour des raisons de performance. Chaque fois qu'il est nécessaire de travailler avec, afficher ou manipuler des ensembles plus grands, la traditionnelle stricte façon OO d'instancier un grand nombre d'objets d'affaires a échoué.

Cependant, comme j'ai commencé à travailler avec LINQ to SQL, mes paradigmes ont changé. Il n'y a plus besoin de ce tout, puisque le modèle Linq peut être tout - objets métier, objets de transfert et des ensembles de données génériques. Je ne l'ai pas encore exploré comment cela fonctionne dans des applications très grandes, et s'il devrait y avoir un besoin d'isoler le code frontal du modèle Linq. J'ai eu des discussions à ce sujet avec des collègues, sans vraiment trouver une réponse dans les deux cas.

Answer 3

J'aime l'option C, mais il donne aussi une pause me pour deux raisons:

1. Je dois répandre la knwowledge de ce que les properites sont trop nombreux endroits.
2. DTO doivent être sérialisable, ce qui est pas terrible, mais encore une considération.

Answer 4

Je suppose tous les 3 couches existe au sein de la même application. En java atleast j'ai utilisé Hibernate pour l'accès aux données et utilisé les fèves de données dans toutes les couches. (Option B) Il est logique d'être en mesure de réutiliser vos entités dans vos couches.