This dumb mistake just cost me an hour spelunking around in the debugger:

var status = source.Substring(source.LastIndexOf("/" + 1));

(where source is e.g. “http://foo.com/status/all-is-good”)

Fortunately the ramifications were picked up in the acceptance tests, but the root cause wasn’t at all obvious from such a high level.

Lesson for the day – code is never too trivial to warrant unit testing.

This is the fifth in a series of five posts recounting my experiences using Entity Framework Code-First to replace ADO.NET and stored procedures in a client’s existing application. The introductory post in the series is here.

---

I am lucky to have had the opportunity to spend a time-boxed period playing with Entity Framework Code-First in a real-world scenario, and to get paid for the privilege! I now have a clearer understanding of how it has progressed during the last few years, what its strong points are, and where it still has shortcomings compared to the much more mature NHibernate framework.

The Positives

I have to say that after a week of getting through the pain barrier and the initial denial of working with an unfamiliar ORM, I have reached a level of understanding and acceptance with Entity Framework. It really isn’t all that bad (at least the Code-First flavour), and if you don’t stray too far from its rigid way of thinking it will help you to get a solution up and running quickly and reliably. It’s certainly a far preferable option than mucking about with ADO.NET and stored bloody procedures, that’s for sure.

The whole process of configuration and initialization is straightforward and pain-free, with the derived DbContext providing a out-of-the-box implementation of Unit of Work already to be referenced from your consuming code. Easy.

Querying the model is 99% unadulterated LINQ, with the occasional call to Include to perform some eager fetching – what could be simpler?

I’m also unashamedly impressed with how easily EF can be used to power ASP.NET Dynamic Data sites, and RESTful WCF Data Services. Nice.

The Negatives

I found that the real pain of working with Entity Framework only surfaces when you wish to start tuning its behaviour in any way – you find that it’s a big black box with few extensibility points. It performs cunning tricks effortlessly, but wields its power in a largely indiscriminate manner. By comparison, NHibernate can achieve even greater things, but requires you to explicitly invoke these powers.

I am reminded of a response Ayende gave when asked why NH Futures was not the default behaviour – “NHibernate tries hard not to make too much magic”. I thought it sounded glib at the time, but having lived with EF for a while, I now understand why this is preferable.

Most of the NHibernate features that are missing from Entity Framework are related to performance – such as the ability to configure query batching, write batching, bulk operations, extra-lazy properties, and second-level caching. These are the features you’ll miss the most when you’re some way into a project, perhaps not until it’s in production and scalability issues arise.

I also feel the CTP5 of EF code-first is a little way off offering true support for persistence ignorance and POCO, having experienced a number of issues that required me to change my domain model, database schema, and application code.

Additional Resources

Here are a few of the resources that I found particularly useful during my EF week:

• Programming Entity Framework, Second Edition – Safari / Amazon
• Dino Esposito – A Feature-Driven Comparison of EF and NH
• ADO.NET Team Blog
• Using DbContext in EF Feature CTP5 – a series of 12 blog posts
• David Ebbo – Using Dynamic Data With EF Code First and NuGet

This is the fourth in a series of five posts recounting my experiences using Entity Framework Code-First to replace ADO.NET and stored procedures in a client’s existing application. The introductory post in the series is here.

---

I didn’t want this series of posts to descend into a point-scoring NHibernate-versus-Entity Framework comparison, but…

I now have a basic proof-of-concept up and running, with my client’s nascent application now being powered by Entity Framework Code-First CTP5 rather than a hand-rolled DAL. So, I had some time to consider future functional and non-functional requirements that the team would be asked to develop and support, and investigate how EF would meet the challenge.

Caching

I was genuinely surprised to learn that Entity Framework still doesn’t include any out-of-the-box support for integrating second-level caching, for example to cache reference data. It seems there is a body of opinion stating that caching should not be the responsibility of the data access layer. I disagree, and I think this is one of the major benefits NHibernate still has over Entity Framework, with its multiple flexible and configurable second-level cache providers.

Targeting Alternative Providers (SQLite)

When working with NHibernate, I often target SQLite for fast integration tests against an in-memory database, rather than maintaining a testing version of the MSSQL/Oracle databases that my applications usually use for their bitbucket. I was pleased to see the discussions on the System.Data.SQLite page suggesting that this approach is possible with Entity Framework too, but I didn’t spend any time attempting to get this working.

Auditing Functionality

Entity Framework does not appear to support the rich events and listeners model that is offered by NHibernate and frequently used to develop application auditing functionality. The recommended solution to achieve this scenario is to override the virtual SaveChanges method on DbContext and add validation and auditing logic there. For more details, see page 261 of Programming Entity Framework.

Bulk Operations

I have not yet encountered any Entity Framework support for bulk update/delete operations akin to NHibernate’s Executable DML functionality. Such requirements are usually relatively rare, but it’s a shame to have to fall back to writing stored procedures for relatively simple operations which can be described in terms of the domain model.

Query Batching

There does not appear to be any way to do query batching in Entity Framework, as per NHibernate Futures. Multiple queries result in multiple network trips to the database, sadly. Similarly, there’s no support for write batching and batched collection loads.

Concurrency and Versioning

Entity framework supports optimistic concurrency. Chapter 23 of Programming Entity Framework explains in detail how this can be configured and utilised by your application. Entity Framework also supports rowversion fields for concurrency checks.

Extra-Lazy Properties

Unlike NHibernate, Entity Framework currently has no notion of “extra-lazy” properties. Requesting the Count of a child collection (e.g. Order.Lines.Count) will therefore trigger the loading of all entities (Lines) in the child collection. Not nice. Yes, we can work around this by making the appropriate count query at a higher level but it’s much nicer to be able to traverse the domain model relationships and let persistence ignorance work it’s magic.

Integration with the Wider .NET Stack

To my mind, one of the key selling points of Entity Framework over NHibernate is its out-of-the-box integration with other areas of the .NET stack – notably the ability to power ASP.NET Dynamic Data sites (which are great for simple pages to maintain reference data) and WCF Data Services.

Query Techniques

NHibernate offers a world of choice when it comes to methods for querying the model: HQL, Criteria, QueryOver, LINQ, Named Queries, etc. These each offer a plethora of possible options and tweaks including query caching, batching and futures. By comparison, Entity Framework offers a comprehensive LINQ provider (with decent extensions to specify eager-loading of child entities), or Entity SQL. And that’s your lot.

---

By the end of my fourth day, I had a working proof-of-concept using Entity Framework Code First to power my client’s application, and I had a good idea of how suitable it was to meet future requirements lurking in the product backlog.

In the fifth and final part of this series of posts, I’ll write some concluding thoughts on my overall experiences spending a week with Entity Framework.

This is the third in a series of five posts recounting my experiences using Entity Framework Code-First to replace ADO.NET and stored procedures in a client’s existing application. The introductory post in the series is here.

---

Having configured and initialized Entity Framework, and tweaked the mappings, by Day 3 I was all set to start consuming my shiny new DbContext implementation from the application code, and actually get some CRUD work done. Not unexpectedly, I hit a few issues along the way…

Proxy Generation

As a long-term NHibernate user, I habitually mark all members on my domain classes as virtual, since this is a requirement for entities to be replace at runtime by proxies. Remember that NHibernate is a port from the Java world, where all instance methods are virtual by default.

Now, this habit led to some unexpected behaviour when I attempted to use Entity Framework to persist the same domain objects, namely exception messages such as:

The property ‘Foo’ on type ‘Bar_B6089AE40D178593955F1328A70EAA3D8F0F01DDE9F9FBD615F60A34F9178B94’ cannot be set because the collection is already set to an EntityCollection.

Clear as mud, eh? A little Googling eventually unearthed the following posts from other people experiencing this issue:

• Why is my Entity Framework Code First proxy collection null and why can’t I set it?
• Code First adding to collections? How to use Code First with repositories? Advice me please
• Code First EF4 with N-Tier.. I’m really stuck on this one issue

This latter post on the MSDN forums includes the following explanation from one of the guys on the Entity Framework team:

“If you make all your properties virtual then EF will generate proxy classes at runtime that derives from your POCO classed, these proxies allow EF to find out about changes in real-time rather than having to capture the original values of your object and then scan for changes when you save (this is obviously has performance and memory usage benefits but the difference will be negligible unless you have a large number of entities loaded into memory). These are known as ‘change tracking proxies’, if you make your navigation properties virtual then a proxy is still generated but it is much simpler and just includes some logic to perform lazy loading when you access a navigation property.

Because your original code was generating change tracking proxies, EF was replacing your collection property with a special collection type to help it find out about changes. Because you try and set the collection back to a simple list in the constructor you are getting the exception.

Unless you are seeing performance issues I would follow Terrence’s suggestion and just remove ‘virtual’ from your non-navigation properties.”

This feels a little bit strange, and I’m not convinced that we are really getting persistence ignorance if we experience differing behaviour depending on whether or not we have chosen to make all our members virtual. I haven’t invested much time looking into the benefits of these “Change-Tracking Proxies”, or how it is possible to utilise these without causing the “collection is already set to an EntityCollection” exception. I just did what the man said and removed the virtual keyword from most non-navigation properties.

A Runtime Exception When Lazy-Loading

At one point I experienced an exception message along the lines of:

“Entities in ‘CodeFirstContainer_Sessions’ participate in the ‘Session_Season’ relationship. 0 related ‘Session_Season_Target’ were found. 1 ‘Session_Season_Target’ is expected.”

This was caused by my navigation property (Session.Season) not having been set as virtual, so no proxy was being created.

Incidentally, it is worth highlighting that lazy-loading must occur within the scope of an open DbContext (i.e. within the Unit of Work). It is not reasonable to expect to transparently load the navigation property after the database connection has been closed (this is analogous to attempting to lazy-load in NHibernate after closing the Session).

Cascades

In NHibernate, cascading saves/updates/deletes have to be specified manually on all foreign key relationships – the default behaviour is not to cascade any changes when committing changes, which often leads to newcomers experiencing an error message “not-null property references a null or transient value”.

Entity Framework takes a more convention-based approach and assumes that all saves and updates should cascade. So, if you save a shiny new Order with an associated Address and a handful of Lines, Entity Framework will determine that it should first insert the Address row, then the Order row, and then each Line row. Sweet. Updates similarly cascade. Assuming you are happy with this behaviour (which seems sensible), then all should be well.

Deletes, on the other hand, are a bit strange. Entity Framework will not take responsibility for cascading a delete in the database – it expects that you will achieve this by setting a cascading delete on the foreign key relationship in the RDBMS.

Having said this, if you delete a parent entity in Entity Framework, it will attempt to issue delete statements for any child entities which have been loaded into the current DbContext, but it will not initialize any child entities which have not yet been loaded. This may lead to the RDBMS throwing foreign key constraint violation exceptions if a cascading delete has not been specified. For more details about how cascade delete “works” in Entity Framework, see this blog post.

Personally, I think this behaviour is pretty shoddy, but there you have it! Forewarned is forearmed.

In light of this behaviour I had to make modifications to the database schema to set cascading deletes on all the appropriate foreign key relationships. For many line-of-business applications, deletes are actually pretty rare events, and in the short term I suspect this issue is more likely to be encountered when clearing down data in integration tests than in actual application use.

Initializing Child Objects on Domain Entities

I habitually add code to the constructors of domain entities to initialise child entities to sensible defaults – I find it helps to ensure that objects are always in a valid state, and reduces the likelihood of encountering an unhandled NullReferenceException. So, for example, I would usually have something like this:

public class Order
{
    public Order()
    {
        this.Address = new Address();
    }

    public virtual Address Address { get; set; }
}

Unfortunately, when using this approach with Entity Framework, I found that when loading an existing Order which has an associated Address, the Order.Address object was always reset to its default.

Now, I realise that making calls to virtual members in a constructor is not really a good idea (heaven knows Resharper and Coderush have both nagged me about it often enough), but NHibernate never had a problem with this approach. Nevertheless, I tried to do things properly and replaced the automatic properties with backing fields….

public class Order
{
    public Order()
    {
        this._address = new Address();
    }

    private Address _address;

    public virtual Address Address
    {
        get { return _address; }
        set { _address = value; }
    }
}

But still no dice. I then tried putting initialization logic in the property’s getter….

public class Order
{
    public Order()
    {
        this._address = new Address();
    }

    private Address _address;

    public virtual Address Address
    {
        get { return _address ?? (_address = new Address()); }
        set { _address = value; }
    }
}

But nothing worked. Every time I loaded an Order, the Order.Address object was reset back to its default instead of containing the data loaded from the database.

This is quite frustrating and as yet I haven’t been able to find a workaround, other than to abandon my plans to perform object initialization in the domain model and instead handle it in the service layer, with all the resultant null-checking code that will ensue.

While trying to find a solution, I did stumble across this comment from Rowan Miller that “More flexibility in how we interact with classes is a common ask for EF and our team is looking at how we can support this at the moment.”
Are we asking for flexibility? I thought we were just asking for the persistence ignorance that had long been promised.

---

Despite these issues, in three short days I had gone from knowing next to nothing about Entity Framework 4 Code first, to using it to perform almost all of the data access required by a small application. In the fourth part of this series I’ll consider some of the additional features and application requirements that I would expect an ORM to handle, and see how EF meets the challenge.