As I talked about in my post Do we need the repository pattern? I’ve been thinking about how we can make a testable data access layer with Entity Framework without using a repository pattern. I showed how you could do that in my post Mocking your Entity Framework data context and testing it in .NET MVC. However losing the repository also loses a nice centralised place to keep your query logic. In this post I’ll show you a nice simple way to use extension methods to do this.

Suppose you’re using Entity Framework to store a collection of foos and there are several places in your app that you …

I explained in my previous post Do we need the repository pattern? why you might want to mock your Entity Framework context rather than using the repository pattern. In this post I’ll show you how to do that and how to test your .NET MVC controllers with a fake data context.

The way you do this varies slightly depending on whether you're using code first or database first. I’ll cover both in this post.

Using Code First in Entity Framework 4

My implementation of code first is based heavily on the blog post by Rowan Miller.

A mockable data context (EF Code First)

When you create your code …

As we learn new technologies, we discover new mistakes. The Entity Framework makes data access very quick to develop, but also introduces a new set of mistakes that can be made. On my last project I used the Entity Framework Profiler and found my code blighted with a scourge of N+1 problems. I discussed this in my blog post Reviewing my data access layer using the Entity Framework Profiler.

I was also worried that my code wasn’t testable. From what I’d read, the repository pattern seemed to be the agreed best practice for making your data access testable.

However my N+1 problems led me to …

Inspired by Oren Eini’s series of blog post code reviews and hearing him talk on This Developers Life Life I decided to review the data access of my latest application using the Entity Framework Profiler.

This is the second application I’ve used the Entity Framework for, and I’ve found it a joy to work with. I’d heard the arguments against ORMs that said they can’t produce good SQL, but I’d also heard the argument that ORMs are made by very smart people and they can probably make better SQL than most people. What I hadn’t heard till I heard Oren’s interview was that a smart ORM will still …