EF entities as domain-models, when decoupling them from views with view-models?

I'm trying to understand the best architecture for my MVC2 site.

As I have been experimenting with getting the data in and out of a database with Entity Framework, I am beginning to realize the simple domain-models I have so far constructed do not map to all the needs of my planned views. So I am considering following the accpepted answer to this question: Why Two Classes, View Model and Domain Model?.

But there seems to be redundancy with little payoff that I can perceive between the domain-models and the EF models, and I can't even hardly understand the conceptual difference. I do NOT have as a requirement the need to switch data sources down the road, and I do not forsee the need to switch my ORM solution either.

QUESTION:

If I follow this pattern then, since I am using Entity Framework, shouldn't I just use my EF entities to serve directly as the domain models? (note: I haven't thought through the "how" of that, but answers there are welcome too.) Or am I still advised to manage a separ开发者_如何学运维ate set of domain-models?

It seems you've got some redundancy here. Reading your paragraph:

But there seems to be redundancy with little payoff that I can perceive between the domain-models and the EF models, and I can't even hardly understand the conceptual difference.

I would argue that there is no real difference between the EF Model and your Domain Model. In the projects I create, my EF Model is my Domain model.

However, my Domain model classes are not the same as my ViewModels. The Domain model class might contain data that is not interesting for the View, or maybe the view needs information that is calculated/evaluated based on information in view. A simple example might be:

public class Session // Domain model (and EF Model
{
    public int Id {get; set; }
    public DateTime Start {get; set; }
    public int DurationInMinutes {get; set; }

}

public class SessionViewModel // The viewmodel :p
{
   public DateTime Start {get; set; }
   public int DurationInMinutes {get; set;}
   public DateTime End 
   {
       get
       {
            return Start.Add(TimeSpan.FromMinutes(DurationInMinutes));
       }
   }
}

In this example I'm interested in displaying the actual End-time in my View, but I have no interest in storing it in the database, as that might lead to data-discrepencies (DurationInMinutes + Start might not equal End if data is corrupted upon saving)

When I first started coding this way, I ended up doing alot of manual work mapping my Domain models to ViewModels, and back. AutoMapper changed all that :) Google it, or NuGet it and it will make your life a whole lot easier :)

Hope this helps a little. Please comment if I'm totally missing the point :)

Update to address the comment

DataAnnotations would then be applied to the ViewModel, because normally DataAnnotations denote how the data should be displayed and validated in the View.

For instance you would put the [Required] attribute on public DateTime Start {get; set;} in order for the Html.DisplayFor extensions automatically validates your HTML according to your dataannotations.

By definition (by some anyway) the Domain Model should not contain any code or logic related to your business logic. The Domain Model is simply responsible for containing the data pretty raw according to your datastore. Personally I like to put some sort of Service layer inbetween that is responsible for fetching the data and returning ViewModels, and also doing the reverse.

The ultimate goal is to avoid referencing your domainmodel directly from your controllers.

Of course, all these points has to be weighed in reference to the size of the project. It's certainly overkill to do all this just to mock up a test-site - but in any other project where you'll actually be deploying something that might scale, expand or otherwise change, it's a good practice to get used to, as it seriously increases your ability to do so.

Another key point to this approach is that you are forced to abstract your operations down to smaller and more managable units, enabling better and more precise unit-tests.