1. Agile Entity Framework 4 Repository: Part 1- Model and POCO Classes
2. Agile Entity Framework 4 Repository: Part 2- The Repository
3. Agile EF4 Repository: Part 3 -Fine Tuning the Repository
4. Agile EF 4 Repositories Part 4: Compiled LINQ Queries
5. Agile Entity Framework 4 Repository Part 5: IObjectSet and Include
6. Agile Entity Framework 4 Repository: Part 6: Mocks & Unit Tests

I lied. In the last installment of this blog series, I said that the next post would show the tests. They are still sitting there waiting to be written about, but something more important came up. I was focused on the repository building and not paying attention to my queries. Even in my EF Tips & Tricks conference presentations, I discuss the importance of using compiled LINQ queries because of their performance benefit. Here is a blog post I wrote early in 2008 about compiled queries for a quick look at what they do and how to use them: Compiled Queries in Entity Framework

It really is a best practice to use them, so after a few people asked via emails and the comments in the blog “but what about compiled queries?” I wanted to see if I could get them to work in the repository.

One of the the big problems with compiled LINQ queries in EF is the fact that they are associated with the ObjectContext. If the context goes out scope, so does the precompiled query and you have to compile the query again.

But I have already dealt with that problem. Here’s another blog post I wrote, Using Pre-Compiled LINQ to Entities Queries in Web Apps and Services, that showed how to solve this. Essentially, I created a static variable to retain the precompiled query across processes in a web app.

I decided to leverage this approach (simply retaining the compiled query) to be used by different ObjectContexts regardless of whether they are in a separate process or not.

I managed to pull it off. I still have more work to do to fine tune this solution, but I wanted to share the basic structure of how I’m doing it.

First you’ll need to refer back to the repositories I created in the previous post, Agile EF4 Repository: Part 3 -Fine Tuning the Repository, – e.g., CustomerRepository.

My conundrum

The repository uses a context to query, update and manage customer entities. However this context is not an ObjectContext — it is an interface that I created called IContext. My EF context, which does the real Entity Framework tasks, inherits from an ObjectContext and implements IContext. So when the repository happens to be using that flavor of IContext, it will be possible to use compiled queries. But when the repository is using some other context that implements IContext, I cannot assume that I’ll have the ObjectContext features. So I’m in between a rock and a hard place. I don’t really want the repository to have to worry about that; yet, I don’t want the ObjectContext to have knowledge of all of the CustomerRepository queries and all of the ReservationRepository queries etc.

So what I did was add another layer.

The additional layer is a new class (actually, one new class per repository) for compiled queries, e.g., CustomerRepositoryCompiledQueries. That’s a working title. 🙂

This class and it’s siblings ReservationRepositoryCompiledQueries, AddressRepositoryCompiledQueries, etc, will be responsible for precompiling and invoking queries for its relevant repository.

With me so far? 🙂

Modifying IContext

Here’s the part I’m not 100% satisfied yet, but it gets me going in the right direction (and works).

Back in the repository, I now need to differentiate between contexts that know how to precompile/invoke and contexts that don’t. This is not the repository’s job, so I added a property to the IContext interface:

bool CanPreCompile { get;  }

Contexts that implement the interface will return either true or false (no kidding, sorry ;)). My context that is the real ObjectContext (ModelContext, from the first blog post) will return true. The mock contexts (coming in later posts in the series) will return false.

If you were patient enough to look at my linked post (above) on retaining the precompiled queries across processes, the setup below will be familiar. I’m declaring a static variable to maintain the precompiled query, e.g., _custByID. When the CustsWithReservations method is requested, if the variable is null (hasn’t been precompiled yet) then I go ahead and precompile it and then invoke it. If it was already pre-compiled, then I go right to invoking it using the context and id passed in.

using System.Collections.Generic;
using System.Linq;
using POCOBAGA.Repository.Interface;
using POCOBAGA.Classes;
using System;
using System.Data.Objects;

namespace POCOBAGA.Repository.Queries
{
  class CompiledCustomerQueries
  {
    static Func<ObjectContext, IQueryable<Customer>> _custWithReservations;
    static Func<ObjectContext, int, Customer> _custByID;

    public static IList<Customer> CustsWithReservations(ObjectContext context)
    {
      if (_custWithReservations == null)
      {
        _custWithReservations = CompiledQuery.Compile<ObjectContext, IQueryable<Customer>>
                       (ctx => from cust in ((IContext)ctx).Customers
                               where cust.Reservations.Any()
                               select cust);
      }
      return _custWithReservations.Invoke(context).ToList();
    }

    public static Customer CustByID(ObjectContext context, int ID)
    {
      if (_custByID == null)
      {
        _custByID = CompiledQuery.Compile<ObjectContext, int, Customer>
         ((ctx, id) => ((IContext)ctx).Customers.
             Where(c => c.ContactID == id).Single());

      }
      return _custByID.Invoke(context, ID);
    }
  }
}

One of the notable parts of this class is that I need the ObjectContext in order to Compile, but I need the IContext in order to get at the Reservations and Customers properties. Since BAGAContext is both ObjectContext and IContext…problem solved with a little casting.

One more change to the IContext (and implementers)

As noted, the Compile method requires an ObjectContext. It will be the repositories calling the methods which compile, but the repositories don’t have an ObjectContext, they have an IContext.

