Having spent a bit of time working on CMS (Umbraco and EPiServer) based projects, I recently had to come back to building a custom ASP.Net application using the MVC framework. Before commencing I took a bit of time to read around, and re-think some of the ways I've built applications like this previously, in terms of how the solution is architected.
Previously I've put together a fairly strict three layered architecture - data access layer using Entity Framework, wrapped in a unit of work/repository pattern; a business logic or service layer, and the presentation web application. Which worked quite nicely in truth, but there's always value in re-looking at such things and seeing how they could be improved. And where's the fun in doing things the same way each time anyway!
In particular I was keen to investigate:
- A CQRS style architecture, where we work with distinct query and command objects, in a more "slices over layers" fashion. This breaks the application down logically more vertically than horizontally, with features being grouped and having their own distinct classes.
- Better following the single responsibility principle, with smaller, more focussed classes.
- Removing the probably unnecessary wrapping of the Entity Framework context, which after all, effectively provides it's own unit of work pattern.
- In doing so, looking to use the Entity Framework context in a more discrete fashion, avoiding potential bugs and complexities that I've run into before. These can manifest themselves if you are keeping the context alive across different operations, or attempting to handle entities created directly from form posts rather than being pulled from the context.
- Working with a richer domain model that would play nicely both with Entity Framework and the presentation layer.
- Increased focus on unit testing.
Credits and further reading
In working up this new architecture, nothing was invented from scratch... rather I pulled together a number of different influences from various books and blog posts that led to the patterns described in this series of posts:
- Rob Conery's post on working with Entity Framework and repositories got me thinking about how best to work with the ORM in my application.
- Jimmy Bogard's series of posts on cleaning up your controllers led me to a version of the mediator/CQRS pattern he outlines.
- Adam Tibi provided a direct implementation of such a pattern for ASP.Net using the IoC container Ninject that I adapted slightly for my use.
- Finally got around to reading Eric Evans classic book"Domain Driven Design", and followed up with Julie Lerman's series of blog posts on working with these patterns with Entity Framework, and Jimmy Bogard's series of posts on a similar topic on Los Techies
Posts in this series
There will be three further posts in this series, where I'll discuss in more detail the certain aspects of the application patterns I'm now using.
- Firstly, the implementation of the CQRS pattern in ASP.Net MVC.
- Secondly, working with a rich domain model and Entity Framework.
- And lastly, discussing an increased focus on unit testing these aspects - directly on the domain model and utilising a library called Effort for creating unit tests on the data access and mapping code used in the query and command objects.