MVC Project Architecture
Posted by coreycoogan on June 5, 2009
The MVC project I’ve talked about in my first 2 posts is still moving along. I’ve continued to learn all I can about the new ASP.NET framework, but have a lot to learn. It’s very different (read:better) from the MVC I used to do 5 years ago in the JSP days.
As the rest of the team ramps up, I thought it was important to layout the application architecture. Being a fan and student of Domain Driven Design, I followed many of the patterns discussed by Evans, as well as others. The app requires a WCF service layer, so most the typical layering will reside behind the Service layer. We’re also using LLBLGen, with Linq, as an ORM. The client is anti NHibernate, so some other ORM had be chosen and in my opinion LLBLGen is the best database driven ORM around.
The app is an enterprise critical application and I’m trying to architect in a way that will support growth, foster SOLID principals and be easy to maintain. Here’s the layers we’ll be using, with a description of each.
app.web (mvc)
app.web.controllers – has controllers for MVC.
app.application – DTOs, WCF service gateway, interface for WCF proxies. Controllers will take WCF service proxy interfaces via DI.
app.service – WCF service that sends/recieves DTO’s defined in app.application. Maps DTO’s to domain objects and interacts with the next layer to call Application Services.
app.service.application – application layer for the WCF service. Contains application services that act as a facade to the domain (core) layer. This is where all infrastructure and domain functions are coordinated.
app.core – where domain objects and repository interfaces live. This is where all business logic is essentially stored.
app.infrastructure – where the repository implementations live, as well as email gateways and other infrastructure stuff.
Josh said
How is the project going? We’ve been using LLBLGen in an ASP.NET MVC project for a large business services app for the past 6 months and are pretty happy with it so far. Out of curiosity, are you using an IoC framework (like StructureMap or Unity), or just injecting the various dependencies manually through default c-tors? Also, how are you handling transactions? So far that’s been our biggest struggle since the trx often must reside at the controller/session level, but the adapter is down in our service layer (your app.core layer).
Good luck!
coreycoogan said
Hi Josh,
the project I outlined here changed quite a bit after I was pulled away from it. The architect had different ideas about what a layered application looks like and the team was rather junior, resulting poor man’s DI rather than using the StructureMap container that was already available to the project. Everything that I wrote, however, leveraged SM for all DI. Check out my post on Castle to see how I’m doing that stuff in latest project.
LLBLGen is a pretty good ORM, although I like SubSonic more. Unfortunately, the team decided that EntityFramework was better than LLBLGen and decided to use that later in the project. I absolutely hate EF and think LLBLGen is a much stronger ORM, but it wasn’t my call.
As far as your transactions go, I think your architecture may be causing you these hassles. First, you adapter should probably be in an Infrastructure layer, not your Core layer. Your Core layer should be your Domain objects, or in this case LLBLGen entities. You would then have an Application Layer that provides application services. It is these services that would be responsible for opening the transaction, calling the applicable operations (passing the repository or transaction) and then committing. I would steer clear from managing transactions in the UI.