I added the following to the IContext to expose the context as a “compiler”.

     ObjectContext Compiler { get; }

The BAGAContext class which is a true ObjectContext implements this to return it’s ObjectContext:

    public ObjectContext Compiler
    {
      get { return (ObjectContext)this; }
    }

Modifying the Repository

Now let’s see how this all works together in the repository. I’ll modify the GetByID method of the CustomerRepository that was in the previous post in the series.

   public Customer GetById(int id)
    {
      if (_context.CanPreCompile)
      {
        return CompiledCustomerQueries.CustByID(_context.Compiler, id);
      }
      else
        return _context.Customers.Include("Contacts")
            .Where(c => c.ContactID == id).FirstOrDefault();
    }

If the context is one which can leverage precompiled  queries then I have to use the repositories supplemental logic for getting the query from the compiler, otherwise, I just go ahead and execute the query.

Testing the Pre-Compiled Repository

I want to do some testing to verify that the compiled queries work. The goal is to call GetByID with two separate repository instances and watch in the debugger if the query is simply invoked or compiled on the second time. This will be a simple integration test so I’m not going to need the mocks (which I haven’t shown you yet anyway).

The telling part of the test code is:

    var cRep = new CustomerRepository();
    Customer c1 = cRep.GetById(1);
    var cRep2 = new CustomerRepository();
    Customer c2 = cRep2.GetById(16);

When debugging this code the CompiledQuery.Compile is executed as the first GetByID is called. When the second GetById is called against the second repository, the execution recognizes that the query has already been compiled (i.e. _custByID is not null) and just skips right to the invoke.

And in Summary…

For me this is a proof of concept, if perhaps not the perfect implementation. Precompiling LINQ to Entities queries, especially those which get used frequently, is important when you care about performance. It’s great to be able to implement various features, but critical to be able to use them in concert.

Having the ability to truly write agile, persistent ignorant, testable code with EF and at the same time, continue to benefit from other important features of Entity Framework is  pretty important. Otherwise, EF would not really be PI.

There are plenty of other scenarios to run the repositories against, but this was pretty high up on the list and I’m happy that I was able to work out a good starting point.

Even when working with POCOs, the EF’s ObjectContext can track the objects using ObjectStateEntry objects just as it does for entities that inherit from EntityObject.

I was thinking about ObjectContext.ObjectStateManager.GetObjectStateEntry. This method has two overloads. One takes an entity and the other takes an EntityKey of an entity. Then it returns the ObjectStateEntry being maintained to track that particular entity.

In more detail, the signature for the first overload is

GetObjectStateEntry(object entity)

So it doesn’t necessarily require an EntityObject.

I ran a query using a context which returned a POCO class.

The POCO class was one designed for snapshot detection. There are no virtual properties and therefore no proxy EntityObject is created on behalf of this object.

I requested the entry:

var ose= context.ObjectStateManager.GetObjectStateEntry(contact);

And voila, even though it was a simple object, the context was still able to find the ObjectStateEntry and return it.

There are a lot of What-Ifs around using POCOs. There will are definitely be some scenarios where you won’t get the behavior you might expect from an EntityObject. Sometimes using proxies will fix that, such as in the case of lazy loading. But it will take time to work through the various possibilities.

I have gathered up my slides and demos from Oredev and DevConnections and put them on the internet.

The PPTs are on Slideshare.

The demos are on the downloads page of my book’s website: www.learnentityframework.com.

That page also has the links to the slideshare urls.

Here’s what you’ll find on the downloads page:

1. DevConnections Fall 2009 Entity Framework Tips & Tricks
    Demo zip file
    Powerpoint –>   http://www.slideshare.net/JulieLerman/lerman-vvs14-ef-tips-and-tricks

2. DevConnections Fall 2009 Entity Framework 4 and ASP.NET

• Demo Part 1: Simple EntityDataSource, DynamicData and MVC
• Demo Part 2: ObjectDataSource
• Demo Part 3: MVC with simple POCO Repository

      Powerpoint –> http://www.slideshare.net/JulieLerman/lerman-adx303-entity-framework-4-in-aspnet

3. DevConnections Fall 2009 Entity Framework 4 and WCF
    Demo zip file
    PowerPoint –> http://www.slideshare.net/JulieLerman/lerman-vvs13-entity-framework-4-and-wcf

4. OreDev, Vermont.NET and NotATPDC: Agile Entity Framework 4

• Part 1: POCOs
• Part 2: Repository/Testing (demos coming soon) See my blog post series Agile EF 4 (Agile EF4 Repository- Part 3 -Fine Tuning the Repository)

    Powerpoint->  http://www.slideshare.net/JulieLerman/agileentity-framework-4

Third post in my Agile EF4 Repository blog series:

1. Agile Entity Framework 4 Repository: Part 1- Model and POCO Classes
2. Agile Entity Framework 4 Repository: Part 2- The Repository
3. Agile EF4 Repository: Part 3 -Fine Tuning the Repository
4. Agile EF 4 Repositories Part 4: Compiled LINQ Queries
5. Agile Entity Framework 4 Repository Part 5: IObjectSet and Include
6. Agile Entity Framework 4 Repository: Part 6: Mocks & Unit Tests

