The last few weeks, I have worked on a project that uses Entity Framework 4 Code First (let’s call it EF from now). Normally, I use NHibernate for my OR-mapping needs and although EF works almost the same conceptually, there are differences. This post is about some of the issues that an NHibernate user can expect when working with EF.

Many to one associations and introduce a foreign key property

Let’s say it bluntly: EF supports Foreign Key associations  (foreign key id’s in your entities, besides many to one associations)  and you better use them, or you’ll experience a lot of pain. I started to model my entities with ‘proper’ object references but ran into 2 problems:

• Filtering in collection properties causes select n+1 issues. So forget:
  

  Order.OrderLines.Where(ol => ol.Product.Id == productId)

  but do:

  Order.OrderLines.Where(ol => ol.ProductId == productId)

  to filter a collection property because the first will load all product instances;

• When you override Equals() and GetHashCode()in your entities to use only the ID for object equality, you can assign an empty object with only the ID set as reference property in NHibernate but EF doesn’t fall for this trick. This is can be very useful, for example when setting references from a dropdownlist where you only have an ID of the referenced object.

It seems that EF just doesn’t leverage proxies like NHibernate does so it needs to have the actual object instance to do things instead of just the proxy.

The good thing however is that when you’re having both a foreign key ID property and an object reference in EF, these are synced automatically and only one column will be generated in the database and the only real issue is a little pollution of your entity.

Object reference not set to an instance of an object

So you’ve created a nice object graph and saved it in the database. Then after fetching the object graph back, some of the referenced objects are null even when the ID’s of the references are nicely sitting there in the database. WTF???

Well, EF doesn’t automatically load a referenced object unless it’s marked as virtual (lazy) or loaded explicitly via Include(). If you forget both, you’ll end up with the NullReferenceExceptions.

No Dictionary collection mapping

This is something not many people complain about, but I really miss the option to map dictionaries like Map in NHibernate. Also, NHibernate’s List mappings are not supported.

Cascade is a big black box

EF doesn’t have a way to specify how changes in your entity are cascaded into related entities. I’m not sure if this is a good or a bad thing. On one hand I miss having control over this, but on the other hand EF seemed to do well without setting anything.

Out of the box, EF code first generates CASCADE  DELETE database constraints on required associations but when your model gets only a little bit complex, you’ll get errors like “Introducing FOREIGN KEY constraint on table may cause cycles or multiple cascade paths”. Fortunately, you can turn this off in your DbContext:

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
    // Remove cascade delete convention because it causes trouble when generating the DB.
    modelBuilder.Conventions.Remove<OneToManyCascadeDeleteConvention>();

    base.OnModelCreating(modelBuilder);
}

Explicitly set state when attaching objects to the DbContext

In NHibernate you can simply update an object that isn’t associated with a Session via Session.Update(). EF can do the same via Attach() but you must not forget to explicitly set the object state to modified, otherwise no updates occur:

dbContext.Customers.Attach(customer);
dbContext.Entry(customer).State = EntityState.Modified;
dbContext.SaveChanges();

More?

Please leave a comment if you want to share your own experiences.

Just a little post to let you know that I released the first Alpha of the next generation of the Cuyahoga CMS yesterday. For the people who don’t know Cuyahoga: it’s a .NET CMS that uses lots of Open Source components like NHibernate, Castle Windsor and Lucene.NET. Although not as polished as Umbraco or Dotnetnuke, I think it still shines when doing custom module and template development.

Development has been a long journey. Already back in 2006 we started development for the 2.0 version. In that time most of the work was done by Max Gaerber. He did a fantastic job in the design of the generic handling of content items.

Then somewhere in 2007 we started the new admin with Castle Monorail, did a spike with the first ASP.NET MVC, changed back to Monorail and finally changed to ASP.NET MVC again. The switch from ASP.NET WebForms to MVC for the site admin allowed us to do some pretty advanced AJAX stuff. The result is still a little rough around the edges, but it’s usable for experimental purposes.

Download it at http://sourceforge.net/projects/cuyahoga/files/.

About a year ago, a few people (called by some as ‘The NHibernate Mafia’) wrote a vote of no confidence against the Microsoft ADO.NET Entity Framework (EF), mainly because a big influential company like Microsoft was releasing an inferior tool set. See the text of the petition for the detailed reasoning.

My initial thoughts were ‘why worry, there are plenty alternatives like NHibernate, LLBLGen Pro or LINQ to SQL’ and although I agree with the content of the vote of no confidence, I decided not to sign. That was until realized that as a contractor, you often have to confirm to the technology that the customer has adopted, so it’s to be expected that a lot of future projects have EF as their O/R mapping layer because ‘Microsoft says it’s the way to do data access’. I signed and yes, it’s the selfish me that made me do it.

