Pros and Cons of using ASP.NET MVC with Entity Framework?

Question

What are some pros and cons of using ASP.NET MVC with Entity Framework in .NET 4.0? Any 'gotchas' in live scenarios?

Answer 1

What I really like about ASP.NET MVC is:

• It forces you to use Separation of concerns;
• Full control of HTML output;
• It's easier to write unit test;
• Very extensible;
• Open Source :D
• NO VIEWSTATE! That means, faster browsing.

On the other side, I find WebForms more productive for large enterprise applications full of grids, ajax and web controls.

Answer 2

Bunch of new stuff like AjaxHelpers and AjaxExtensions that set the stage for some interesting things the community could do with ASP.NET MVC and Ajax. I'd like to see some JQuery love in there, maybe with some MVCContrib as they've been quiet lately.

PROS

1. Found much easier to do with MVC was to have multiple versions of a page that displayed the same data, but in a slightly different format.
2. MVC makes it simple to unit test the logic that is specific to a page. To do so, you simply test the actions in your controllers, which are regular, easy to test classes.
3. The best part about using an MVC framework is that everything in the web application has a standard structure and it is compartmentalized.

CONS

1. If you decide to convert your site to MVC, you may also run into issues trying to maintain existing page addresses.

2. spending some time writing rules that perform the necessary 301 redirects, because you don’t want to take chances with SEO (Search Engine Optimization).

3. One of the problems is that MVC frameworks can be incredibly bulky. They require a lot of files for everything to work properly.

Answer 3

I'm learning ASP.NET MVC at the moment on a personal project and am finding it great. I really like:

• Edit/Display templates
• Custom extension methods on HtmlHelper for various extras I want
• Integration with jQuery, making client-side extensions relatively straightforward

I'm also trying out EF4. It seems ok, though I would like better support for versioning database changes. I'm not using the POCO objects either, which means if you display an entity on the UI, you can't use the validation attributes (easily -- you can with a metadata type but it is ugly). I'm tending introduce ViewModel classes between entities and the View anyway, as they allow other types of supplementary data that do not belong in the entity.

Answer 4

With regards to the entity Framework, the early stages of developing apps where the model is frequently changing, is really easy with EF4. You code your models and controllers up first and then the framework can automatically create a basic view, and script up a database for you. This is a real boon to productivity.

Spooks point about bloat is really valid, not sure if this is specific to .NET MVC, but small project can quickly balloon to hundreds of files.

Answer 5

ASP.NET MVC is around for sometime. Entity framework 4.0 is just released. There is lot of push for both these technologies from Microsoft evangelists like Scott Guthrie and Scotth Hanselman.

Most of the examples of entity framework are shown using ASP.NET MVC as front end. Entity framework might not be as matured as some of the other ORM technologies like NHibernate. But I believe it is definately the next big thing that MS is pushing for.

Take a look at my blog about getting started with EF code first approach here Here is another link which can be used with existing databse schema and entity framework query databse using entity framework

Answer 6

I don't see that there could be any problems using the two together, since they deal with two opposite ends of the application, that shouldn't even need to know that the other exists.

If you ASP.Net code is properly factored, it's controllers should not be affected by whether the objects it uses come from EF or some other ORM.