In the previous post I created an uber repository (someone called it a ‘god class’ :)) that was responsible for all of my object generation. You’ll see some great discussion in the comments with Bobby Johnson (who I met when speaking at the South Sound .NET group in Olympia),  Mike Campbell (a friend and unbeknownst to him, sometimes mentor) and myself about the structure of this repository. They encouraged me to look deeper and create repositories that had singular responsibility for classes.

So with a lot of cajoling and many emails back and forth where I tried to explain EF to them and they helped me with a better understanding of the repository pattern and of persistence ignorance, I have taken the repository to the next step and refactored my solution. Faisal Mohamood’s (Entity Framework team) post on EF, Repository and Unit of Work helped as well. This is important because I use the ObjectContext as a unit of work. Therefore, I don’t want Customer to be responsible for saving itself. I might want to save a Customer with Orders and line items. Or perhaps I want to save a Customer and Addresses. Technically speaking, I can still accomplish that by saving a customer graph without having a unit of work.  What about querying. If I want to query a customer and it’s orders separately yet still save them together, now I’ll want to have a shared context to perform the save. EF4’s Foreign Keys simplifies things a bit, but as Faisal points out, the unit of work pattern also works with EFv1 where the relationships are maintained by the context.

Okay back to code.

Repository Interface for Entities

I’ve seen plenty of repositories that define an explicit interface for each component, such as ICustomerRepository and IOrderRepository. But I’m not doing that here. Rather, I have a single interface called IEntityRepository that defined a contract for any entity for which I am defining a repository. My instinct has driven me to do this and if it’s really wrong, I’ll find out quickly enough through the comments of this blog post. 🙂

I’m using generics here so that I don’t have to worry about the type. Thanks to a quick generics refresher that I received from Kathleen Dollard last week when we were hold up in her hotel room at DevConnections one evening, this particular usage came easily to me.

using System.Collections.Generic;
using POCOBAGA.Classes;

namespace POCOBAGA.Repository.Interface
{
    public interface IEntityRepository<TEntity>
    {
        TEntity GetById(int id);
        void Add(TEntity entity);
        void Delete(TEntity entity);
        List<TEntity> All();
        IContext context { get; }
    }
}

Implementing IEntityRepository

Next I created some repositories that implement this interface to serve as entry points to get at some of my classes. The classes define additional methods as well. The constructor allows the repository to spin up a new context if necessary or use a pre-existing one that can be passed in. This is the same pattern I used in the previous repository.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using POCOBAGA.Repository.Interface;
using POCOBAGA.Repository.Model;
using POCOBAGA.Classes;
using ExtensionMethods;


namespace POCOBAGA.Repository.Queries
{

    public class ReservationRepository : IEntityRepository<Reservation>
    {

        IContext _context;

        #region Constructors

        public ReservationRepository()
        {
            _context = new BAGAContext();
        }
        public ReservationRepository(IContext context)
        {
            _context = context;
        }

        #endregion

        #region Interface
        public Reservation GetById(int id)
        {
            return _context.Reservations.Include("Customer.Contact")
                .Where(r => r.ReservationID == id)
                .FirstOrDefault();
        }

        public void Add(Reservation entity)
        {
            context.Reservations.AddObject(entity);
        }

        public void Delete(Reservation entity)
        {
            _context.Reservations.DeleteObject(entity);
        }

        public List<Reservation> All()
        {
            return _context.Reservations.ToList();
        }
        public IContext context
        {
            get { return _context; }
        }

        #endregion

        #region Reservation Methods

        public IList<Reservation> GetReservationsForCustomer(int? CustomerID)
        {

            if (!CustomerID.HasValue || CustomerID.Value < 1)
            {
                throw new ArgumentOutOfRangeException();
            }
            return _context.Reservations.
              Where(r => r.ContactID == CustomerID).ToList();
        }
        #endregion
    }
}

Here’s another IEntityRepository implementation.

using System.Collections.Generic;
using System.Linq;
using POCOBAGA.Repository.Interface;
using POCOBAGA.Repository.Model;
using POCOBAGA.Classes;
using ExtensionMethods;

namespace POCOBAGA.Repository.Queries
{

    public class CustomerRepository : IEntityRepository<Customer>
    {

        IContext _context;

        #region Constructors

        public CustomerRepository()
        {
            _context = new BAGAContext();
        }
        public CustomerRepository(IContext context)
        {
            _context = context;
        }
        #endregion

        #region Interface

        public Customer GetById(int id)
        {
            return _context.Customers.Include("Contacts")
                .Where(c => c.ContactID == id).FirstOrDefault();
        }

        public void Add(Customer entity)
        {
            context.Customers.AddObject(entity);
        }

        public void Delete(Customer customer)
        {
            _context.Customers.DeleteObject(customer);
        }


        public List<Customer> All()
        {
            return _context.Customers.ToList();
        }

        public IContext context
        {
            get { return _context; }
        }
        #endregion

        #region CustomerSpecific

        public IList<Contact> CustomersWhoHaveReservations()
        {

            return _context.Contacts
                .Where(c => c.Customer.Reservations.Any())
               .ToList();

        }
        #endregion
    }
}

Saving

Now what about saving? I don’t simply want to call SaveChanges on the context. If you saw the previous post, you may recall that I had a Save method with all types of validation. I want to use that again.

This will mean some mods to the BAGAContext from the first post. Currently, IContext currently exposes SaveChanges. That means that I would be able to call SaveChanges directly from my various IEntityRepository classes. How? ReservationRepository.Context.SaveChanges. That’s not good. This is where I diverge from Faisal’s demo on EF & Unit of Work. His is a simple demo and I am not suggesting that it represents his idea of a fully fleshed out app.

