On the heels of the demise of the commercial version of EntitySpaces, I am delving into Microsoft’s Entity Framework. I need to implement it in a big project to replace a much more manual Data Access Layer.

So I’ve done a ton of reading on it (and played with it some, too), and the common wisdom is to use the Repository Pattern to implement it. The main reason seems to be to maintain a separation of concerns — so that the persistence layer isn’t directly used/referenced from the UI. In turn, this seems to be important so that you can change the underlying data structure without changing the UI very much.

At first, this seems to add a layer of complexity to an application that doesn’t seem to be necessary — I never used this pattern with EntitySpaces (although I could have), and indeed, the ES developers recommended against it. Entity Framework uses the dbcontext as its own repository/unit of work pattern, so why add a whole other level of abstraction to it? Adding complexity will surely slow down development, and speeding things up is my primary motivation for using an ORM framework.

There is a terrific case made for NOT using repositories by Oren Eini (aka Ayende Rahien), a contributor to the NHibernate open-source ORM framework. His post can be found here.

Will I ever actually change the database layer?

As I said, this doesn’t seem to be necessary – I don’t believe I will change the underlying database from SQL Server to Oracle or some other database. Even if I did, Entity Framework can work with many different databases.

I suppose there is a possibility that it could change to a web service implementation. I don’t know why the project would change like that, but it could if the need arose. In this case, repositories would insulate the UI from that change. I am implementing EF using POCOs, so those could be kept and reused even with web services.

But What If I Change the UI?

But after thinking about it for a while, the most important reason to maintain separation of concerns in my project is that I don’t know how the UI layer will change. I can already see the possibility of creating several UIs – Web, mobile, and public web services. Aha! If I use repositories, I can develop as many UIs as I want using the same data access layer. Or almost the same data access layer — I am certain I would have to add custom methods to my repositories for each UI.

But can I still create multiple UIs if I don’t use repositories — using EF directly? Yes, of course I can. On the downside, there will be some duplication of code. Conversely, the data access will be tailored directly to my UI needs.

So what’s the right answer?

Guess what, despite the legions of fanatics that will tell you there is only one “right” way to do it, either way will work.

For speed’s sake, I strongly considered going without repositories, but I have decided to use them based on the multiple examples of their effectiveness and my uncertainty about future UI development for my project.