Question

I’ve been digging into ASP.net MVC for a little while now. It seems that most blogs and posts indicate that a “best practice” is to abstract away the Entity Framework by implementing the Repository Pattern. It also seems the recommended practice is to utilize View-Specific models instead of working directly with the EF Domain Entities.

It makes some sense because you can than implement a transparent layer of Caching in the Repository, your MVC app doesn’t need to know anything about Entity Framework, and the View-Specific POCO models don’t have all the EF methods and properties attached to them (which tend to mess up XML and JSON serialization).

But if that is the way people “should be” developing, why are all the Controller/View wizards and tooling in Visual Studio focused directly on Entity Framework? Why do all the Microsoft examples on http://www.asp.net/mvc seem to work directly with the framework and domain entities instead of creating repositories with caching and utilizing view specific models?

Also, if I should be using view-specific models, am I mapping the domain entities onto those models in the controller? Isn’t it inefficient to be returning an object graph to the controller if I only need certain fields? Or should I be creating view-model specific methods on my repository?

Answer 1

Why do all the Microsoft examples on http://www.asp.net/mvc seem to
work directly with the framework and domain entities instead of
creating repositories with caching and utilizing view specific models?

Unfortunately I cannot answer this question as I am not a Microsoft employee working on the Visual Studio team creating those wizards nor publishing content on the http://asp.net/mvc site. Personally I am allergic to 99% of the wizards in Visual Studio and never touch them.

Also, if I should be using view-specific models, am I mapping the
domain entities onto those models in the controller?

Yes. Alternatively you could use AutoMapper to simplify this process and unclutter your controller actions.

Isn’t it inefficient to be returning an object graph to the controller
if I only need certain fields?

No, it is efficient. As a matter of fact it’s even faster (in terms of performance) than if you were mapping to a view model. It’s just that in most cases your domain models are not adapted to the requirements of your views. And from that moment the nightmare will start inside your views which will turn into spaghetti code in attempts to adapt those domain models – your views become now inefficient and not easily maintainable. You will quickly realize that the domain models do not contain all the necessary information the view needs. And what happens next? You start using another concept I am allergic to – ViewBag. So you are passing certain things to the view under the form of a strongly typed model, other things under the form of a weakly typed structures, things get messy. Also controller actions taking domain models instead of view models are vulnerable to mass injection attacks and you might be having troubles with things like validation.

Or should I be creating view-model specific methods on my repository?

Absolutely not. A repository works only with domain models. It doesn’t know what a view model is.

Of course all those are my 2¢. Feel absolutely free to ignore them and work directly with your EF domain models inside your views if this is the pattern that suits you better and you feel more comfortable with. It would be incorrect trying to impose one or another pattern. Just use the one you feel right for your needs.