Geeks With Blogs
Codekiwi Just a the musings of a kiwi who loves to code...

I came across and found very useful, bare in mind I am relatively new to the EF and TDD so any suggestions would be welcomed.

I have been very busy recently with a new project, as I am in control of this project I have wanted to do things correctly from the start, I also am using it as an opportunity to get familiar with all the newest and shiniest of Microsoft's technologies. The platform is using a combination of ASP.Net MVC 2.0 and the Entity Framework 3.0.

Because I know this codebase is going to grow very large I wanted to get off on the right foot and have a robust but flexible data access strategy and have unit testing engrained I found a fantastic article by Morshed Anwar on CodeProject, Here is the link I highly recommend reading it.

Repository provides an in-memory like collection interface for accessing domain objects. So as far as the consuming component is concerned, it uses the repository just like a collection when working with Domain objects. The repository then neatly abstracts the internal mechanics of how the Add / Remove calls to the repository translate to the actual data access calls to the data store. Objects can be added to and removed from the Repository, as they can from a simple collection of objects, and the mapping code encapsulated by the Repository will carry out the appropriate operations behind the scenes. Conceptually, a Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer. Repository also supports the objective of achieving a clean separation and one-way dependency between the domain and data mapping layers.

So with the repository we get a nice abstraction that provides us with persistence ignorance and a nice separation of concerns where the responsibility of persisting domain objects is encapsulated by the Repository leaving the domain objects to deal entirely with the domain model and domain logic.

 After implementing this thing worked very well, I could create a new repository in my business layer with a single line (albieit a long one)

This worked well for my application, allowing me to use linq to provide safe data access from my business layer while adhereing to the S in SOLID (Separation of concerns), however when I came to the unit tests (yes I know I should be doing these first, but I'm not TDD yet) I ran into a brick wall.

The problem comes from the fact the DoQuery operations return an ObjectQuery, Because ObjectQuery is not abstract and sealed it cannot be mocked using Moq or Rhino mocks, I did however find an article by Muhammad Mosa on TypeMock Isolator and the EF . This was not a solution for me as Typemock Isolator is not free and my project is so far funded by me.

After a little research I realised (with a head slapping moment) that the ObjectQuery(Of T) class implements the IQueryable(Of T) interface, after swapping this out in the Repository class everything worked brilliantly. See below for the DoQuery method

So yes this whole post is just to explain replacing the return type of the DoQuery, but the power of this simple change has mean't I can fully mock my data access, see my mocked repository below (using Rhino Mocks)

Posted on Wednesday, January 27, 2010 10:12 PM TDD , ASP.Net MVC | Back to top


Comments on this post: Implementing a Testable Mockable Repository pattern with the Entity Framework

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Codekiwi | Powered by: GeeksWithBlogs.net