During the past couple weeks at work, I’ve been migrating a solution from NHibernate to Entity Framework. I’ve been learning a lot, and it’s been quite enjoyable. There are some things I like about Entity Framework, but there are some things that I’ll miss from NHibernate. There are also some issues with the Entity Framework that I’ve been having.
There are several bright spots I’ve been seeing from using the Entity Framework.
- I like how you can use a designer to create the entity classes and map them to table. It makes it so easy. It retrieves a lot of the schema from the database for you, which is nice.
- The code generation is nice. It creates the classes for me. There’s also options to pre-compile queries to boost performance.
- The entity framework can create self-tracking entities that keep track of changes as you make them. This is something I have wished for.
I’ve gotten used to NHibernate over the past four years of using it; so naturally, I would miss it. True, there was a steep learning curve at the beginning. I learned things such as the mapping syntax, HQL and remembering to marking the .hbm.xml files as embedded resources (that last one gets me every time). But after all that, there’s practically no schema that NHibernate can’t handle. There are a couple features from NHibernate that I miss.
- I miss absolute control. NHibernate will let you configure it however, but it just may not work when you run it. On the other hand, the Entity Framework is very strict on what changes it will allow (especially in the designer), which is very much like Microsoft. For example, it insists that the schema is not configurable and should only come from the database.
- I miss NHibernate’s relationship mapping. Once the relationship is set up in the mapping file correctly, it’ll work no matter what’s thrown at it (inserts, updates and cascading deletes). With entity framework, there a few extra steps involved (especially with the cascading deletes).
Because entity framework is very new, there are still some big issues in using it. Some of it may be from using an Oracle database, but that shouldn’t matter.
- Every time you update the entity model from the database you have to close the designer and open it in XML to add the StoreGeneratedPattern=”Identity” to every primary key column reference. It’s very annoying. I’m guessing Microsoft will include a fix for this in the next Visual Studio service pack.
- There’s a defect in the class generation template for self-tracking entities. There’s a scenario wherein the namespace (containing periods) of the child class is used as part of a method name, and it doesn’t compile. For this, I had to edit the template.
- There’s not much configuration with how connections are used. By default, a new connection is used every time there’s a save to the database. This quickly consumes the connection pool. I’m not sure what to do for this yet. I wish there was smarter connection management out-of-the-box.