So now we’re one year later and I just started on a new contract where EF is being used and as I already feared one year ago things are not pretty. The previous developers seem to have struggled a lot, which resulted in poor performance and lots of workarounds.

And you know what: I don’t blame EF itself or the developers but only Microsoft marketing for labeling the Entity Framework as the ‘preferred magic way to do data access’ and all the surrounding blah of future products that will build on EF so people blindly take it as their weapon of choice.

Sorry for this somewhat negative post, but I had to write this off.

Many web hosting companies only allow ASP.NET applications to run under medium trust. This has been a major drawback for Cuyahoga because it required full trust (or better: some libraries require full trust). This has already caused some nasty surprises when people deployed their site to the host to find out it would not run.

Well, I can finally say that Cuyahoga 2.0 will work under medium trust!

Castle DynamicProxy

Last week, someone mentioned on the Castle users list that DynamicProxy was supposed to work under medium trust and this immediately triggered me. DynamicProxy had always been the key part that prevented Cuyahoga, NHibernate, and lots of other software from running under medium trust because it generates assemblies on the fly and that’s not allowed (at least pre-NET 2.0 SP1).

So, I checked out a fresh version of the Castle trunk, built it with AllowPartiallyTrustedCallers and copied the assemblies to Cuyahoga that was set to run under medium trust.
Unfortunately, still no luck. The dreaded SecurityException showed its yellow screen, but instead of giving up immediately, I took a deep breath and started digging the DynamicProxy sources. The solution was a simple one: DynamicProxy calls AssemblyBuilder.DefineDynamicModule and used the overload that generates debug symbols. Changing that to not generate the debug symbols anymore made it work under medium trust! I send a patch to the Castle guys and lets hope it can be incorporated. This allows NHibernate to run under medium trust without turning off lazy-load on class mappings or using a special proxy generator.

One caveat: the Castle trunk requires .NET 3.5, so we can’t fix it for the 1.6.x branch of Cuyahoga which is .NET 2.0.

Lucene.Net

Second, Lucene.Net didn’t work under medium trust and boy, that was easy to fix: a single call was made to a relative file path, which is not allowed. Changed that to use the full path and it worked. Submitted a patch and I hope they will accept it.

Cuyahoga

So, with the libraries working under medium trust, I was ready to roll, at least I thought so. It appeared however that Cuyahoga also did some nasty things that are not allowed under medium trust, such as requesting a HttpModule instance from the appdomain and some file access outside the application root. Fortunately these were easy fixes and now I have everything working just fine under medium trust.

I think, I’ll leave medium trust turned on in the development version to signal issues in an early state.

Recently, I ran into an issue with NHibernate Criteria queries. The scenario is the following:

User has a many-many association with Role and Role has a many-many association with Site. I simply wanted all users that belong to a given site (and a whole slew of other optional parameters, therefore the Criteria query).

With hql this is simple:

select distinct u from User u join u.Roles r join r.Sites s where s.Id = :siteId

With a criteria query, it appeared a little bit harder. First I tried this:

ICriteria crit = session.CreateCriteria(typeof(User))

    .CreateCriteria("Roles") // traverse into Roles

        .CreateCriteria("Sites") // traverse into Sites

            .Add(Expression.Eq("Id", siteId);

Note the absence of the distinct keyword anywhere in the query. A nice Cartesian Product was the result due to the joins on the linking tables. Some googling showed that we can get distinct results with Criteria queries by applying the DistinctRootEntityResultTransformer via Criteria.SetResultTransformer() but that all happens in memory and not in the database query (call me old-fashioned, but I’d like my database results properly filtered ).

Finally, I found the solution in using subqueries:

ICriteria crit = session.CreateCriteria(typeof(User));

DetachedCriteria roleIdsForSite = DetachedCriteria.For(typeof (Role))

    .SetProjection(Projections.Property("Id"))

    .CreateCriteria("Sites", "site")

    .Add(Expression.Eq("site.Id", siteId.Value));

DetachedCriteria userIdsForRoles = DetachedCriteria.For(typeof(User))

    .SetProjection(Projections.Distinct(Projections.Property("Id")))

    .CreateCriteria("Roles")

        .Add(Subqueries.PropertyIn("Id", roleIdsForSite));

crit.Add(Subqueries.PropertyIn("Id", userIdsForRoles));

Yes, that’s an insane amount of code to do something that simple, but it works and the generated SQL is highly efficient . Notice the distinct projection in the second DetachedCriteria (userIdsForRoles).

I’d really appreciate it if somebody has any suggestions for improvement.