Lazy-Loaded BLOB Property

NEW "TABLE SPLITTING" ANSWER 

I just learned about a new feature in Entity Framework v.4 called "Table Splitting".

It isn't the lazy property we really want but it gives us a foundation for a decent simulation of lazy property ... and it works now, with DevForce 2010.

Btw, Danny Simmons (EF Team) says they wanted to get Lazy Property into EF 4 ... and ran out of time. At least it's on their roadmap.

Table Splitting

Apparently EF always had the ability to map two entities to the same table, "splitting" the columns/properties between the two. 

They called it "Table Splitting", not to be confused with "Entity Splitting" ... which is when a single entity is mapped to two separate tables. "Table Splitting" and "Entity Splitting" are opposites. Just try to remember which is which :-)

In our example of "Table Splitting", we create an Employee entity (with properties mapped to every column EXCEPT photo) and an EmployePhoto entity (with two properties, EmployeeID and Photo, mapped appropriately).

I said earlier that EF didn't support this trick. I wasn't entirely right about that. Apparently EF v.1 supported it. Unfortunately, the EF Designer did not and would refuse to validate the model. This circumstance parallels EF v.1's support for complex types; yes, they were there ... but the Designer threw a fit if you tried to use it.

You can read all about "Table Splitting" ... and how to do it ... from Gil Fink here: 
http://blogs.microsoft.co.il/blogs/gilf/archive/2009/10/13/table-splitting-in-entity-framework.aspx 

Here's some example DevForce code to illustrate the point:

  void GetEmployeesWithLazyPhoto {

      var em = new NorthwindIBEntities();

      // Get first three employees ... without their photos
      var emps= em.Employees.Take(3).ToList();

      // Prove that we did not get the EmployeePhoto entities at the same time
      var photos = em.EmployeePhotos.With(QueryStrategy.CacheOnly).ToList();
      System.Diagnostics.Debug.Assert(!photos.Any()); // there aren't any photos

      // Get the photo of the first employee
      var firstPhoto = emps.First().EmployeePhoto;
      System.Diagnostics.Debug.Assert(
         !firstPhoto.EntityAspect.IsNullEntity);// now we have it
  } 

---
Notes:

(1) Yes, you can use INCLUDE to get the photos eagerly with the Employees:

   var emps= em.Employees.Include("EmployeePhoto").Take(3).ToList();

(2) Employee must be the "principal" entity and EmployeePhoto must be the "dependent" entity to ensure that a new Employee is always inserted before EmployeePhoto. You'll get that arrangement if you follow Mr. Fink's recipe.

I've tested the query. I haven't tested adding new Employees or EmployeePhotos. This note is more of a prediction than a prescription. I'm not sure what happens if you try to add a new EmployeePhoto before adding its Employee. 

(3) If you want to be able to create new Employee objects, the Photo column in the Employee table must either be nullable or have a database default value. Entity Framework has to be able to insert a new Employee table row without specifying a value for the Photo column. Nothing new here ... just good old SQL.

(4) The entity referential integrity check should take care of deleting the EmployeePhoto when you delete the parent Employee. Haven't confirmed yet.  Of course deleting the Employee effectively deletes the EmployeePhoto regardless ... because deleting the table row deletes both.  

I do not know yet what happens if you try to delete EmployeePhoto. Presumably the Referential Integrity check will prevent this.

The net of these considerations is that you should hide them all from Employee consumers. You don't want them worrying about this stuff. You want them to think of the photo as part of the Employee ... not as another entity.

If you don't need to search for Photos independent of the Employee (and why would you?), I would try to make the EmployeePhoto entity internal to the domain model assembly.

[Again, haven't tried this yet either. Thinking out loud.]

Of course that means no consumer would ever see the EmployeePhoto entity. That's just fine. I'd make the Employee.EmployeePhoto navigation property internal as well or maybe private. 

I'd create a public Photo class (if necessary). I'd add a custom Photo property for Employee, implemented such that it used the non-public EmployeePhoto property to acquire the photo and poured the photo bytes into an instance of the Photo class; this Photo class instance, not the EmployeePhoto entity, is what I'd return to the caller.

I'd also bury the mechanics of making a new EmployeePhoto inside this custom Employee.Photo property. Or maybe I'd create Employee.AddPhoto, Employee.UpdatePhoto, and Employee.DeletePhoto methods instead. It's up to you. The point is to encapsulate the mess.

Now it may be that the caller can no longer compose the query that eagerly loads EmployeePhotos with their employees (see Note #1). 

I haven't tried this yet (as I keep saying). If so, that's fine with me. If I want eager photo loading, I should cover the query in my Repository class which DOES have access to the internal EmployeePhoto entity. I don't want outsiders to see me making sausage.

You do have a Repository class, right? You don't let your UI query all by itself do you? That's not good design. Once you start thinking seriously about how and when to expose entities, you'll know that you want to encapsulate all the persistence machinery - including DevForce persistence machinery - in a Repository or "DataService" class.

For the last time, I haven't tried these refinements yet. I'm broaching them in case you want to be a pioneer.