Utilisation de DTO sur le site Web asp.net pour une architecture à 4 niveaux

Question

J'ai quelques inquiétudes à propos de DTO. J'essaye de créer l'architecture de niveau 4 pour mon site Web d'asp.net. J'aurai DTO, BLL, DAL et Presentation Layer.

1. Dois-je créer un DTO pour chaque table? J'ai presque 100 tables et certaines des tables ont 70-100 colonnes.

2. Pour une requête compliquée où je rejoins 5-8 tables, Comment aborder cette question? Ai-je besoin d'obtenir DTO pour chaque table, puis d'exécuter Linq Query sur toutes ces listes DTO dans BLL, puis de renvoyer le résultat à la page aspx?

S'il y a d'autres suggestions, s'il vous plaît faites le moi savoir. Merci d'avance pour votre aide.

Answer 1

Certaines personnes insistent pour avoir des DTO séparés pour chaque appel de service que vous effectuez. Selon la complexité de la logique, cela pourrait potentiellement conduire à plus de 100 DTO différents.

Je préfère une approche générique, où vous construisez un modèle DTO avec une correspondance 1-1 entre les DTO et les entités de domaine. Dans cette approche, vous aurez 100 tables DTO. Si vous utilisez un outil pour créer automatiquement du code (Codesmith, T4), la création de la couche DTO peut être facile.

L'autre préoccupation, le retour des résultats composés peuvent être relevés avec un conteneur DTO générique pour tenir vos classes DTO:

http://netpl.blogspot.com/2010/12/generic-dto-model-and-other-silverlight.html

(la section commence à la « modèles génériques DTO)

Answer 2

Vous n'aura besoin d'un DTO que si vous devez passer un objet simple, peut-être du référentiel DAL (où votre DTO = une table, un résultat de procédure stockée ou un résultat de vue) vers un objet domaine/BLL qui pourrait bien être un objet logique. vue du domaine plutôt que d'un mappage un à un à partir de la base de données. Tout dépend de la façon dont vous «développez» votre application.

Si vous avez des charges de DTO similaires, cela peut être une bonne idée d'utiliser un outil, comme AutoMapper - cela vous fera gagner beaucoup de temps en écrivant du code de mapping ennuyeux.