manque une partie/couche dans mon application

Question

J'ai une application mvc asp.net avec trois couches: - couche de données avec des entités et dépôt (NHibernate) modèle - couche de service avec les services (fonctions), qui communique avec la couche de données . - couche ui avec l'application asp.net mvc, qui communique avec la couche de service.

Le problème est que les données dans mes entités sont différentes des données dans mes vues. J'utilise donc des ViewModels en forme personnalisée. Mais je n'aime pas la façon dont je cartographie la couche de service et les modèles de vue. Tout se passe dans l'action des contrôleurs. J'utilise AutoMapper mais je pense qu'il y a trop de code spaghetti. Permettez-moi de donner un exemple:

1.) J'ai un processus d'enregistrement d'utilisateur. J'ai un FirstName, LastName, Email, entrées OpenId qui correspond aux mêmes propriétés dans le ViewModel. Mais que je dois à différentes entités pour stocker ces données (une pour l'utilisateur, et une pour l'identité openid - l'utilisateur peut avoir plusieurs identités openid). Donc, dans mon action de contrôleur, j'ai un mappage (AutoMapper) entre un modèle de vue et une entité utilisateur et un mappage (AutoMapper) entre le modèle de vue et une entité openid. Après cela je sauvegarde chaque entité avec la fonction de service.

Il me manque quelque chose - comme un DTO personnalisé (je ne pense pas que viewmodel devrait être partagé entre la couche de service et la couche Web) qui sera passé entre le web et la couche de service.

2.) J'ai une fonctionnalité de recherche dans l'application. À partir de l'action du contrôleur, j'appelle la couche de service qui me renvoie la liste des entités de document qui correspondent aux critères de recherche. Mais encore une fois le problème est que je veux aussi afficher la catégorie (entité différente) pour chaque résultat. Donc, dans l'action du contrôleur, je suis en boucle entre les résultats et ajouter l'information de catégorie dans la structure IDictionary dans le modèle de vue.

Je manque aussi quelque chose ici - encore une fois DTO qui retournera la liste des paires (nouvel objet): document, catégorie.

Le motif DTO est-il correct? Devrais-je jeter un oeil à la DDD? Tout matériel connexe sera apprécié.

Merci beaucoup!

Answer 1

Je ne pense pas qu'il vous manque une couche dans votre architecture d'application, mais il semble que certains types (classes) vous manquent.

Faut-il créer plus de DTO? Non, je ne pense pas que ce soit une bonne idée. IIRC, la définition originale de DTO était de transférer des données à travers les limites du processus. Les contrats de données WCF sont un bon exemple de DTO. Cependant, étant donné que les DTO sont simplement des messages, ils ne contiennent aucun comportement. Si vous vous basez API interne sur DTO, il conduira à un Anemic Domain model.

Vous devriez envisager sérieusement d'ajouter de nouveaux types à votre application pour capturer vos besoins. Où devraient aller ces types?

Cela dépend. Si vous pouvez dire que le type en question encapsule un concept général , il appartient à un modèle de domaine. S'il existe seulement pour supporter une interface donnée (utilisateur), il appartient à cette couche.

Dans votre second exemple, vous devez combiner Document et Catégorie, bien qu'il s'agisse d'entités distinctes. Cette combinaison résume-t-elle un concept récurrent? Si c'est le cas, il appartient à votre modèle de domaine.Sinon, il appartient à votre couche d'interface utilisateur.

En cas de doute, placez le nouveau type dans la couche externe (votre couche d'interface utilisateur). Vous pouvez facilement le déplacer vers votre modèle de domaine s'il s'avère que c'est un concept plus général que vous ne l'imaginiez. Le déplacement dans l'autre sens est plus difficile car le type peut déjà avoir pollué le modèle de domaine, donc le démarrage dans la couche externe est l'option la plus sûre.