To fix this, change the SaveChanges method in IContext to Save.

 string Save(); 

Next, remove the SaveChanges from BAGAContext and in its place, implement the Save method. Actually, we’ve already created all of the save logic in the original repository from the previous post. I’ll just move that into the BAGAContext class.

Because the BAGAContext class inherits ObjectContext, it does have the ability to call SaveChanges. The switch here is that it’s private to the BAGAContext class, so we can call it from within our Save method.

        public string Save()
        {
            string validationErrors = "";
            if (PreSavingValidations(out validationErrors) == true)
            {
                SaveChanges();
                return "";
            }

            else
                return "Data Not Saved due to Validation Errors: " + validationErrors;
        }


        public bool PreSavingValidations(out string validationErrors)
        {
            bool isvalid = true;
            validationErrors = "";

            foreach (Reservation res in ManagedReservations)
            {
                try
                {
                    bool isResValid;
                    string validationError;
                    isResValid = res.ValidateBeforeSave(out validationError);
                    if (!isResValid)
                    {
                        isvalid = false;
                        validationErrors += validationError;
                    }
                }
                catch (Exception ex)
                {
                    throw ex;
                }
            }
            return isvalid;
        }

Now, because I have access to the context from my repositories (e.g. ReservationRepository.Context) I could call this.Context.Save method from any of the repositories.

Here is an important concept to understand if you are new to Entity Framework. ObjectContext.SaveChanges will save EVERY object that it is currently managing. Therefore, if you are sharing a context between the CustomerRepostiroy and the ReservationRepository, and you have created objects in both repositories, then when you call Save, regardless of which repository you access the context through, e.g. custRepository.Context.Save, the context will save all of the customers and all of the reservations that it is managing. And any other types involved as well, such as the Contact class that was eager loaded with customers.

In a class (or UI) that consumes ReservationRepository, e.g. using an instance named resRepository, I can call context.Save like this:

string result = resRepository.context.Save();

And here is how it gets back to the database:

But do I want really want those repositories to give me access to saving? Not really, but I”m going to leave it this way for now. What I will eventually do is create another class to represent the context. The user will have to instantiate that class and pass it into the repositories. Then I will call mycontext.Save when the time comes. IT also means *not* exposing the context, or at least context.Save through the repositories.

So that’s it for now. Thanks again to Bobby and Mike for their encouragement, persistence and patience.

Next up will be TESTING!

(11/21/09: Note I have changed my interface name to IBAGAContext, because it is really a contract for the context, not the repository).

The Series: so far

1. Agile Entity Framework 4 Repository: Part 1- Model and POCO Classes
2. Agile Entity Framework 4 Repository: Part 2- The Repository
3. Agile EF4 Repository: Part 3 -Fine Tuning the Repository Takes the uber repository created in Part 2 and splits it up into class-specific repositories for a more Domain Driven design.
4. Agile EF 4 Repositories Part 4: Compiled LINQ Queries
5. Agile Entity Framework 4 Repository Part 5: IObjectSet and Include
6. Agile Entity Framework 4 Repository: Part 6: Mocks & Unit Tests

Part 1 of this series, Agile Entity Framework 4 Repository- Part 1- Model and POCO Classes, covered the classes, the model and the context.

Now we will look at the repository. Since the model & context are also part of the repository, my working title for this part of the repository is the Query Repository. It houses all of the database interaction and some additional related logic. Query Repository is somewhat of a misnomer because there is also logic to persist data back to the data store in here.

A caveat. This is not the end-all-be-all implementation of the repository pattern. It is a look at how you can use EF and the ObjectContext in a testable way. The hope is that those of you who are expert agile developers, will be able to take this information and plug it into your patterns. For the rest of us, it is baby steps.

Normally in this layer of an app using EF, I would be instantiating an ObjectContext and using it to perform queries, updates and other functions. But the purpose of this repository is to be used by both a real application (e.g., the UI) and a series of unit tests. Therefore the repository needs to be pretty flexible and can’t be tightly bound to the Entity Framework’s ObjectContext.

So what will it use for queries and updates etc? It will require “something that can perform queries against my model, classes and data and also persist data to the store”. It should feel something like the ObjectContext but not truly be one. And notice the word “store” rather than “database”. Where the data comes from is not relevant. Doesn’t matter in the least. If it happens to come from a database – great. Somewhere else – that’s good, too. The context in Part 1 happens to hit a database. But my repository doesn’t care about those details.

If you look at the context class I built in Part 1 of this series, it has a number of public properties and methods: Customers, Reservations, ManagedReservations, etc. Additionally, my context inherits behavior from the ObjectContext class such as SaveChanges and DetectChanges.

The Repository Interface

The Context Interface

These are properties and methods that my application relies on so I will create an interface to act as a contract to ensure that I have these properties and methods. Then I’ll instruct my repository to use anything that implements that interface.

Note that if you were using a mocking framework, you wouldn’t need to do all of these steps. But I’m building this from scratch to better understand all of the working parts. It’s like studying classical music before trying to do jazz improvisation. 🙂

