Question

I am designing an ASP.NET MVC application using the Onion Architecture described by Jeffrey Palermo.

It is an ASP.NET MVC 2.0 project, where I am requiring that all views be strongly typed using dedicated View Models -- we will not be passing domain models to our views. We are using AutoMapper to do the translation -- AutoMapper is isolated in the infrastructure, Web does not know or care that AutoMapper is being used.

Currently, I am defining the IViewModelMapping interfaces in the Web project -- simply because this service will be used by the Controllers and it has direct access to its own View Models. This way the interface can access both the Domain Models (in Core) and the View Models (in Web).

In order to provide the actual implementation of the IViewModelMapping interfaces, I created an ObjectMapping namespace in the Infrastructure project, which will isolate the actual mapping implementation to the Intrastructure of the onion. In doing so, this will require Infrastructure to have a dependency on BOTH Core AND Web.

My question is: since both of these projects are technically on the outskirts of the onion (in the same layer) -- is one project allowed to have a dependency on another project in that layer? Does anyone notice any potential pitfalls with this design?

An alternative design would be moving the IViewMapper interfaces into Core -- but this would be impossible because Core does not have access to the ViewModel classes. I could also move the view models into Core, but I feel like they would not belong there, since they are specific to the UI layer.

The proposed architecture is as follows -- notice that Infrastructure has a dependency on Core AND Web. Web remains isolated and only has access to the Core business logic.

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

Was it helpful?

Solution

You are correct that you don't want Infrastructure to depend on UI(Web), but I break that rule sometimes.

I would think instead of IViewModelMapping, create IMapper with method Map(). Then, the interface can have implementations that might have to do with view model mapping, or maybe just regular mapping. Either way, that interface can be in Core because it is not semantically bound to any type of model.

Great graphic. I hope I answered the meat of your question. The overall philosophy of the Onion Architecture is to keep your business logic and model in the middle (Core) of your application and push your dependencies as far outward as possible.

OTHER TIPS

Try to move Object Mapping into Web layer.

Your Web/UI layer can be dependent on Infrastructure layer. But it's not a good design to have dependency of Web on Infrastructure layer. Onion architecture says push your dependencies as far outward as possible.

You can create a "\Builder" folder in UI. Add one interface file in it,example.. IBuilder or IMapper and declare a method like ConvertToViewModel or CreateMapping in it. whatever you like.

*Builder **IBuilder.cs -declare a method here. **Builder.cs -- - Implement the method here,define mapping between a ViewModel and it's corresponding DomainModel( reference from core layer) and return appropriate ViewModel here.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top