Question

I’m building a MVC4 app, I’ve used EF5 model first, and kept it pretty simple. This isn’t going to a huge application, there will only ever be 4 or 5 people on it at once and all users will be authenticated before being able to access any part of the application, it’s very simply a place order – dispatcher sees order – dispatcher compeletes order sort of application.

Basically my question is do I need to be worrying about repositories and ViewModels if the size and scope of my application is so small. Any view that is strongly typed to a domain entity is using all of the properties within that entity. I’m using TryOrUpdateModel in my controllers and have read some things saying this can cause a lot of problems, but not a lot of information on exactly what those problems can be. I don’t want to use an incredibly complicated pattern for a very simple app.

Hopefully I’ve given enough detail, if anyone wants to see my code just ask, I’m really at a roadblock here though, and could really use some advice from the community. Thanks so much!

Answer 1

ViewModels: Yes

I only see bad points when passing an EF Entities directly to a view:

• You need to do manual whitelisting or blacklisting to prevent over-posting and mass assignment
• It becomes very easy to accidentally lazy load extra data from your view, resulting in select N+1 problems
• In my personal opinion, a model should closely resembly the information displayed on the view and in most cases (except for basic CRUD stuff), a view contains information from more than one Entity

Repositories: No

The Entity Framework DbContext already is an implementation of the Repository and Unit of Work patterns. If you want everything to be testable, just test against a separate database. If you want to make things loosely coupled, there are ways to do that with EF without using repositories too. To be honest, I really don’t understand the popularity of custom repositories.