ASP.NET MVC application architecture "guidelines"
- by Joe Future
I'm looking for some feedback on my ASP.NET MVC based CMS application architecture.
Domain Model - depends on nothing but the System classes to define types. For now, mostly anemic.
Repository Layer - abstracted data access, only called by the services layer
Services Layer - performs business logic on domain models. Exposes view models to the controllers.
ViewModelMapper - service that translates back and forth between view models and domain models
Controllers - super thin "traffic cop" style functionality that interacts with the service layer and only talks in terms of view models, never domain models
My domain model is mostly used as data transfer (DTO) objects and has minimal logic at the moment. I'm finding this is nice because it depends on nothing (not even classes in the services layer).
The services layer is a bit tricky... I only want the controllers to have access to viewmodels for ease of GUI programming. However, some of the services need to talk to each other. For example, I have an eventing service that notifies other listener services when content is tagged, when blog posts are created, etc. Currently, the methods that take domain models as inputs or return them are marked internal so they can't be used by the controllers.
Sounds like overkill? Not enough abstraction? I'm mainly doing this as a learning exercise in being strict about architecture, not for an actual product, so please no feedback along the lines of "right depends on what you want to do".
thanks!
Jason
