dépendances d'architecture de l'oignon dans la même couche: Infrastructure et communication Web

Question

Je suis la conception d'une application ASP.NET MVC en utilisant l'architecture Onion décrit par Jeffrey Palermo.

Il est un projet ASP.NET MVC 2.0, où je suis exigeant que toutes les opinions soient fortement typés à l'aide des modèles de présentation dédiée - nous ne transmettons les modèles de domaine à notre point de vue. Nous utilisons AutoMapper pour faire la traduction -. AutoMapper est isolée dans l'infrastructure, le Web ne sait pas ou soins AutoMapper est utilisé

À l'heure actuelle, je suis en train de définir les interfaces IViewModelMapping dans le projet Web - simplement parce que ce service sera utilisé par les contrôleurs et il a un accès direct à ses propres modèles de vue. De cette façon, l'interface peut accéder à la fois les modèles de domaine (en base) et les modèles de vue (dans le Web).

Afin d'assurer la mise en œuvre effective des interfaces IViewModelMapping, je crée un espace de noms ObjectMapping dans le projet d'infrastructure, qui isolera la mise en œuvre de la cartographie réelle à la intrastructure de l'oignon. Ce faisant, cela exigera une infrastructure d'avoir une dépendance sur les deux aInSI Web.

Ma question est: puisque ces deux projets sont techniquement à la périphérie de l'oignon (dans la même couche) - est un projet a permis d'avoir une dépendance à l'égard d'un autre projet dans cette couche? Est-ce que quelqu'un remarque des pièges potentiels avec cette conception?

Une autre conception déménagerait les interfaces IViewMapper dans le noyau - mais cela serait impossible, car de base n'a pas accès aux classes ViewModel. Je pourrais aussi déplacer la vue des modèles dans le noyau, mais je me sens comme ils ne feraient pas partie là, car ils sont spécifiques à la couche d'interface utilisateur.

L'architecture proposée est la suivante - remarquer que l'infrastructure a une dépendance sur aInSI Web. Web reste isolée et n'a accès à la logique métier de base.

http://www.matthidinger.com/images/onion-arch.png

Answer 1

Vous avez raison que vous ne voulez pas l'infrastructure à dépendre de l'interface utilisateur (Web), mais je briser cette règle parfois.

Je pense au lieu de IViewModelMapping, créez IMapper avec la méthode la carte (). Ensuite, l'interface peut avoir des implémentations qui pourraient avoir à faire avec vue sur la cartographie modèle, ou peut-être juste la cartographie régulière. De toute façon, cette interface peut être en cœur car il ne sémantiquement lié à tout type de modèle.

Grand graphique. J'espère avoir répondu la viande de votre question. La philosophie générale de l'oignon L'architecture est de garder votre logique métier et le modèle au milieu (de base) de votre application et poussez vos dépendances aussi loin que possible vers l'extérieur.

Answer 2

Essayez de déplacer mapping objet dans Web couche.

Answer 3

Votre couche Web / UI peut dépendre de la couche d'infrastructure. Mais ce n'est pas une bonne conception d'avoir la dépendance du Web sur la couche d'infrastructure. architecture oignon dit pousser vos dépendances aussi loin que possible vers l'extérieur.

Vous pouvez créer un dossier « \ Builder » dans l'interface utilisateur. Ajouter un fichier d'interface en elle, par exemple .. IBuilder ou IMapper et déclarer une méthode comme ConvertToViewModel ou CreateMapping en elle. tout ce que vous aimez.

* Builder ** IBuilder.cs -declare une méthode ici. ** Builder.cs - - mettre en œuvre le procédé ici, de définir un mappage entre ViewModel et il est DomainModel correspondant (référence de la couche de base) et de retour ViewModel approprié ici.