One of the benefits of Visual Studio’s multi-targeting is that if you are still stuck using the .NET 3.5 version of Entity Framework and are unable to move to EF4 (so sad), you can still get the new designer goodies for a .NET 3.5 project.  Remember that the designer is a VS2010 feature, not a .NET 4.0 feature.

Be sure to select .NET 3.5 when you create your project:

When you add the model, you’ll notice that the foreign key checkbox is disabled. FK support is not only an EF4 designer feature but it is dependent on .NET 4. But you can still get the much needed pluralization support.

Once the model is created, you can take advantage of new designer features such as the complex type support. Complex tyeps existed in .NET 3.5 but the designer did not support them making it painful to take advantage of them.

Here is that complex type in an entity that was retrieved from the database.

Model First works too:

Not every new designer feature will work with an older model though.

T4 code generation won’t. You can select “Create Code Generation Item” from the context menu, but no templates will be available.

EF 3.5 uses a different type of code generation.

Function Import will NOT provide the nifty EF4 support for mapping stored procedure results to Complex Types:

Without the Foreign Key support, the model will use what’s called “Independent Associations” in other words, the same type of associations that we were limited to in .NET 3.5 where the association was dependent on the mappings.

Even though the designer has a referential constraint in the properties window, you can’t build it with this model because the foreign key is not available.

(With an EF4 model, you can use either Independent Associations or Foreign Key Associations.)

So if you are stuck building EF v3.5 apps (oh please please move to EF4, life will be SO much happier!), you can still get a lot of benefit from using VS2010’s designer.

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.