Note that BAGA is the name of the business in my book, Programming Entity Framework, which stands for Break Away Geek Adventures, so you’ll see that acronym a lot and it’s used in the namespaces and in the name of the repository.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data.Objects;
using POCOBAGA.Classes;

namespace POCOBAGA.Repository.Interface
{
  public interface IBAGAContext 
  {
     IObjectSet<Contact> Contacts{get;}
     IObjectSet<Customer> Customers {get;}
     IObjectSet<Trip> Trips{get;}
     IObjectSet<Reservation> Reservations { get; }
     IObjectSet<Payment> Payments { get; }

     void DetectChanges(); //used for ObjectContext detect changes
                           // or mock's fix-up mechanism
     int SaveChanges(); //used for ObjectContext.SaveChanges default behavior
                        // with no int return or parameters

     IEnumerable<Reservation> ManagedReservations { get; }
  }
}

This interface should look familiar. It returns a bunch of IObjectSets and the ManagedReservations that you saw in the context class (Part 1).

Also, you may recall seeing the interface referred to in that context class….

public class BAGAContext : ObjectContext, IBAGAContext

Just keep that little tidbit in the back of your mind while we look at the Query Repository

The Query Repository (or whatever I’ll be calling it…)

So now it’s time for the class where all the good stuff happens. This is where I run queries and persist data back to the database. It can be used by whatever class wants to get at my model’s data.

There are actually more methods in my repository. I’m only displaying the ones relevant for this discussion.

Discussion follows the code.

using System.Text;
using System.Data.Objects;
using POCOBAGA.Classes;
using POCOBAGA.Repository.Interface;
using POCOBAGA.Repository.Model;
using ExtensionMethods;

namespace POCOBAGA.Repository.Queries
{

    public class POCOQueryRepository
    {
        IBAGARepository _context;

        #region Constructors

        public POCOQueryRepository()
        {
            _context = new BAGAContext();
        }
        public POCOQueryRepository(IBAGAContext context)
        {
            _context = context;
        }

        #endregion

        #region Queries
      
        public IList<Reservation> GetReservationsForCustomer(int? CustomerID)
        {
            if (!CustomerID.HasValue || CustomerID.Value < 1)
            {
                throw new ArgumentOutOfRangeException();
            }
            return _context.Reservations.
              Where(r => r.ContactID == CustomerID).ToList();
        }
      #endregion

      #region Saving
      public string Save()
      {
            string validationErrors = "";
            if (PreSavingValidations(out validationErrors) == true)
            {
               //this Save is not taking n-tier issues into account
               _context.SaveChanges();
                return "";
            }
            else
                return "Data Not Saved due to Validation Errors: " + validationErrors;
        }

        public bool PreSavingValidations(out string validationErrors)
        {
            bool isvalid = true;
            validationErrors = "";

            foreach (Reservation res in _context.ManagedReservations)
            {
                try
                {
                    bool isResValid;
                    string validationError;
                    isResValid = res.ValidateBeforeSave(out validationError);
                    if (!isResValid)
                    {
                        isvalid = false;
                        validationErrors += validationError;
                    }
                }
                catch (Exception ex)
                {
                    throw ex;
                }
            }
            return isvalid;
        }

     }
}

This repository has two constructors. The first takes no arguments. If this constructor is called, then when the repository is instantiated, it will spin up a new context – specifically, the “real” context, the one which involves the EF APIs and interacts with the database. The overload to the constructor allows the calling code to pass in a context. What this will do for testing is allow us to pass in a fake context that won’t be so bound to EF or the database. As long as whatever is passed in implements IBAGARepository IBAGAContext, we’re good. That way we can safely use the context in this class and call methods such as _context.SaveChanges or _context.Reservations.

There are only two publicly exposed methods in this example. One is to perform a query and the other is to perform a save. The save has a helper method to ask entities to validate themselves. In this case, it only bothers to ask the Reservation objects to perform their validation. Note that this Save method does not take n-tier issues into account. It presumes that the context already has all of the necessary info for updating. Dealing with n-tier here would be out of scope of the discussion.

Thinking ahead about testing, these two methods provide a challenge for testing without hitting the database. The GetReservationsForCustoemr does some validation and then performs a query. There are a few things to test here. First I want to be sure the validation works. That will mean having a test that provides a bad value and making sure the validation detects that and throws the expected exception. This ones easy because I won’t have to worry about that query. But what about the test to ensure that a good ID passes the validation. I can’t say “okay but after you check that just STOP and don’t call the query. The query will have to run. But why do I want to hit the database when all I’m trying to do is test that the ID validation works. This is where the challenge comes in.

In the save method, my focus will be on the validations. I want to be sure that they do the right thing with bad data and do the right thing with good data. When testing this, I don’t really need to send the data to the database.

The interface is in it’s own project and has a reference to the classes project as well as System.Data.Entity. The only reason it needs System.Data.Entity is to get its hands on IObjectSet.

The Query repository project needs access to the classes, the repository interface and the model repository (with the model & ObjectContext).

In the next blog post we’ll start looking at the testing side of things for this solution and in doing so, some of the puzzle pieces that I put in place here will make more sense.

July 2015 note:
I’ve noticed a sudden interest in this six year old blog series. Please keep in mind that this demonstrates old code and old ideas. It uses the EF ObjectContext which is still around but you should be using EF DbContext instead. I also am no longer a big fan of usin classic or generic repositories unless I’m doing some straight CRUD and still want to encapsulate the DbContext interaction. EF6 now has much better support for mocking frameworks and I find going through the effort of faking the IObjectSet etc much more work than necessary.

