Just a friendly reminder that I’m passing on from one of the tech reviewers of my book who (thankfully) noticed that I had left a note in there about Single & SingleOrDefault not being supported.

They were not in .NET 3.5 SP1 Entity Framework, but they are now supported in EF4.

Single is the way to go when you only expect one item to be in your result set.

As noted by many, the benefit of Single is highlighted in testing. Single expects only one item to be in the result set. If there are more, then an exception is thrown and this can help you discover logic errors in your application.

For a list of supported & unsupported LINQ methods used (or not used) in LINQ to ENtities, see the MSDN Topic: Supported and Unsupported LINQ Methods (LINQ to Entities)

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 EF4 Repository: 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 Part 2 of this blog series, I created a context interface, IBAGAContext, that returns IObjectSet types rather than ObjectSet types from the EntitySets.

Example:

     IObjectSet<Contact> Contacts{get;}
     IObjectSet<Customer> Customers {get;}
    

IObjectSet is the new EF4 interface that is used to create the ObjectSets returned by the default context.

For a point of comparison, here’s a method from a default code generated context:

 public ObjectSet<Activity> Activities
        {
            get
            {
                if ((_Activities == null))
                {
                    _Activities = base.CreateObjectSet<Activity>("Activities");
                }
                return _Activities;
            }
        }
        private ObjectSet<Activity> _Activities;

ObjectSet implements IObjectSet which provides it with set operations. It also inherits from QueryObject which gives it lots of EF capabilities. One of the methods that come with QueryObject is Include which provides eager loading.

context.Customers.Include(“Orders”) blah blah

(A few people, including Matthieu Mezil, have created overloads for Include that take lambdas instead of magic strings. Here’s Matthieu’s second of two posts which contains a link to the first: Entity Framework Include with Function Next. Additionally, Jamie Philips had a lambda function for EF1 that allowed further filtering. Last time we talked, he reported that it wasn’t working with EF4 POCOs.)

But Include is not available with IObjectSet.

In a recent comment, Nick asked how I was using Include on an IObjectSet.I realize I neglected to add that into the relevant post.

With nods to Jamie Phillips again, Include came from his POCO sample when he and I co-presented back-to-back EF4 POCO sessions at the New England Code Camp in October.

Jamie created an Include extension method to replace the Include supplied by the ObjectQuery. I placed the method in a separate class file in the same project that contains the model and the BAGAContext file because it simply calls the real ObjectQuery.Include.

namespace ExtensionMethods
{
  public static class MyExtensions
  {
    public static IQueryable<TSource> Include<TSource>
      (this IQueryable<TSource> source, string path)
    {
      var objectQuery = source as ObjectQuery<TSource>;
      if (objectQuery != null)
      {
        return objectQuery.Include(path);
      }
      return source;
    }
  }
}

In the repositories in Part 3 of this series, this is how I was able to use the Include method.

Jamie did write a follow-up post about the problem with the lambdas and POCO classes: Include() Extension Method and POCO

One of the things I struggled with in n-Tier apps in EFv1 was the options for reconstructing entity state on the server side in order to call SaveChanges when modified data was passed in from the client.

The options were to hit the database to get a set of current server values and then apply updates to those or to just attach the incoming data and iterate through each property marking it as modified so that SaveChanges would be able to construct an Update.

The problem with the former was the extra hit to the database. That made me crazy.

The problem with the latter is that I was marking every property as modified even when they weren’t and that made me crazier. Admittedly not really worse than the first.

If you’ve seen the WCF chapter in my book, you’ll know I opted for the extra database hit.

In EF4, there are new state methods. In addition to ApplyPropertyChanges (from v1) being renamed to ApplyCurrentValues and acquiring a sibling, ApplyOriginalValues, there is the ChangeState method. I explored the impact of these methods in my Sept/Oct 2009 CoDe Magazine article, What’s New in Entity Framework 4? Part 1: API Changes .

I want to focus now on using ChangeState to set an entity to Modified.

This is similar to walking through each property and marking it modified. The concept is that you are saying “this entity is modified” without having to specify exactly what was modified. Every property is marked as modified and every property will be included in an update statement.

But what if every property was not supplied?

What if you have a client app that allows users to edit a few fields of a contact record. And…the client app is a website which means that when the user hits a Save button and the page posts back, there’s no original contact object. So in order to save, in one layer or other, some code constructs a contact to return to the server/repository. Here’s the code:

Contact c = new Contact {ContactID= Convert.ToInt32(IDLabel.Text),
        FirstName = TextBox1.Text, LastName = TextBox2.Text,
        ModifiedDate = DateTime.Now, State = State.Modified };

I have a state property in there because this is a POCO object and I can put whatever I want in it. 🙂 Plus I use the state property to help me out when I get to the server side.

Looks okay, but what if I told you there is also a Title property in this class?

Because the UI developer didn’t populate that value, on the server, the assumption will be that Title is null. When you call ChangeState(EntityStateModified), that null will be seen as the value to be used for the update. Take a look at part of the update method sent to the database. It’s setting Title=null.

exec sp_executesql 
N'update [dbo].[Contact]
set [FirstName] = @0, [LastName] = @1, [Title] = null, [ModifiedDate] = @2
where...

This is not to say that there’s anything wrong with the ChangeState method (or ApplyCurrentValues/ApplyOriginalValues, which will do the same thing). THe point (as always) is that you really need to be aware of what’s going on.

My worry is that I can’t really control what’s happening on the consumer side. It’s such a critical rule. I don’t want to “solve” it by making all of my properties non-nullable. (Can you imagine? 🙂 )

So it means that I have to think carefully about how and where I use these methods because I may not always have control of the state of what’s being passed in.

I was getting accustomed to the idea of just marking all of the properties modified and living with the inefficient update. One inefficient trip to the database is more cost effective than two trips to the database.

There’s always the CACHING option. But that gets really sticky with multiple users and graphs and lazy loading etc. I know I can cache my POCOs, even my graphs, or just values if I want… easily enough. I was just hoping to avoid that extra layer for now.

So I either have to make the consumer cross-their-heart-and-hope-to-die-promise to return the entire object back to me with the correct values or I have to go back to using some of the options from EFv1 – hit the database, manually (and selectively) mark each properites as modified or pass original values around.

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

• What’s New in Entity Framework 4? Part 1: API Changes (Sept/Oct 2009)
• What’s New in Entity Framework 4, Part 2: Modeling Changes (Nov/Dec 2009)

DevConnectionsPro Magazine (was aspNETPro Magazine)

• Renovations to .NET 4.0’s Entity Framework (Nov 2009)

(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.)

• Entity Framework 4, Beta 2 is Here (Jan 2010) Not online yet

Visual Studio Magazine

• Contributions to Entity Sequel by Jeffrey Schwartz

Webcasts

• Agile Entity Framework Part 1: POCO Classes  NotAtPDC.com, Nov 2009 (75 min.)
• Agile Entity Framework Part 2: Repositories & Testing  NotAtPDC.com Nov 2009 (75 min.)
• Upcoming: Tour the Top Ten Treats in EF4 OReilly.com Jan 27, 2010

Screencasts

• Screencast – What’s new in the Entity Data Model Designer in VS2010 (20 min.)

Interviews

• Channel 9 Øredev chit-chat: Dag König and Julia Lerman
• 5 Minutes WIth …Julie Lerman

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.