May 6, 2010 at 10:44 AM
Edited May 6, 2010 at 12:53 PM
In WCHM - we put together a real world architecture based on a MVC project we built last year - it was much, much larger than WCHM (6 devs working for 6 months). We came up with architecture to give the best testability, reusability and separation of concerns
we could using this technology stack. We think it worked out rather well.
Architecturally - we're of the opinion that you should not have repositories in controllers - because your business logic (or infrastructure logic) is now in your presentation layer - your presentation layer should literally only recieve input, decide an
action, and decide what view to display as a result of that action. This leaves your controller very thin, and very testable. Make them do one thing only and do it well.
For us the presentation layer is the combination of view engine and controller (hence why they are in the presentation solution folder) - VM are purely a dto for sending data to the view to be rendered - nothing else - the Model - is our Domain Model - which
I guess is where we diverge from MS's boilerplate MVC architecture and use concepts from Domain Driven Design.
The Tasks layer is really where reusable logic sits - this is essentially an orchestration layer - where you would write a series of tasks, doing business logic, data access, external service calls etc. Mappers are used to keep the boundaries clean.
Hope this info helps - post again if you need any more clarifications or you think I've missed some point.