Updated Information on Repositories:
Please check out the REPOSITORY module of the Domain-Driven Design on Pluralsight that Steve Smith and I authored. You can see more information on repositories.

Updated Information on Testing/Mocking with EF6: 
In my EF6 course on Pluralsight, the final module (“Sometimes It’s the Little Things“) demonstrates the new mocking capabilities with EF6.

If you do not have a Pluralsight subscription, send me a note and I can send you a code for a free 30 day trial!

I’m going to lay out this out in a few blog posts because it’s complex. As I am not a TDD developer, I won’t be starting from the tests. I’m doing this in a fashion which is logical to me. But that will mean you’ll get some teasers along the way that will be fleshed out further down the road.

1. Agile Entity Framework 4 Repository: Part 1- Model and POCO Classes
2. Agile Entity Framework 4 Repository: Part 2- The Repository
3. Agile EF4 Repository: Part 3 -Fine Tuning the Repository
4. Agile EF 4 Repositories Part 4: Compiled LINQ Queries
5. Agile Entity Framework 4 Repository Part 5: IObjectSet and Include
6. Agile Entity Framework 4 Repository: Part 6: Mocks & Unit Tests

I should be working on my 2nd Edition of Programming Entity Framework, but it’s driving me crazy that this information is so hard to find even though I’ve been doing conference and live meeting presentations on it.  The info in this post is also in the book, just laid out [very] differently.

A tiny bit of background

Entity Framework 4 supports POCO classes that do not inherit from Entity Object.

This is possible in two flavors.

Flavor 1: Snapshot Notification
Rather than depending on the EntityOBject to notify the context of changes to scalar property values or relationships, the context is now responsible for getting a snapshot of the entity state using ObjectContext.DetectChanges. You can call this method yourself or just let SaveChanges call it for you (a default).

Note that you don’t get lazy loading support with snapshot, however, without IRelatedEnd.Load available, you’ll need to use the context’s new LoadProperty method to do an explicit load.

Flavor 2: Proxies

If you mark EVERY property of your POCO class as virtual (Overrideable in VB), then EF will perform a neat trick. It will spin up proxy EntityObjects on behalf of the POCO class which will do what EntityObjects already know how to do – notify the context of changes to properties & relationships as well as allow lazy loading.

You can find more in-depth details on these on the team blog here:

POCO in the Entity Framework: Part 1 – The Experience

POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

POCO in the Entity Framework : Part 3 – Change Tracking with POCO

Also, I’m waiting for my live meeting recording on EF4 POCOs (from www.notatpdc.com) that I presented last night to be available. Will blog when it is.

The Model

So first, here is what my model looks like.

My classes need to expose (public or private actually) a property for every property in the entity. YOu can have additional properties and methods if you want.

Here are two of my classes. Customer which is extremely simple, looks almost like a DTO, and Reservation which includes a method to return PaymentStatus and some validation logic as well.

Notice that the Customer properties are not virtual but the Reservation properties are. I have different requirements for these classes within my app.

CUSTOMER

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace POCOBAGA.Classes
{
  public class Customer
  {
    public int ContactID { get; set; }
    public int CustomerTypeID { get; set; }
    public Nullable<System.DateTime> InitialDate { get; set; }
    public Nullable<int> PrimaryDestinationID { get; set; }
    public Nullable<int> SecondaryDestinationID { get; set; }
    public Nullable<int> PrimaryActivityID { get; set; }
    public Nullable<int> SecondaryActivityID { get; set; }
    public string Notes { get; set; }
    public byte[] timestamp { get; set; }
    //navigation properties
    public Contact Contact { get; set; }
    public ICollection<Reservation> Reservations { get; set; }
  }
}

RESERVATION

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace POCOBAGA.Classes
{
    public enum ePaymentStatus
    {
        UnPaid = 1,
        PartiallyPaid = 2,
        PaidInFull = 3,
        OverPaid = 4,
        NotAvailable=5
    }
    public class Reservation
    {
        public virtual int ReservationID { get; set; }
        public virtual System.DateTime ReservationDate { get; set; }
        public virtual Nullable<int> ContactID { get; set; }
        public virtual Nullable<int> TripID { get; set; }
        public virtual byte[] TimeStamp { get; set; }
        //navigation properties
        public virtual Customer Customer { get; set; }
        public virtual Trip Trip { get; set; }
        public virtual ICollection<Payment> Payments { get; set; }
        //other logic
        public ePaymentStatus PaymentStatus()
        {
            int TripCost = Trip.TripCostUSD.Value;
            decimal PaymentSum = Payments.Sum(p => p.Amount);
            if (PaymentSum == 0)
            {
                return ePaymentStatus.UnPaid;
            }
            else
            {
                if (TripCost > PaymentSum)
                { return ePaymentStatus.PartiallyPaid; }
                else
                {
                    if (TripCost == PaymentSum)
                    { return ePaymentStatus.PaidInFull; }
                    else
                    { return ePaymentStatus.OverPaid; }
                }
            }
        }

        public bool ValidateBeforeSave(out string validationError)
        {
            bool isvalid = true;
            validationError = "";
            if (TripID == null)
            {
                isvalid = false;
                validationError = "Trip";
            }
            if (ContactID == null)
            {
                isvalid = false;
                validationError += ",Contact";
            }
            if (ReservationDate == null)
            {
                isvalid = false;
                validationError += ",Date";
            }
            if (validationError != "")
                validationError = "[ReservationID " + ReservationID.ToString() + ": " + validationError + "]";
            return isvalid;
        }
    }
}

