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

Question

Hello SO,

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'm not too familiar with Entity Framework, but I believe it simply generates an EDM file which can be hand-edited. I know I've done this quite frequently with the Linq-to-SQL DBML files that the designer generates (it's often faster to hand-edit them than use the designer for small tweaks).

Answer 2

You know I'd be interested if any developers can provide some insight into this. Any Entity Framework examples seem to only consist of about ten to twenty tables, which is small scale really.

What about using the EF on a database with hundreds or even a thousand tables?

Personally, I know several developers and organisations that were burned by LINQ-to-SQL and are holding off for a year or so to see what direction EF takes.

Answer 3

Starting from Entity Framework 4 (with Visual Studio 2010), the generated code is outputted from T4 (Text Template Transformation Toolkit) files which you can edit so you have full control over what is generated. See Oleg Sych's blog which is a mine of information about T4. Code generation is not a problem and T4 opens so many perspectives that I can't live without anymore.

I'm currently working on a project where we use Entity Framework 4 for the data access layer, and Scrum as the agile project management method. From one sprint to another, there are several tables added, other modified, new requirements added. When you have run once into each potential EF problem (like knowing that default values from database are not persisted by default in the .edmx file, or changing a nullable column to a non-nullable and updating the designer doesn't change the mapped property state), you're good to go.

Edit: to answer your question, it's EF 4 whose code generation is based on T4 rather than T4 supporting EF. On EF 3.5 (or EF 1.0 if you prefer), you could in theory use T4 by writing them from scratch, parsing the EDMX file in the T4 code and generate your entities. It would be quite a lot of work considering all of this is already done by EF 4. Plus, Entity Framework 3.5 only supports one type of entitiy, whereas EF 4 as built in or downloadable templates for POCO entities (that don't know anything about persistence), Self-Tracking Entities...

Considering Entity Framework itself, I think it was lacking many features in its first release, and while usable, was quite frustrating to use. EF4 is much more improved. It still lacks some basic features (like enum support), but it has become my data access layer of choice now.

Answer 4

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