Archive for the ‘Entity Framework’ category

Activate Your Glutes and Visual Studio 2010

February 3, 2010

If you’ve downloaded the source code for the site you’ve probably noticed that it’s still using MVC 1.0, Entity Framework 1.0 and Visual Studio 2008.

I’ve been using Visual Studio 2010 and .Net 4 for a few weeks now on a commercial project and, since ReSharper 5.0 was released in beta (losing ReSharper is a painful experience), have found it to be a fairly stable and usable experience though I hope they sort out the performance issues in the IDE by the time it is fully released – I don’t recall ever waiting for my 8-bit BBC Micro with its mighty 6502 processor and 32kb of RAM to catch up with my typing.

But back on topic, I do plan on moving the site over to MVC 2.0 and Entity Framework early next month. I’m particularly keen to see how the much touted Entity Framework improvements work out as version 1.0 is frequently horrible and I keep wishing I’d used NHibernate.

A prerequisite for me doing this however is getting integration tests in place for my repository implementation for which I’m planning on using ndbunit for the first time. If anyone has any experience with this, good or bad, then I’d be interested in hearing any comments you might have and experiences you think are worth sharing.

Advertisements

The Perils of Entity Framework

February 2, 2010

When you first look at Entity Framework it seems nice and glossy and friendly. Great you might think, now I don’t have to code any pesky classes for using my data in my application as Entity Framework as created them for me. Heck its even marked them up as Data Contracts so I can serialise them through WCF.

This would be a mistake.

Lets deal with the simple case of an in-process model as you might use in a ASP.Net MVC application, as for example the Activate Your Glutes site does.

There are a couple of obvious ways you could use Entity Framework in an MVC application.

Firstly you could place the logic for retrieving data through Entity Framework directly in your controllers running Linq to Entity queries right there in the controller. You’ll quickly discover a couple of problems with this – firstly how do you ensure that two different controllers needing access to the same data run the same query? You’re going to find yourself violating the DRY principle pretty quickly. Plus this is a fairly obvious case of a cross cutting concern – a controller should be about presenting data in a model to a view and not about the nuts and bolts of retrieving that information from a data store.

So a better approach is to use the repository pattern to hide these details away.

Great, so now your controllers are nice and simple. They ask for an entity from a provider and get that entity. And if you’re using Entity Framework the temptation is to return the Entity Framework objects straight back to your controller. After all your controller wants a Person entity and Entity Framework has a nice shiny Person class that contains all the properties you need so why not return it?

The danger and problem with doing this is that you’ve allowed the ORM code in the Entity Framework classes to bleed through to your controller. As you work with the objects and manipulate them you are making changes to objects that live in the Entity Framework context.

Lets say for view purposes you capitalise the surname of the Person object you are working with and then later on make a call to your repository implementation that internally makes a call to SaveChanges committing all the changes Entity Framework knows about to the database. Did you really mean to save that capitalised surname? Possibly. Is it clear that you have? No.

More typically in MVC you’ll come up against these kinds of problems when implementing custom model binders for complex objects that include one to many relationships. You’ll find yourself having to write contorted code, quite possibly referencing EntityKey’s directly, to make your model binder work in all situations.

To avoid all this and keep Entity Framework’s ORM concerns down where they belong in the repository implementation its best to implement a series of POCO objects to prevent cross cutting concerns from spreading like wildfire. You can take the grunt work out of converting between your POCO objects and Entity Framework objects by using something like AutoMapper that is quick to configure and as long as you roll with its convention over configuration based approach can generally do this job with a line of code.

You can see examples of the implementation described above in the Activate Your Glutes codebase.

As an aside its worth noting that using the repository pattern and POCO objects as described above can help make your code easier to test.