The PaymentStatus method presumes that the Reservations have been loaded and doesn’t care how that’s taken care of. Because I have set up the Reservations class (and the Payments class which is not shown) to allow lazy loading, I know that the ObjectContext will take care of it for me if necessary. (There are a few caveats around this that I’m not going to dig into since this is enough to build up the example and make the points I want to make.)

The ValidateBeforeSave method is available so that I can let a Reservation be responsible for its own validation when it’s time to save. I’ll still have to call it from somewhere and that will be the same place I call SaveChanges. You’ll see.

The Project for my POCO Classes

The classes are in their own project.

Note that this project does *not* have a reference to System.Data.Entity.

That’s it for the classes.

The Model Repository

Now for what I call the Model Repository.

This is where the Entity Framework lives, my model, my context and interaction with the database.

There are two critical items in this project: my model and a class which inherits from ObjectContext.

The project has a reference to System.Data.Entity and to the project with the classes.

The Model (again)

The key to my model is that it does *not* do code generation. Notice that in the model’s File Properties, the “Custom Tool” property is empty. I have removed the default,  “CustomTool=EntityModelCodeGenerator”.

I have constructed my classes by hand as well as the context which will manage my classes. You could use T4 to generate your classes. I’m not in this scenario.

11/24: Adding some more emphasis re: T4. In this blog post my goal is for you to see what the classes look like, not how to create them. As we go through the posts it will become more apparent that code generation can be enormously helpful to automatically generate not only these classes, but the repostories and the context, from the model.

The Context

The classes have no clue about EF. So we need EF to be aware of the classes. The context’s job is to enable querying against the entities/classes, to keep track of their state and to persist them back to the data store. When you use the default code gen, an ObjectContext class is created to do this. You *must* do the same for your POCO classes. I’ve built my context class by hand.

ObjectSet is new to EF and critical to POCO support and agile development. ObjectSet is the strongly typed class that represents an EntitySet in the model. ObjectSet implements IObjectSet and inherits from ObjectQuery. If I weren’t building a repository, I would just return ObjectSet’s from my context just like the default generated context does. However, I need more flexibility so I am going to return an IObjectSet, e.g. any class that implements IObjectSet. Just make note of this and you’ll see where it fits in further on in a latter part of this blog post series.

Another notable  piece of this context, also that you’ll see come into play later on, is the fact that my class not only inherits from ObjectContext, as it needs to, but that it implements another interface, IBAGARepostiroy. This is my own custom interface and I’ll show it when we get to the testing part of this series. Just keep it in the back of your mind.

For now pay attention to the fact that I expose the IObjectSets of the various classes that I want to query. This means that with this class, BAGAContext, I can write LINQ to Entities queries such as context.Customers, or Context.Reservations.Where(r=>r.ReservationID=3). Because I’m quering from an ObjectContext, the objects that are returned from the query will be managed by the context as well. Even my POCO objects.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data;
using System.Data.Objects;
using POCOBAGA.Classes;
using POCOBAGA.Repository.Interface;

namespace POCOBAGA.Repository.Model
{
    public class BAGAContext : ObjectContext, IBAGARepository
    {
        private IObjectSet<Customer> _customers;
        private IObjectSet<Trip> _trips;
        private IObjectSet<Reservation> _reservations;
        private IObjectSet<Contact> _contacts;
        private IObjectSet<Payment> _payments;

        public BAGAContext()
            : base("name=BAEntities", "BAEntities")
        {
            ContextOptions.LazyLoadingEnabled = true;
            _contacts = CreateObjectSet<Contact>();
            _customers = CreateObjectSet<Customer>();
            _trips = CreateObjectSet<Trip>();
            _reservations = CreateObjectSet<Reservation>();
            _payments = CreateObjectSet<Payment>();
        }
        public IObjectSet<Contact> Contacts
        {
            get
            {
                return _contacts;
            }
        }
        public IObjectSet<Payment> Payments
        {
            get
            {

                return _payments;
            }
        }
        public IObjectSet<Customer> Customers
        {
            get
            {
                return _customers;
            }
        }
        public IObjectSet<Trip> Trips
        {
            get
            {
                return _trips;
            }
        }
        public IObjectSet<Reservation> Reservations
        {
            get
            {
                return _reservations;
            }
        }
        public IEnumerable<Reservation> ManagedReservations
        {
            get
            {

                IEnumerable<ObjectStateEntry> oses =
                    this.ObjectStateManager.GetObjectStateEntries
                    (EntityState.Added | EntityState.Deleted |
                     EntityState.Modified | EntityState.Unchanged);
                return oses
                    .Where(entry => entry.Entity is Reservation)
                    .Select(entry => (Reservation)entry.Entity);
            }
        }

    }
}

There’s one last point to make about this class. I expose a property called ManagedReservations. I love this property. It gives me back all of the reservation objects that are currently being managed by the context. Why ask the developer to know how to do that or even know that it’s a bit of a challenge to get them. Many people would accidently execute another query against the database when they want just to see what’s in memory. This little method deserves its own blog post. 🙂

