ASP.NET MVC application architecture "guidelines"

Posted by Joe Future on Stack Overflow See other posts from Stack Overflow or by Joe Future
Published on 2010-04-04T14:37:14Z Indexed on 2010/04/04 14:43 UTC
Read the original article Hit count: 368

Filed under:
|

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

© Stack Overflow or respective owner

Related posts about asp.net-mvc

Related posts about architecture