My initial take on Entity Framework

Entity Framework Observations

  1. When using EF in a typical N-Tier application, you need to be careful to identify a strategy to allow objects to be dissociated from the object context. While the objects are connected to the context, the context can track changes to the entities, but once detached, you need to take special care to “attach” entities back to a context (or add new entities to a context). This requires custom code (although there are EF extension methods available to help with this).
  2. While in a standard N-Tier architecture, you would typically define different managers per entity (that would be responsible for fetching and persisting that entity); the pattern is somewhat different when using the EF. The manager responsible for the parent entity is the one that would typically invoke the fetch or save (which would in turn, fetch or save child objects as well). This also implies that while you can still distribute the responsibility of applying entity specific business rules to corresponding “managers”, you’d probably need to invoke those validations explicitly from the parent manager.
  3. The current EF version doesn’t really support lazy loading – when fetching an object, you need to explicitly identify all child objects that you want to load with the parent. The other option is to mark the attribute that represents the child as private, create a partial class for the entity and a property within it that represents the child. In the getter of that property, you can then write code to explicitly Load the child object. This also has its disadvantages since the deferred loading can only happen as long as the context is still present. In an N-Tier application where you may want to detach the object, you need to ensure that required child objects are loaded prior to detaching the parent. Note – In the next version of EF (4.0), ObjectContext will contain a property to better support deferred loading.
  4. Deleting a parent object and child entities is not very straight forward. EF will not “auto delete” the child entities for a parent. You either need to load the entire object graph and explicitly delete them from the context, or you need to use the “Cascade” on delete option available on the association in the database.
  5. More often than not, the model auto generated in the designer will not suffice. You will need to tweak it by hand, especially if you want to “normalize” your entities and define complex, reusable types. Note – The current version of the designer will not be able to display the graphical interface if you introduce complex types in the model.
  6. Always keep a back up of the last “good” EF model – as you make changes to it, some might need to be backed out, and this can take some effort if you’re new to EF.
  7. Once you call “SaveChanges” on the current instance of the ObjectContext, it automatically closes the underlying database connection. If you intend to reuse the same context to perform subsequent operations, you need to explicitly open the connection again. Here’s where the use of AOP frameworks such as PostSharp can help – you can add a handler for every method entry, where you want to check the connection and open it if it is closed.
  8. Expect to write or leverage several extension methods for basic EF objects such as EntityObject, ObjectContext, EntityKey etc.
  9. The next version of EF is going to have several useful features, such as support for writing POCO (Plain Old CLR Objects), instead of having to use “heavy duty” Entity Objects all the time.
  10. It saves significant time in developing a custom data access framework, and using Entity SQL/ LINQ, it’s possible to shape queries dynamically, without having to write underlying code each time you want to fetch a different sub-set of attributes for an object. A lot of the thinking and effort behind setting up custom data access code goes away.
  11. Ties in very well with ADO.Net Data Services and out of the box presentation controls that can use the EntityDataSource for instance
  12. The framework tracks changes implicitly and is therefore able to perform selective updates/inserts, rather than making the developer either set explicit flags (to track changes) or issuing DB calls to over-write unchanged entities as well.
  13. There are a couple of “one –time” (or less frequent) activities that require some time (i.e. creating the model, implementing basic extension method requirements, strategy for detached objects etc.), but once that is setup, development time does reduce significantly.


Entity Framework

  1. Cascade Delete
  2. Entity Framework FAQ
  3. Data Points: Entity Framework Q&A
  4. ADO.NET Entity Framework and LINQ to Entities Forum
  5. How to: Pre-Generate Views to Improve Query Performance (Entity Framework)
  6. How to: Manually Configure an Entity Framework Project
  7. Programming Entity Framework
  8. ADO.Net Team Blog
  9. Entity Framework Design Blog
  10. Entity Framework 4.0 Preview

Entity Framework versus LINQ

  1. ADO.NET Entity Framework – When To Use It vs. Linq to SQL
  2. Is This Thing On? : LINQ to SQL vs. ADO.NET Entity Framework
  3. Entity Framework vs. Linq to SQL – Wortzel’s blog
  4. LINQ to Entities vs. LINQ to SQL – What should I use and when? [The .NET Addict’s Blog]
  5. DotNetSlackers: Entity Framework vs. Linq to SQL

Entity Framework versus NHibernate


Mapping in Entity Framework

  1. Mike Taulty’s Blog : Mike’s ADO.NET Entity Framework Mapping Table – This is a particularly good summary of how mapping works with EF
  2. Mapping split tables to one entity – Willem Meints – blog community
  3. Working with Ids in the Entity Framework
  4. ADO.NET team blog : Working With Large Models In Entity Framework – Part 2
  5. ADO.NET: Achieve Flexible Data Modeling with the Entity Framework

Querying the Entity Framework

  1. How to: Execute a Query that Returns an Anonymous Type (Entity Framework)
  2. Entity SQL Language
  3. Query Builder Methods (Entity Framework)

Transaction Management

  1. Managing Connections and Transactions (Entity Framework Tasks)
  2. CodersLife : Why doesn’t TransactionScope work with Entity Framework?

Extension Methods

  1. ADO.NET Entity Framework Extensions – Home

N-Tier Design


Attaching & Detaching Object Graphs

  3. Perseus: Entity Framework EntityBag – Home
  4. Jaroslaw Kowalski : Transparent Lazy Loading for Entity Framework – part 1
  5. SingingEels : Entity Framework and Lazy Loading

~ by calvhobbes on June 17, 2009.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: