Model-Defined Functions are one of the great new features of EF4. The only downside is that it’s a little kludgey to call them from LINQ to Entities.
Jiri Cincura has a simple, but elegant workaround – the ever agile Extension Methods!
Model Defined Function as a method on entity (or on type for store function)
Not sure if I’ve blogged all of these (so twitter-addicted these days) so here’s a list of recent articles & webcasts I’ve done on EF4.
CoDe Magazine
DevConnectionsPro Magazine (was aspNETPro Magazine)
(Note that the images for the article can be seen via hyperlinks. Wherever it says “as shown in Figure X”, there’s a hyperlink on Figure X and you can the see the image. Penton is working on the website, so hopefully this will be more obvious in the future.)
Visual Studio Magazine
Webcasts
Screencasts
Interviews
Blog
Lots of blog posts on EF4 under the EF4 tag: thedatafarm.com/blog/tags/ef4
The Book
I’m hard at work on the 2nd Edition of my book, Programming Entity Framework which will be based on EF4. Look for the Rough Cuts version to appear soon on OReilly.com.
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
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
Powerpoint-> http://www.slideshare.net/JulieLerman/agileentity-framework-4
Third post in my Agile EF4 Repository blog series:
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
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.
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.
Five years ago, I wrote this blog post about a tree on our property.
I see this tree all day long while I’m working. This tree is like the ocean. In the summer when it is full green and the wind is blowing, it is absolutely mesmerizing to watch it. I have never loved a tree before, but I love this tree.
Two summers later, I was on the phone during a thunderstorm, with Don Smith from Microsoft’s Patterns and Practices group (who is sure to remember this incident), when lightning struck our house. The next day, I discovered that it had also struck the tree.
Over the next few years, half of the tree was clearly dead. This past summer, the other half succumbed as well. We knew it was a goner but even barren, it was still beautiful. However, it had become a liability because, though the tree was might and strong even when dead, its huge branches were coming down when we had big winds.
So today, Rich finally did the deed and cut the tree down. It’s funny to be sad about a tree. And i will provide a LOT of fuel for us since we are getting a wood stove soon. But still, it was a thing of beauty.
And deserving of one last blog post.