I’ve been reading a few things about ASP.NET MVC, SOLID and so on, and I am trying to figure out a simple ‘recipe’ for small-to-medium ASP.NET MVC apps that would put these concepts together; the issue that I am most concerned with is ending up with controllers that are too complex and being like code-behind files in webforms, with all type of business logic into them.
I am considering the following architecture, for a small data-driven app:
- Controllers: only handle requests, call an appropriate service and return the action result to the View;
- Models: POCO, handle all the business logic, authorization etc. Depends on repositories, totally ignorant of persistence infrastructure.
- Repositories: implement
IRepository<T>, use dependency injection and is where my db code will reside; only receives and returns POCO.
I am considering having services between the controllers and the models, but if they will just pass forward method calls I am not sure how useful it would be.
Finally there should have unit tests covering the model code, and unit+integration tests covering the repository code (following the ‘red-green’ practice, if possible)
Thoughts?
Ian Cooper had a good post on exactly this recently:
The Fat Controller