Is ADO.NET Entity Framework (with ASP.NET MVC v2) a viable option when writing custom and contantly updated websites?

Question

I've just finished going through the MvcMusicStore tutorial found here. It's an excellent tutorial with working source code. One of my favorite MVC v2 tutorials so far.

That tutorial is my first introduction to using ADO.NET Entity Framework and I must admit that most of it was really quick and straight-forward. However, I am worried about maintainability. How customizable is this framework when the customer requests additional features to their site that require new fields, tables and relationships?

I am very concerned about not being able to efficiently execute customer's change orders because the Entity models are basically drag-and-drop, computer generated code. My experience with code generators is not good. What if something goes haywire in the guts of the model and I'm unable to put humpty-dumpty back together?

In the long run, I wonder if using hand typed models which human-beings can read and edit is a more efficient course than using Entity Framework.

Has anyone worked enough with entity framework to say that they are comfortable using it in a very fluid development environment?

Answer 1

I have been using entity framework(V1.0) for about a year in my current project. We have 100s of tables,all added to the edmx. Problems we face (though not sure if the new entity framework resolves these issues)

1. When you are used to VS.net IDE, you will be used to doing all drag/drop operations from your IDE. The problem is, once your edmx hosts 100s of tables,the IDE really stalls and you would have to wait for 3-4 minutes before it becomes responsive

2. With so many tables ,any edits you do on the edmx take long.

3. When you are going to use a version control, comparing 10000 line XML is quite painful. Think about merging 2 branches each having a 10000 line edmx,the tables, new association between tables, deleted associations and going back and forth comparing xmls. You would need a good xml comparison tool if you are serious about merging 2 big edmx files

4. For performance reasons we had to make the csdl,msl and ssdl as embedded resources

5. Your edmx should have to be in sync with your DB all the time,or at least, when you try to update the edmx, it will try to sync and might throw some obscure errors if they are out of sync.

6. Be aware that your entities(tables/views) should always have a primary key, else you will get obscure errors. See my other question here

Things We did/I might consider in the future when using EF

1. Use multiple edmx by using 1 edmx for tables logically grouped/linked together. Be aware of the fact that if you do this, each edmx should live in its own namespace. If you try to add 2 related tables(say person & address) to 2 edmx in the same namespace, you will get a compiler error stating that the foreign key relationship is already defined. (Tip: create a folder and create the edmx under this folder. If you try to alter the namespace in the edmx without having the folder, it does not save properly the namespace the next time you open/edit it)

   fewer tables in edmx => less heavy
   container => good
   

   fewer tables in edmx=> easier to merge when merging 2 branches

2. Be aware of the fact that object context is not thread safe

3. Your repository (or what ever DAO you use) should be responsible for creating and disposing the container it creates. Using DI frameworks, especially in a web app complicated things for us. Web requests are served from the threadpool and the container were not disposed properly after the web request was served as the thread itself was not disposed. The container got reused (when the thread was reused) and created a lot of concurrency issues

4. Don't trust your VS IDE. Get a good XML editor and know how to edit the edmx file (though you don't need to edit the designer). Get your hands dirty

5. ALWAYS ALWAYS ALWAYS (just cannot emphasize this enough) run a SQL profiler (and I mean each and every step of your code) when you execute your queries. As complex as the query might look, you will be surprised to find how many times you hit the DB Example:(sorry, unable to get code to the right format,can someone format it ?)

   var myOrders = from t in context.Table where t.CustomerID=123
   

   select t; //above query not yet executed

   if(myOrders.Count>0)//DB query to find count { var firstOrder = myOrders.First()//DB query to get first result }

   Better approach

   // query materialized, just 1 hit to DB as we are using ToList() var myOrders = (from t in Context.tables where t.customerID=123 select t).ToList();

   if(myOrders.Count>0)//no DB hit
   {
   //do something
   var myOrder = myOrders[0];//no DB hit
   }
   

6. Know when to use tracking and no tracking(for read-only) and web apps do a lot of reads than writes. Set them properly when you initialize your container

7. Did I forget compiled queries ? Look here for more goodies

8. When getting 1000s of rows back from your DB, make sure you use IQueryable and detach the objectContext so that you don't run out of memory

Update:

Julie Lerman address the same problem with a similar solution. Her post also points to Ward's work on dealing with huge number of tables