Domain vs DTO vs ViewModel - Comment et quand les utiliser?
Dans un projet multicouche avec couche de domaine (DL)/couche métier (service) (BL)/couche de présentation (PL), quelle est la meilleure approche pour fournir des entités à la couche de présentation?
DO => Domain Object;
DTO = Domain Transfer Object;
VM => View Model;
V => View;
Option 1:
DL => DO => BL => DTO => PL => VM => V
Cette option semble être la meilleure pratique mais semble également lourde à maintenir.
Option 2:
DL => DO => BL => DTO => PL => V
Cette option ne semble pas être une très bonne pratique, mais comme les DTO sont presque identiques à la machine virtuelle, nous pouvons les transmettre directement à View et il est moins pénible à mettre en œuvre et à maintenir.
Cette option est-elle également fiable pour plusieurs mises en page, par exemple pour les appareils mobiles? J'ai peut-être besoin de moins d'informations de la part du BL, donc il me faudra un diferent VM pour cette mise en page particulière?
C'est OK pour passer le DTO à la vue. Si vous devez modifier ou améliorer le DTO, créez un ViewModel. Un scénario courant consisterait à ajouter des liens. ViewModel peut également faire référence au DTO en tant que propriété complexe.
Si vous envisagez différentes vues nécessitant des données différentes de celles de votre Dto, vous avez tout intérêt à utiliser différents modèles de vues et à y associer votre Dto.
Une des idées sous-jacentes est de permettre une plus grande liberté pour modifier votre modèle de vue, sachant qu'il n'aura aucun impact sur aucune autre partie de votre application. Si votre Dto est utilisé dans plusieurs vues, chaque modification apportée à votre Dto nécessite que vous testiez chaque vue.
Pour moi, cette décision est basée sur l’emplacement de ma logique de validation.
Scénario n ° 1: l'ajout d'une annotation de données dans le modèle de vue (dans la couche d'interface utilisateur) simplifie grandement la programmation. Généralement, il y aura une correspondance individuelle entre DTO et le modèle de vue. Dans ce cas, l'option 1 est bonne. DL => DO => BL => DTO => PL => VM => V
Scénario n ° 2) Si la validation n'est pas attachée à ViewModels, DTO est remplacé par ViewModel et ViewModel réside dans la couche de gestion. DL => DO => BL => VM => PL => V
Le scénario 2 peut être parfait dans les situations où la logique de validation réside dans les modèles de domaine. Et ces modèles sont utilisés par de nombreuses applications d'interface utilisateur. L'interface utilisateur répertorie simplement les erreurs dans une liste, comme indiqué par la couche de gestion (pas très convivial cependant). Lorsque l'application subit des modifications aux règles métier, nous ne changeons que le modèle de domaine. Encore une fois, les validations liées à la base de données peuvent être générées automatiquement via EF (si vous utilisez .net), ce qui réduit encore la possibilité de modification.
Voir ici ma réponse: https://stackoverflow.com/a/14059156/1288063
Vous dites: Cette option semble être la meilleure pratique mais semble également lourde à maintenir.
lourd à mettre en œuvre peut-être, juste quelques lignes de code à dupliquer la plupart du temps, mais à maintenir sûrement pas.