3

I've never worked with MVC design pattern before and recently I started to work on the project using ASP.NET MVC.

I'm using ActiveRecord as my data layer.

I'm also using view models (unique for each view) and AutoMapper to map my view models to EntityFramework entities.

In a few days reseaching about MVC, EntityFramework and reading different articles I came up with the following design:

In my solution I have Web project (Presentation Layer) which contains Views and Controllers.

I have Core project where I define my ViewModels and Services (Business layer where all business logic goes)

I have EntityModels project where all me EF entities live (Data layer)

This design allows me to keep my Data layer separate from my Presentation layer, Web project doesn't know anything about EntityModels project and vise versa, all the logic lives in business layer.

From my controllers (after validation checks) I pass viewModels to Service layer where mapping and all necessary busines logic is executed.

Is this design correct at all?

My consern is that I've read that ViewModels should be defined in Presentation Layer. I saw examples where Presentation Layer has references to Data layer and mapping is done in controllers (good practice?). in this case controllers pass domain models to business layer. I don't have any experience here but I don't like it.

So, can anyone point out where I'm right and where wrong?

thanks in advance.

tereško
  • 58,060
  • 25
  • 98
  • 150
Burjua
  • 12,506
  • 27
  • 80
  • 111

2 Answers2

3

Overall the architecture looks good. The decision on where to place you view models hinges on one factor in my opinion.

Do you plan to have other clients in the future that may benefit from reusing those view models (iPad, Android, etc.)?

If so, definitely keep them out of the MVC assembly and put them in their own assembly. Otherwise, you're safe putting them in the MVC app as long as you're ok with moving them and changing code if you ever decide to make a second client.

For the record, I always put my view models in their own assembly. It doesn't take more time up front, but it pays dividends down the road if things change.

Craig M
  • 5,598
  • 4
  • 32
  • 43
  • Yes, all my view models are in separate assembly under their own namespace – Burjua Jul 12 '11 at 16:39
  • @jfar Build time, seriously? What kind of dinosaur machine do you code on? No offense, but I completely disagree with your entire comment. There is no more complexity in adding an additional assembly and build time is so minimal, especially for an assembly that's going to hold simple view models, that it really seems like you're trying to find a reason to disagree with this answer. If you don't have a few seconds to spare during a build, you're doing things drastically wrong. – Craig M Jul 12 '11 at 19:21
  • @Craig M, when you build hundreds of times a day every additional second counts. Projectitus, creating a project for every little thing without a valid physical reason ( the only reason to make a new project rather than a folder ), is very bad practice. Your slowing down build times for the rare chance you'll save 15 minutes in the future. Not worth it. – John Farrell Jul 12 '11 at 20:04
  • Assuming "building hundreds of times a day" equates to a minimum of 200, that means you're building once every 2.4 minutes in an 8 hour day or you're greatly exaggerating. I agree that some developers have Projectius and I'm not a fan of that practice, but something as core to a system as models definitely warrants its own assembly. – Craig M Jul 12 '11 at 20:48
1

FWIW, I am doing the same thing - but I am new to MVC, so not 100% sure I'm on the right path also. But, it just "feels right", which more often than not tells me it is correct. The only thing I would add is that I use automapper (automapper.org), which almost eliminates the overhead of having the layers. Definitely check it out IMO. I have to say the only thing that doesnt feel 100% correct is that with this pattern, we are creating a whole lot of ViewModels -> one per View. I assume you mean that Create, Index, Update, Details for each domain entity EACH have their own ViewModel? Or are you sharing one ViewModel between the views? Lastly, I dont buy jfars argument that it creates lots of complexity/build time. At the very least, it conceptually separates the layers that much more. It strikes me as a much better job of separating the concerns, with very little overhead.
I have a pipe dream of reusing the viewmodels for a silverlight implementation, but havent really thought that one through yet. But it makes sense that if you do a good job of factoring out all "non-UI" code into the viewmodels and services, then doing a new UI should be "trivial", right? we'll see :-)

Joe
  • 321
  • 3
  • 12
  • 1
    Whoops, just re-read your question, and you are already using automapper - my apologies – Joe Sep 16 '11 at 00:27