Okay, so that’s the end of Part 1.

In Part 2, we’ll look at the other “half” of the repository, the place where your queries and other logic necessary to interact with the context live. For example, GetReservationsByID and Save.

Not at PDC? Well, yeah PDC is having some sessions streamed, like keynotes etc, but for the rest of us, there’s www.notatpdc.com. Two days of live presentations on lots of great topics.

Here’s a screenshot of the schedule so far (note that it is CENTRAL time). Go to the website to get speaker and session details.

The abstracts for my two talks are as follows:

Entity Framework v1 made Agile .NET developers very unhappy because it did not support Persistence Ignorance or the ability to create true POCO objects. But the next version has been created with a lot of input from ALT.NET and Domain Driven gurus. If you want to design a model and wire it up to your objects or forget the model completely and have EF infer all that it needs from your objects, you’re covered. Unit Testing? Repositories? You’re still covered.

Part 1: Understand how to create POCOs and how to integrate them into EF. This is what will be covered in Part 1.

Part 2: In this session you’ll see a solution that uses a repository and mocks to enable unit testing with your POCO entities.

I knew that Intellitrace existed, but not until I saw Nikhil Kotahari’s tweet from PDC09

“Cool VS demo – intellitrace – see your db queries, and track it back to your LINQ code #pdc09”

did I think to look at what IntelliTrace reports with respect to Entity Framework database interaction.

I fired up a sample that executed a query and then demanded some lazy loading to take place.

IntelliTrace picked up the explicit query execution but not the queries executed by lazy loading. They must be too deep in the pipeline.

In the screenshot below, tracing is displayed from the top to the bottom. I can see the step just before the query is executed , the actual command that was sent to the database and then a number of steps after that.

By the time the 8 steps were hit after the first query, my code had performed two hits to the database for lazy loading. So unfortunately, IntelliTrace is not picking them up.

I checked what happens with an explicit load (e.g., myContact.Addresses.Load()) and I can see the query in IntelliTrace. The first query (highlighted) is the explicit query, the second one, expanded, is the result of the call to Load.

I ran another bit of code that did an update via SaveChanges, and IntelliTrace did pick up the database call.

Of course, now that I have EFProf, I can see each and every call to the db, including Lazy loading calls, plus I get extra bells & whistles.

In an earlier post, I wrote about the new awesomeness that ASP.NET 4.0’s Dynamic Data brings to many to many relationships.

I frequently notice that most DD demos demonstrate creating the data model within the same project as the DD website.

Even though a typical Dynamic Data app is for RAD development and isn’t focused on application architecture (come on, the data access is buried in the UI), I still can’t bare to store my model inside of the UI project. All of my EF Entity Data Model’s are housed in their own projects.

This is not a problem at all for a Dynamic Data site. Like any other project that leverages an EDM in a separate project, you only need to perform three steps to point to the external model:

1. Add a reference to the project that contains the data model
2. Add a reference to System.Data.Entity.dll
3. If it’s the executing app (in this case it is), provide the EntityConnection string, most typically by adding it into the web.config file

For Dynamic Data, there is one additional consideration that I was torn over.

I have my model in it’s own project because I like to be able to reuse it in other applications.

In a DD site, I typically do  not expose the *entire* model for the scaffold (e.g., for use in the dynamic application). Instead, I set ScaffoldAllTables to false in the global asax file:

 DefaultModel.RegisterContext(typeof(MyEDM.MyEntities), 
     new ContextConfiguration() { ScaffoldAllTables = false });

and explicitly mark the classes which I want to include with the scaffold attribute:

[ScaffoldTable(true)]

And here is where I run into the conundrum.

The ScaffoldTable attribute is something that I specifically want for the Dynamic Data site. It’s not needed by any other apps that might be using my model. The only way to add it to the generated class in my model project is to use partial classes. As far a I know*, partial classes need to be in the same project as the rest of the partial classes so that the compiler can pull them all together. That means, I’m forced to “dirty” my model project with the attributes that are meaningless to any other application that might also use my model. Fortunately, the ScaffoldTable attribute is in System.ComponentModel.DataAnnotations, not System.Web.DynamicData, so it doesn’t feel so bad. I suppose that because I’ve been focused on repositories and MVC lately, this is why I’m feeling so anal about this and perhaps it’s overkill.

My first instinct, because I was looking for separation, was to put the partial classes with the attributes into the dynamic data project, but of course I was quickly reminded by the error message telling me that I had ScaffoldAllTables set to false but I had not designated any classes to be used, that the extra partial class logic was not getting picked up by my classes because it was in the wrong project. So I bit my tongue and put them where they belonged, into the model’s project.

An approach that I’m considering is having different code generation templates for my model, so that I can generate entity classes to be used in different applications. Even so, I wouldn’t automatically mark all of the entities as a ScaffoldTable anyway. So I’ll have to think a bit more about that if I’m going to really worry about implementing it.

In the meantime, the key takeaway here is that you can have the model in a separate project to be used by Dynamic Data apps and you can specify which entities to use. You just need to include the partial classes with the ScaffoldTable attributes in the EDM’s project, not the Dynamic Data project where you might think you really want them to be.

*just a small caveat on the partial classes rule in case something changed in .NET 4.0 that I’m unaware of.  I don’t know how they would pull it off, but hey, you never know! 🙂