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