ASP.NET MVC best practices using EntityFramework and mapped ViewModels

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 l开发者_JAVA技巧ayer)

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.

---

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.

---

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 :-)