Complex types, in the simple minded way I see them, are a way to split information retrieved from a table into a object within an object. Confused yet? I hope so.

Say you have a User table and on that table you have the typical user information including a bunch of stuff like Name, Sex, City, State, and Zip. Now you could set up the user class to look like this:

  public class User
  {
    public String Name { get; set; }
    public String City { get; set; }
    public String State { get; set; }
    public String Zip { get; set; }
  }

Nothing wrong with that, but what if you have an Address class:

  public class Address
  {
    public String City { get; set; }
    public String State { get; set; }
    public String Zip { get; set; }
  }

That you wanted to map the values from the User table to the User class to so that the User class looked more like this:

  public class User
  {
    public String Name { get; set; }
    public Address Address { get; set; }
  }

Well I'm here to tell you that you can and I have plenty of pictures to back it up.

Keeping with the design from this guy, I am going to add a new class called AdDimension which will have Height and Width, effectively replacing the Height and Width properties on the Ad class.

RECAP - Old class diagram:

So the first thing I have to do is is create the complex type in the Model Browser. That's pretty easy. There's a section called "Complex Types" and you just add one.

See, there's a picture. Next step is adding properties to the newly created complex type.

Another picture! Ok so now you've created on, big deal. Now what? Well you have to add a complex type property to the main class, Ad in this case.

Now if you have more than one complex type, you might have to set the property type to the correct one. Just right click the complex property and click on properties:

Now, you'll have to adjust the mapping for the entity itself. So click on the object and bring up mapping properties. From there, select the correct mapping for the correct column. In this example it's width and as you can see in the drop down there is a AdDimension.Width property to set it to. Cool huh?

And that's it for the object model. Next you have to add the AdDimension class and add a property to the Ad class.

  public class AdDimension
  {
    public Int32 Height { get; set; }
    public Int32 Width { get; set; }
  }

  public class Ad
  {
    ...
    public AdDimension AdDimension { get; set; }
    ...
  }

And then how do you set it?

  someAd.AdDimension = new AdDimension();
  someAd.AdDimension.Height = 10;
  someAd.AdDimension.Width = 10;

And it can even be used in queries:

  context.Ads.Where(ad => ad.Width > 10);

Now there are things to be aware of. Complex types can't inherit from other complex types and the property can't be null when saving. Just be aware of that.

I'm telling you man, this s-- is the s--- man. It's the s---.

• .Net 4.0 Beta 2 Entity Framework – Many To One and POCO / INSERT statement conflicted with the FOREIGN KEY constraint issue
• .Net 4.0 Beta 2 Entity Framework – How To Start
• Entity Framework: Am I Just Being Stubborn?
• Entity Framework: LINQ to Entities only supports casting Entity Data Model primitive types

Taking the structure from the last post, I added an AdType. It's very simple. Columns are AdTypeId (Int Primary) and Description (Varchar). I added a AdTypeId column to the Ad table and created a foreign key to the AdType table with it.

Basically Many Ads to One AdType.

Then I did the usual Update Model From Database with the .edmx file. Same old same old. Well this added the AdType class and the relationship:

So far, so good. Now with this it also means that I need to create the AdType class and add the AdType property to the Ad class along with the AdTypeId property.

Side Note:

Far as I can tell, you need the AdTypeId property despite also having the AdType property. Don't forget this.

Here's the AdType class:

  public class AdType
  {
    public Int32 Id { get; set; }
    public String Description { get; set; }

    public virtual IList<Ad> Ads { get; set; }
  }

And on the Ad class I had to "Ad" (HARHRHARHR) the AdType property along with the AdTypeId property:

  public class Ad
  {
    public Int32 Id { get; set; }
    public DateTime CreatedDate { get; set; }
    public String Name { get; set; }
    public DateTime? LastUpdated { get; set; }
    public Int32 Height { get; set; }
    public Int32 Width { get; set; }

    //Interesting note: Works even if this is private and non virtual
    private Int32 AdTypeId { get; set; }

    public virtual AdType AdType { get; set; }
    //Note:
    //If properties are to be lazy loaded, must be virtual
    public virtual IList<Newpaper> Newspapers { get; set; }
  }

Classes are done. Should be good to go right? WRONG YOU ARE SO F-ING WRONG! Just try this, I dare you:

   Ad ad = new Ad();

   ...
   ad.AdType = someAdType();
   context.Ads.Add(ad);
   context.SaveChanges();

DUN DUN DUUUUN INSERT statement conflicted with the FOREIGN KEY constraint.

You try it? Idiot. You just got stuffed by a foreign key error. Why? Well The Big M has an answer:

In this example, Customer is a pure POCO type. Unlike with EntityObject or IPOCO based entities, making changes to the entity doesn't automatically keep the state manager in sync because there is no automatic notification between your pure POCO entities and the Entity Framework. Therefore, upon querying the state manager, it thinks that the customer object state is Unchanged even though we have explicitly made a change to one of the properties on the entity.

Basically because these objects aren't really being watched by the State Manager, it has no idea anything has changed and should be persisted. Therefore, it has no idea that the AdType property has changed and that the AdTypeId should be updated to reflect this. That's right, it just ignored the AdType property and left the AdTypeId to it's default... 0 (That's a Zero or as the English say, Zed). How do you get around this? This little option.

  context.SaveChanges(System.Data.Objects.SaveOptions.AcceptAllChangesAfterSave);

This tells it to persist the changes that it didn't know about. Now I'm still picking this up as I go so bare with me as I might have the best explanations yet on why things work with the New Entity Framework. Then again, this is a site by a tool.

• .Net 4.0 Beta 2 Entity Framework – How To Set Up Complex Types, Now With More POCO
• .Net 4.0 Beta 2 Entity Framework – How To Start
• Entity Framework: Am I Just Being Stubborn?
• Entity Framework: LINQ to Entities only supports casting Entity Data Model primitive types

After doing a little reading, and by little I mean as little as humanly possible while still having an idea of what I'm doing, I got the new EF to persist an object. Mind you, it took a bit of patience followed by slamming my head into my desk and then more patience, but I did it.

First off, the actual creating of the edmx file is the same, there's really no difference. You still go through the wizard, you still go through the connection set up, and you still grab the tables you want. No change there.

However, once you have it created, click on the .edmx file in your solution explorer, right click, then click properties. You'll see something like this:

You can see where there is nothing in the Custom Tool area of properties. That's because I deleted the text. That's the first part of what you need to do. Next is creating the needed classes. For this example I have two, Ad and Newspaper:

namespace Beta2Test.Data.Entity
{
  public class Ad
  {
    public Int32 Id { get; set; }
    public DateTime CreatedDate { get; set; }
    public String Name { get; set; }
    public DateTime? LastUpdated { get; set; }
    public Int32 Height { get; set; }
    public Int32 Width { get; set; }

    //Note:
    //If properties are to be lazy loaded, must be virtual
    public virtual IList<Newspaper> Newspapers { get; set; }
  }
}

and

namespace Beta2Test.Data.Entity
{
  public class Newspaper
  {
    public Int32 Id { get; set; }
    public Int32 Circulation { get; set; }
    public DateTime CreatedDate { get; set; }
    public DateTime LastUpdated { get; set; }
    public String Name { get; set; }

    //Note:
    //If properties are to be lazy loaded, must be virtual
    public virtual IList<Ad> Ads { get; set; }
  }
}

Three things you might notice:

1. The classes don't inherit from anything. Yay
2. The namespace is Beta2Test.Data.Entity. Fact is, I left it there to show that the namespace can now be anything. Yay
3. Both collection properties are virtual. This is a must when dealing with collections that represent a relationship and you have lazy loading enabled (See below context class). For this, there is a many to many relationship between Ads and Newpapers. The Ads and Newspapers collection represent that. Why do that have to be virtual? Has to do with Entity Framework needing a way to override the properties so it can tell when they are accessed. (Read: Lazy Loading)
4. There is no fourth thing. You are wrong if you think there is.

So far so good, but what about that like whole linking to that persistence layer stuff. You know like them entity objects yo.

Thank you for that poorly worded inquiry, but valid none the less. Remember those entity context classes that it used to generate for you? Well that whole "custom tool" dohickey I removed would have built it for me. However, that's not the path we're going down anymore. It's now time to brave the unknown. We, yes we, will build the context. Yes the context.

using System.Data.Objects;
using Beta2Test.Data.Entity;

namespace Beta2Test.Data
{
  public class Beta2TestContext : ObjectContext
  {
    private ObjectSet<Ad> _ads;
    private ObjectSet<Newspaper> _newspapers;

    public Beta2TestContext() : base("name=InterviewDemoEntities", "InterviewDemoEntities")
    {
      _ads = CreateObjectSet<Ad>();
      _newspapers = CreateObjectSet<Newspaper>();

      //This makes sure the context lazy loads by default
      ContextOptions.LazyLoadingEnabled = true;
    }

    ///
    /// This is used to set up the "queryable" collection.
    ///
    public ObjectSet<Ad> Ads
    {
      get
      {
        return _ads;
      }
    }

    public ObjectSet<Newspaper> Newspapers
    {
      get
      {
        return _newspapers;
      }
    }

    ///
    /// This creates an ad that allows it "to be used with the Entity Framework."
    ///
    ///
    public Ad CreateAttachedAd()
    {
      return EntityContext.Context.CreateObject<Ad>();
    }

    public Newspaper CreateAttachedNewspaper()
    {
      return EntityContext.Context.CreateObject<Newspaper>();
    }
  }
}

The CreateAttached methods aren't needed on the Context class itself, I just put them there. They could go on the Ad/Newspaper class but at this point I'm not sure if that blurs the lines or not. Haven't gotten into best practices mode yet.

You may notice the ObjectSet collections on the context. These are the collections you will query to get items most likely, much like the old context class from the last version:

Context.Ads.Where(ad => ad.Id == 1)

Pretty nice, huh?

Also, I noted above about the virtual properties on the Ad/Newspaper classes and how it had to do with lazy loading.

ContextOptions.LazyLoadingEnabled = true;

That line and the virtual properties ensure that lazy loading will occur when the property is used. Both have to be used together. Now you don't have to put that line in the constructor if you do create a context every time you are retrieving things, you could just set it on a case by case basis. Up to you. I use a singleton like context so I just set it true in the constructor and don't worry about it.

The main thing I had trouble with was this line:

public Beta2TestContext() : base("name=InterviewDemoEntities", "InterviewDemoEntities")

Because I wasn't sure what the second string should be. First one is easy, it's whatever the key in the config file for the connection string. Second, chances are, is the same depending on how you set it all up in the wizard. I think it's the same name when you right click on the opened .edmx file and view properties. There should be a property named "Entity Container Name".

Here's a method I used for testing to create an Ad:

  public Ad CreateAd(Boolean persist)
  {
    Ad ad = null;

    if (persist)
    {
      ad = EntityContext.Context.CreateAttachedAd();  //This is the CreateAttachedAd method above in use
    }
    else
    {
      ad = new Ad();
    }

    ad.CreatedDate = DateTime.UtcNow;
    ad.Height = RandomTool.RandomInt32(0, 10);
    ad.LastUpdated = DateTime.UtcNow;
    ad.Name = RandomTool.RandomString(10);
    ad.Width = RandomTool.RandomInt32(0, 10);

    if (persist)
    {
      AddEntityForRemoval(ad);  //Ignore, for persistence removal after testing is completed
      EntityContext.Context.Ads.AddObject(ad);  //Ad the ... ad to the context
      EntityContext.Context.SaveChanges();  //Persist
    }

    return ad;
  }

There are some things you can ignore because I didn't feel like removing code. As you can see though, it's not very complicated. Use the CreateAttachedAd, fill in the properties, ad to the Ad collection on the context, and save.

The End

Sure you had to do more work than in the earlier version of Entity Framework, but on the other hand I have a fully detached class that can inherit from any class I WANT it to as opposed to the EntityObject class. Not to mention I now have an easy way to do lazy loading. Far cleaner than the old way I did it. The other interesting thing to note, and this may not be a big deal to anyone else, but above I have a note about this:

  AddEntityForRemoval(ad);  //Ignore, for persistence removal after testing is completed

This method just adds the object to a collection of EntityObjects that later I use to delete the object from the database on test cleanup. After moving to this version of EF, I had to change it to a collection of Objects. Interesting thing is:

  EntityContext.Context.DeleteObject(currentObject);

Didn't care. It still knew that the object was attached to the context somehow, despite the CLASS not being an EntityObject. Just an odd note.

Two Errors I came across:

System.InvalidOperationException: Mapping and metadata information could not be found for EntityType 'Beta2Test.Data.Ad'.

If you get this, there is a really good chance you screwed up a property name or are missing it completely. If the property name doesn't exactly match one in the .edmx class designer template, you're screwed. If you don't have it on the class but it's on the class designer template, you're screwed. If you add it to the class designer template, it has to be on the class as far as I can tell. Now, it doesn't have to be public. I have tested it as private and it works just fine.

The required property 'Newspapers' does not exist on the type 'Beta2Test.Data.Ad'.

This most likely happens if you didn't remember to make it a property:

public IList<Newpaper> Newpapers;  //Forgot the { get; set; }

public IList<Newpaper> Newpapers { get; set; };  //Forgot the Virtual

Opps.

• .Net 4.0 Beta 2 Entity Framework – How To Set Up Complex Types, Now With More POCO
• .Net 4.0 Beta 2 Entity Framework – Many To One and POCO / INSERT statement conflicted with the FOREIGN KEY constraint issue
• Entity Framework: Am I Just Being Stubborn?
• Entity Framework: LINQ to Entities only supports casting Entity Data Model primitive types

I saw a lot of people bagging on it saying that it was missing this feature or that feature. Most people were annoyed that there wasn't built in lazy loading. Some were annoyed with the fact that the classes are coupled to persistence. Others just complained because it wasn't [insert your ORM here]. I on the other hand championed the cause with this in mind:

It's just a framework. The tools are there do what you need, you just need to build it.

Take as is, the word framework is just that. It's just a start. It's that point where a house is just a bunch of wood nailed togther. You can't really live in it as is... well I suppose you could?... but it has what you need to produce a complete house. Just takes a little time and effort. You can already see where this is going. After all, I've already figured out I like pain.

So the first issue I ran into was the context itself. You see, I was already used to multiple calls to the database being done with one "connection" and by that I mean not this every time I wanted to get something:

  using(var entity as ToolEntities)
  {
    entity.Tools.Select(...)
  }

Mind you my syntax is more psuedo in that example, but the idea was simple; It was going to be annoying to have to do that every time I wanted something from the database. So after hours of thought and some research, I came up with a solution that would open one "connection" per request that all queries within that request would use. Ok so that was out of the way, and I can't compain since after all:

It's just a framework. The tools are there do what you need, you just need to build it.

The next thing I ran into was lazy loading a many to one or one to one property. I had already seen stuff on many to many or one to many loading. Simple method .Load(). To my surprise there wasn't such a method for this (Not directly at least) so I was stumped. Time to go back to LLBLGEN? Hell no, mush on. And mush on I did. I found the .Include method:

  context.Tools.Include("Favorites")

Boo yah, and I'm back in the game... or was for a little bit until I realized that this is pretty bad since Include loads the whole object you are including. This could be ridiculous if you have an object with 10... 100... ONE MILLION many to one or one to one properties. So once again, hours of thought and research later I came up with a solution that was eh good enough but wasn't exactly what I'd hoped for.

It's just a framework. The tools are there do what you need, you just need to build it.

Another issue I ran into was a creating an IN clause method. Contains just doesn't work with Entity Framework. Straight up, flat out, no can do sir. So again, with time and research I found a way to do this (Which I haven't posted yet due to the fact I didn't come up with the solution and I can't find the link I got it from). Of course there was the order by situation, oh and this gem, and this that I can only describe as a god damned mess. Really? It's in the context yet you still have to run a query on it? Really??

I'm not going to quit on Entity Framework just yet but after a little introspection I have to admit that I'm close to responding to my own righteous:

It's just a framework. The tools are there do what you need, you just need to build it.

With a big :

Go f- yourself.

This whole situation reminds me of a saying:

If you're in a poker game and you can't figure out who the patsy is, you're the patsy.

It doesn't take much imagination to apply that saying to my situation and to be honest I might be falling into the same situation with the MVC framework. Time will only tell with that. Although at least with MVC I have plenty of patsies with me. I think with Entity Framework, I might be the only one losing money.

• .Net 4.0 Beta 2 Entity Framework – How To Set Up Complex Types, Now With More POCO
• .Net 4.0 Beta 2 Entity Framework – Many To One and POCO / INSERT statement conflicted with the FOREIGN KEY constraint issue
• .Net 4.0 Beta 2 Entity Framework – How To Start
• Entity Framework: LINQ to Entities only supports casting Entity Data Model primitive types

    Expression<Func<K, IComparable>> orderBy

The problem comes in when the entire expression is run, meaning when Entity Frame work takes:

    context.Select(selectMethod).Where(whereClause).OrderBy(orderBy).ToList();

and creates SQL out of it. Entity Framework doesn't really know how to handle IComparable as it has not primitive/sql type to match to it. Why it can't see the underlying type of say DateTime, no idea, but this is life.

So this should be an easy fix, right? Eh... yeah. First I thought instead of IComparable I could just convert to some kind of primitive type so that the EF could be on it's merry. Not so much. Turns out this probably isn't possible.

Well thanks to a push from Ben M at The O Flow I got to thinking about how to attack this. Instead of sending in an expression for the order by, why not send in a method that would take in a query and tell it how to order itself. Sounds hard right? (If not then you're obviously too cool for this school) Well it's not, just a different way to think about it.

Right off the bat, the change to the method signature would look like this:

Old order by parameter signature:

    Expression<Func<K, IComparable>> orderBy

New order by parameter signature:

    Func<IQueryable<T>, IOrderedQueryable<T>> orderBy

So what does that mean? It means that I am going to supply the method with a method that will take in a query and return an ordered query... well not ordered yet per se but the blueprint on how to order when that time comes around. Now here's how that's used:

First you need the query:

    var initialQuery = query
    .Where
    (
        somethingEqualsSomething
    );

Then you apply the orderby method, and in the case of the original paging method, the paging too:

    var orderedQuery = orderBy(initialQuery);

    returnValue = orderedQuery
      .Skip(numberToShow * realPage)
      .Take(numberToShow)
      .ToList();

So overall, doesn't look too much different. Just instead of supplying the OrderBy method with a Func, you give a method that creates an ordered query.

How would you use this? Remember the signature was (whereClause, selectClause, orderBy, pageNumber, numberToShow, realPage, totalCountOfPages)

    Tools.GetListForGrid
    (
      tool => tool.EntityId == userId,
      tool => new { Name = tool.Name },  //Select Clause, I'll get to that next
      toolOuter => toolOuter.OrderBy(toolInner => toolInner .Name),  //OrderBy
      ...
    )

Two things you might notice. One would be the OrderBy signature:

   toolOuter => toolOuter.OrderBy(toolInner => toolInner .Name),

What the hell? Remember the method you are sending takes in a query and returns an ordered query. toolOuter is your query, toolOuter.OrderBy(toolInner => toolInner .Name) is your blueprint (IOrderedQueryable) on how it should be queried.

Second thing is that when I showed how to use the OrderBy method above:

    var orderedQuery = orderBy(initialQuery);

    returnValue = orderedQuery
      .Skip(numberToShow * realPage)
      .Take(numberToShow)
      .ToList();

I didn't include the select clause. Partially because I didn't want to complicate it yet, partially because it has it's own issue. If you're like me, you use the select clause a lot. Why? Because it limits the amount of information you take from the database. Say if you are trying to fill a drop down list, why select an entire Tool object (Which could have a ton of mapped properties) when all you need is Id and Name? Seems silly. That's where the Select clause comes in. Now the issue is where to put the order by. You would think after the select clause, since you want to sort on only what you are selecting. Problem is, with paging that gets screwed up. The way sql server "pages" is that it selects twice.

Select all the things that match this where clause.
Select a certain number of items from that starting at X.

The first select creates a dataset with row numbers, and the second one selects the items based on those row numbers. IE take 5 starting at row 5. Now the way the EF handles the order by is to grab the info you need from the Select (Ordered by something... you don't get to choose) and THEN order and grab. As you can guess this may not give the needed results. So how can this be solved? Order before the select as witnessed in the new and improved method:

public static IList<K> GetListForGrid<T, K>
(
    this ObjectQuery<T> query,
    Expression<Func<T, Boolean>> somethingEqualsSomething,
    Expression<Func<T, K>> selectClause,
    Func<IQueryable<T>, IOrderedQueryable<T>> orderBy,
    Int32 pageNumber,
    Int32 numberToShow,
    out Int32 realPage,
    out Int32 totalCountOfPages
)
{
    IList<K> returnValue;

    Int32 totalItemCount =
        query
        .Count
        (
          somethingEqualsSomething
        );

    totalCountOfPages = Methods.TotalCountOfPages(totalItemCount, numberToShow);
    realPage = Methods.GetRealPage(totalCountOfPages, pageNumber);

    var initialQuery =
      query
      .Where
      (
        somethingEqualsSomething
      );

   var orderedQuery = orderBy(initialQuery);

    returnValue = orderedQuery
      .Select
      (
        selectClause
      )
      .Skip(numberToShow * realPage)
      .Take(numberToShow)
      .ToList();

      return returnValue;
}

And usage:

    Tools.GetListForGrid
    (
       tool => tool.Id == userId,
       tool => new { Name = tool.Name },  //Select Clause
       toolOuter => toolOuter.OrderBy(toolInner => toolInner .Name),  //OrderBy
       pageNumber,
       amountToShow,
       out realPage,
       out totalCountOfPages
    );

Now this one actually works with Entity Framework and not just Linq to objects like the last one.

• .Net 4.0 Beta 2 Entity Framework – How To Set Up Complex Types, Now With More POCO
• .Net 4.0 Beta 2 Entity Framework – Many To One and POCO / INSERT statement conflicted with the FOREIGN KEY constraint issue
• .Net 4.0 Beta 2 Entity Framework – How To Start
• ASP.Net MVC: Upload Image to Database and Show Image “Dynamically” Using a View

A while back I decided to show some paging stuff and I forgot that recently, well ok in the last few months, I actually put together a sort of generic extension method to take care of most of the paging situations I was running into. Reason being is I got tired of writing the same method over and over. I figured I'd share it in hopes that somehow, somewhere, it would keep someone's dream alive. That and I figured I needed to make up for not posting for a while... which to some of you might have been a good thing.

Anywho, it's not to difficult actually. Small note though, when reading the code you will see the TotalCountOfPages method and the GetRealPage method. If you can't figure out what those are then I just don't know what to do. (HINT: They are linked somewhere in this very post! Side note: This post is on track to match the normal self linking per post quota on atypical Codding Horror post)

public static IList<K> GetListForGrid<T, K>
(
  this ObjectQuery<T> query,  //Extension method syntax... basically takes in any SomeEntities.SomeTableRepresentation
  Expression<Func<T, Boolean>> somethingEqualsSomething,  //Where clause
  Expression<Func<T, K>> selectClause,
  Expression<Func<K, IComparable>> orderBy,  //Turns out order by just needs anything that is IComparable
  Int32 pageNumber,
  Int32 numberToShow,
  out Int32 realPage,
  out Int32 totalCountOfPages
)
{
   IList<K> returnValue;
   //Get the total count of the items.  Need this to do proper paging.
   Int32 totalItemCount =
      query
      .Count
      (
         somethingEqualsSomething
      );

   totalCountOfPages = TotalCountOfPages(totalItemCount, numberToShow);
   realPage = GetRealPage(totalCountOfPages, pageNumber);

   returnValue = query
   .Where
   (
      somethingEqualsSomething
   )
   .Select
   (
      selectClause
   )
   .OrderBy(orderBy)
   .Skip(numberToShow * realPage)
   .Take(numberToShow)
   .ToList();

   return returnValue;
}

As you can see there are a lot of expressions going on and that's the way this works. It takes care of the annoying stuff that you would have to copy an paste while you supply it the stuff that changes like what you want to select and what the needed items have to match to be selected. Even has something for an order by. What the usage look like?

  ToolEntities.Tools.GetListForGrid
  (
    something => something.SomethingId == passedInSomethingId,  //Where clause
    found => found,  //Select: Simple here.  Usually I use classes to hold info... next post
    found => found.Name,  //Order by
    pageNumber,
    amountToShow,
    out realPage,
    out totalCountOfPages
  );

Really simple, eh?

Why totalCountOfPages and RealPage out? Well the whole idea is that this infomation is valuable to the picker control you will be constructing outside this method call. RealPage is nice for showing what page the pager is on and how to figure out what the previous and next pages will be. TotalCountOfPages is useful for the last page possible. Now the nice thing about the RealPage method is that it won't give you a non existent page. It will only give you the best possible page if the pageNumber parameter is over the possible amount of pages.

Also do notice that this is an extention method meant to be used with the Entity Framework's built in system of handling the Table representations say ToolEntities.Tools.(Method will show up here in intellisense). This makes it cleaner to me than having to pass in the actual current context. As in:

GetListForGrid(ToolEntities.Something, ...) vs ToolEntites.Something.GetListForGrid(...)

In the end, either way is fine.

• Paging and the Entity Framework, Skip, and Take Part 1
• .Net 4.0 Beta 2 Entity Framework – How To Set Up Complex Types, Now With More POCO
• .Net 4.0 Beta 2 Entity Framework – Many To One and POCO / INSERT statement conflicted with the FOREIGN KEY constraint issue
• .Net 4.0 Beta 2 Entity Framework – How To Start

One of the biggest waaaaahbumlance calls is the fact that Entity Framework doesn't have lazy loading. This isn't true. It does, you just have to do a little work, which is to be expected from a FRAMEWORK. Now I have to admit, I wish there were a slightly less odd way of doing this, but eh it's not too bad.

Say you have a class named Topic and it has a reference to a Forum class named ParentForum. Now this is just a property on the actual class created by the E-Work to represent a many to one foriegn key relationship between the Topic table and the Forum table. Now the problem comes in when you try to use something from that property like:

    Int32 someInt = topic.ParentForum.ForumId;

If you didn't use the Include method when you got that topic:

    context.Include("ParentForum").Select(topic => topic);

You are screwed because the ParentForum property will return a null. So this forces you to use Include every time you want to get a Topic and access it's ParentForum property. Sucks.

So next thought is to find out how to lazy load and then plunk it into that generated property. Eh I don't know about you, but that sounds like a bad idea to mess around with a generated file. You have no idea when the E-Work will just trash the file and rebuild.

Next thought was to create a proxy property to check the real one and then load if it's not already loaded. Something like:

    public Forum ParentForumLazyLoaded
    {
        get
        {
           //check and return
        }
    }

Ok so that's not horrible except two things: The name looks dumb and people can still get at the original ParentForum property.

So in comes my solution and it's pretty simple. Rename the property name on the class to something ParentForumInner and make it private.

Then you can create a much nicer outward facing property like:

    public Forum ParentForum
    {
      get
      {
          if (!ParentForumInnerReference.IsLoaded)
          {
              ParentForumInnerReference.Load();
          }

        return ParentForumInner;
    }
    set
    {
        ParentForumInner = value;
    }
}

Now one of the issues with this is that although outside the class only the ParentForum property can be seen, within the class they both can be seen which can lead to issues like:

    context.Topics.Where(topic => topic.ParentForum.ForumId == id);  //boom

Where you should be using:

    context.Topics.Where(topic => topic.ParentForumInner.ForumId == id);  //yay

E-Work doesn't know how to handle that situation when evaluating that expression and the kicker is that it does just fine compile time. You won't know this is bad until runtime.

Other issue is that you have to do a little more work then just some setting on the property which is what most people wish for. I guess that may be true, but again this is a framework. It gives you all the tools you need to makes things work, you just have to do some coding.

The plus side to this is that with minimal coding, you can completely get rid of Include which to me is huge.

• ByATool.com gets a shiny new tool!
• Data Annotations, MVC, and Why You Might Like Them
• Random Add-On – Automapper
• State List in Dictionary Form

One things nice about the Entity Framework is the ability to create or fill a class on the fly with the Linq query methods/language. You.. you have no idea what I'm trying to say. Fine. I'll put it in programming speak:

  someList.Select(item => new { item.Name, item.ID })

  or

  from item in someList
  select new { item.Name, item.ID }

OR

  someList.Select(item => new DataItemClass { Name = item.Name, ID = item.ID })

  or

  from item in someList
  select new DataItemClass { Name = item.Name, ID = item.ID }

As you can see, they are two slightly different examples. One will create a list of anonymous types and the other a list of DataItemClass objects. Now that's not really the point of this, the point is something like this:

  context.Topics
    .Select(topic =>
                new TopicItem
                {
                  TopicName = topic.Name ,
                  Creator = topic.User.UserName,
                  Category = topic.Category.Description
                }
              )

Now, here's the thing that I assumed. When you select out a bunch of topics and you want to make sure that the one to on properties are "include"ed like thus:

  topicList
   .Include("User")
   .Include("Category")
   .Select(item => item);

Other wise when you try to access that User property you'll get a null reference exception. So with this I thought that when you query like I did above to fill the TopicItem object, I would get the same problem as I would if I tried just accessing the property on a hydrated Topic. In other words:

  Creator = topic.User.UserName,

Would blow up mid query after all calling that property after a query would sans include. Come to find out, and I probably should have already known this, Entity Framework is just fine without having to have the Include method or any kind of join. Infact, adding the include method in the method chain:

  context.Topics
    .Include("User")
    .Include("Category")
    .Select(topic =>
                new TopicItem
                {
                  TopicName = topic.Name ,
                  Creator = topic.User.UserName,
                  Category = topic.Category.Description
                }
              )

Did nothing when I profiled the query. The SQL was exactly the same with or without the include. So it's smart enough to know that if I am not actually hydrating an entire Topic object, it doesn't need to bother with the includes. Go figure.

• .Net 4.0 Beta 2 Entity Framework – How To Set Up Complex Types, Now With More POCO
• .Net 4.0 Beta 2 Entity Framework – Many To One and POCO / INSERT statement conflicted with the FOREIGN KEY constraint issue
• .Net 4.0 Beta 2 Entity Framework – How To Start
• Entity Framework: Am I Just Being Stubborn?

  Drug totallyNotUsingVitamins = toolContext.Drugs.Select(drug => drug.Name == "HCG");
  manny.DrugOfChoice = totallyNotUsingVitaminS;

Looks pointless when I can do this:

  playersObject.DrugTypeReference.EntityKey =
     new EntityKey("ToolEntities.BallPlayers", "drugOfChoiceID", 1);

Which was taken from here.

So here's the problem: Why should I have to hit the database if I know what the ID is? I mean, that's a trip I don't have to make right?

If you're asking that question, then it's possible you don't understand how a lot of ORMs work, or in this site's case: The Entity Framework.

What it really comes down to a couple arguments:

• What is the cost if it hits the database?
• Is it actually hitting the database?
• It's just easier to set the ID

What is the cost if it hits the database?

Now the first one you could almost make an argument, after all what's the point of hitting it if you don't need to? This might seem silly:

  using(ToolEntities toolContext = new ToolEntities())
  {
    Drug totallyNotUsingVitamins = toolContext.Drugs.Select(drug => drug.Name == "HCG");
    manny.DrugOfChoice = totallyNotUsingVitaminS;
  }

If that is the only time you're using this. A one off like that does seem to beg overdoing it. But really is it? This is probably the strongest argument for the straight ID set and really what is the real cost? In order to persist the object, a connection has to be created and the entity has to be persisted. So in reality, you have to create a connection any how, so the actually getting and hydrating of the reference object is just sort of tagged onto that and unless there is something wrong with the table or connection, this adds a minimal amount of time.

Is it actually hitting the database?

But what if this has to be run a million times? Then what? I have to get that item a million times and now my hits have gone from one million to two million?

  using(ToolEntities toolContext = new ToolEntities())
  {
    for(Int32 loopCounter = 0; loopCounter < someNumber; loopCounter ++)
    {
      Drug totallyNotUsingVitamins = toolContext.Drugs
                                       .Select(drug => drug.Name == "HCG")
                                       .First();
      manny.DrugOfChoice = totallyNotUsingVitaminS;
    }
  }

Ok not the best example, but the point is that within that using you will be updating a million records which you would assume that

  Drug totallyNotUsingVitamins = toolContext.Drugs.Select(drug => drug.Name == "HCG");

Would be run a possible two million times. You could make the argument that Entity Framework does make a select against the database even if the object is in the context. This is something I've thought rather odd myself. However, it's just a query on an already open connection. And since creating the query is done the first time around, the acutal query being run is minimal in effort. Basically the hard work was does the first time around. The next time is nothing to really consider.

It's just easier to set the ID

Ok so this one is hard to discredit since it is easier. It's about one line less easier. Is one line really worth this? Is it worth the ease of understanding? From the first example, it's pretty easy to understand what I'm setting. Select a drug type of "HCG". Second one, not so much. All I see is an ID, so if I want to know what drug that is, I'd have to go searching for what that ID is. Also, from a spec level, it's more clear to say:

Set DrugOfChoice to "HCG"

Then

Set DrugOfChoice to 1

Now I may be reaching on this last example, but as I said, it will be hard to prove that the second example isn't "easier" coding wise. After all it's one less line. However, when things like readablity comes in, I can't see the second being a winner in that contest.

Once a person understands how an ORM like the Entity Framework works, it becomes apparent that some of the old ways of thinking need to be abandoned as in the long run they only hold overall development back. And beyond that, sometimes when we think we're optimizing, we could actually doing more harm than needed. Losing readability for the sake of ridiculously small amounts of time just doesn't make sense anymore.

• .Net 4.0 Beta 2 Entity Framework – How To Set Up Complex Types, Now With More POCO
• .Net 4.0 Beta 2 Entity Framework – Many To One and POCO / INSERT statement conflicted with the FOREIGN KEY constraint issue
• .Net 4.0 Beta 2 Entity Framework – How To Start
• Entity Framework: Am I Just Being Stubborn?

Ok so the last two posts have been arguably useless, maybe more so than anything else here, but they were somewhat needed because now I am going to show how to Linq, the Entity Framework, and well that's it I think.

public static IList<ToolItem> GetSomeTools(String name, Int32 numberToShow, Int32 pageNumber, out Int32 realPage, out Int32 totalCountOfPages)
{
  //EntityContext.Context is just a singletonish version of the
  //Entities class.  Most people would use
  //  using (ToolEntities context = new ToolEnties())
  Int32 totalCount = EntityContext.Context.ToolItems
		   .Count(item => item.Name == name);
  //This is the method from the first post of this series
  //Just getting the count of pages based on numberToShow and
  //item totalCount
  totalCountOfPages = TotalCountOfPages(totalCount, numberToShow);
  //This is the method from the second post of this series
  //Basically getting the best possible page if the page number
  //is higher than the totalCountOfPages or lower than 0
  realPage = GetRealPage(totalCountOfPages, pageNumber);

  returnValue = EntityContext.Context.ChatRooms
			  .Where(item => item.Name == name )
			  .OrderBy(item => item.Name)
			  .Skip(numberToShow * realPage)
			  .Take(numberToShow)
			  .ToList();

  return returnValue.ToList();
}

Really simple yes? It follows like this:

Say I'm on page 1, which for this would be zero or pageNumber - 1. So I want to grab the first 20 items from the database. Well that means I want to start at 0 and grab 20. Now if you want this all to be done with some kind of conditional thing that either handles the first page or the other pages, you actually want to skip the same way no matter what the page number is. This is taken care of by numberToShow * realPage since even at 0 this works. After all 0 * anything is 0 and therefore you will be Skipping 0 items. So in other words, you're at the start. Next you want to Take the amount of items you need, which is 20. Next time around you'll start at 20 Skip(numberToShow 20 * realPage 1) and take the next 20. Nice thing is, even if you say Take 20 and there are only 2 left, it doesn't care. It will just grab those two.

And there you have it, how to page with the Entity Framework and minimal amount of work. I know I hate taking other people's methods (Like the TotalCountOfPages and GetRealPage methods), don't know why. So sorry if I am forcing you to do so. However, the two methods I gave are semi important to this.

You might wonder why realPage and totalCountOfPages, well this is useful stuff when knowing what page is next for paging controls. Next post I'll show those off but I'll warn you, they are nothing spectacular.

• Use Linq to Split a List: Skip and Take
• .Net 4.0 Beta 2 Entity Framework – How To Set Up Complex Types, Now With More POCO
• .Net 4.0 Beta 2 Entity Framework – Many To One and POCO / INSERT statement conflicted with the FOREIGN KEY constraint issue
• .Net 4.0 Beta 2 Entity Framework – How To Start

So something I've been doing a lot of lately is making quite possibly the best thing ever: String cheese wrapped in turkey bacon. But when I'm not doing that, I am working with a lot of ListViews and the entity framework. Now I know there are "built in" paging controls but I just haven't liked what I've seen. So I took it upon myself one day to develop a repeatable system for paging. Say you have users and a bunch of invites that are attached to the users. You want to show a list of invites for a particular user, but you want a ListView that doesn't show every invite... ie you need a pager. Well just so happens I have a solution, but as always you should consult a doctor before use.

First off you need a method to get the total count of pages meaning what the ceiling is when you page upwards. After all, if you go over the possible count of pages, you'll just get no items returned and look kind of dumb.

There are three situations you have to look out for: You have less items that the required items per page (Say 10 rows but you display 20 row per page), you have a perfect division (20 rows and 20 row per page or 40 rows and 20 rows per page, ect), you have an uneven division (21 rows and 20 rows per page). First two are easy, third isn't hard exactly but there are some catches.

public static Int32 TotalCountOfPages(Int32 rowCount, Int32 neededPageSize)
{
  Int32 returnValue;
  if(rowCount > 0)
  {
    if (rowCount <= neededPageSize)
    {
      returnValue = 1;
    }
    else
    {
      if ((rowCount % neededPageSize) == 0)
      {
        returnValue = rowCount / neededPageSize;
      }
      else
      {
        Decimal convertedPageSize =
         Convert.ToDecimal(neededPageSize);
        Decimal convertedRowCount =
         Convert.ToDecimal(rowCount);
        Decimal resultRounded =
          Math.Round(convertedRowCount / convertedPageSize);
        Decimal resultNonRounded =
          convertedRowCount / convertedPageSize;

        if (resultRounded < resultNonRounded)
        {
           returnValue =
            Convert.ToInt32(resultRounded + 1);
        }
        else
        {
           returnValue =
            Convert.ToInt32(resultRounded);
        }
      }
    }
  }
  else
  {
    returnValue = 0;
  }
  return returnValue;
}

Ok so first off, I assume this one is pretty obvious:

  if(rowCount > 0)

If there aren't any rows, the there can't be a page count.

Next take care the less rows than being shown per page:

  if (rowCount <= neededPageSize)
  {
    returnValue = 1;
  }

Simple enough. Now for the second part, a perfect division between rows and rows to show:

 if ((rowCount % neededPageSize) == 0)
 {
    returnValue = rowCount / neededPageSize;
 }

Basically, for those who don't know mod or the % operator, that means there is no remainder. If there were, the result of rowCount % neededPageSize would not be 0 since Mod basically means "Give me what's left over when I divide something by something else."

Ok, this is where it gets a little messy as I have yet to find a good way to round a number up since, far as I know, there's no way to do it with the .Net lib'ary. So, I had to come up with something clever... and when that failed I came up with this:

 Decimal convertedPageSize =
    Convert.ToDecimal(neededPageSize);
 Decimal convertedRowCount =
    Convert.ToDecimal(rowCount);
  Decimal resultRounded =
    Math.Round(convertedRowCount / convertedPageSize);
  Decimal resultNonRounded =
    convertedRowCount / convertedPageSize;

  if (resultRounded < resultNonRounded)
  {
      returnValue =
          Convert.ToInt32(resultRounded + 1);
  }
  else
  {
     returnValue =
       Convert.ToInt32(resultRounded);
  }

Ok so what's going on here? First off, because trying to divide an integer by an integer gives me an integer, I had to covert some stuff to decimal. Why is that? When I divide them, I need to know if the number after the decimal is between 1 and 1.5 since Math.Round will round down in that case killing my ability to tell if I have enough pages.

Example: 19 rows and 10 per page will give me a 1.9 which Round will make 2. This is perfect since I need two pages to show the 19 rows. What if I have 14 rows and 10 per page? I get 1 from rounding. Uh oh. I really need two pages.

How do I get around this? Get the rounded version and the unrounded version. From there I know that if the unrounded version is greater than the rounded version I need an extra page.

So 14 rows / 10 per page = 1.4 unrounded and 1 rounded. 1.4 > 1, so that 1 page isn't going to do it. I need to add one more page. Now if it 19 rows/10 per page I'll get 1.9 unrounded and 2 rounded. 2 pages is exactly what I need and I don't have to add anything.

Next post I'll show the next needed method: How to tell if the page number being sent in (From the pager/UI) is actually valid. If not, then grab the last possible amount of records.

• Entity Framework: Reusable Paging Method
• .Net 4.0 Beta 2 Entity Framework – How To Set Up Complex Types, Now With More POCO
• .Net 4.0 Beta 2 Entity Framework – Many To One and POCO / INSERT statement conflicted with the FOREIGN KEY constraint issue
• .Net 4.0 Beta 2 Entity Framework – How To Start

As I said, I was trying to delete a user through the entity framework but noticed that all the addresses the user had were still in the database after deletion. Whoops. I dun forgot to set Cascade Delete on the tables. No big deal. So after I fixed the tables, I went to update the edmx file... ie update from database... and I thought all was well. Yeah not so much. I started to get this error. So the next thing I did was open the .edmx file in notepad and looked for "delete". Sure enough I found it.

        <Association Name="FK_UserAddress_User">
          <End Role="ChatUser" Type="BAT.Data.Store.User" Multiplicity="1"">
            <OnDelete Action="Cascade" /">
          </End">

Eh ok... it's there. Well after some searching I ran into this post. Basically what was happening is although that shows the OnDelete Action="Cascade", it's still not everywhere it needs to be. Then it dawned on me that the way the .edmx file works is that pretty much everything has to be doubled in the file, once for the database and once for the actual class. What was missing was the class half. For some reason when adding Cascade to a foreign key and then updating the .edmx file, only the table part of the markup gets updated. Bummer. So, what to do? Kind the foreign key name in the file (FK_UserAddress_User for example) and do a search on it. You'll find something like this:

     <Association Name="FK_UserAddress_User">
           <End Type="BAT.Data.ChatUser" Role="User" Multiplicity="1" />

Oooo right there is the problem. You see, if this were correctly done, it would have the action="delete" added to it, just like the one in the SSDL area. So how do you fix this? Manually. Hooray.

     <Association Name="FK_UserAddress_User">
           <End Type="BAT.Data.ChatUser" Role="User" Multiplicity="1" >  //RIGHT HERE
             <OnDelete Action="Cascade"></OnDelete>  //RIGHT HERE
           </End>  //RIGHT HERE
     <End Type="BAT.Data.UserAddress" Role="UserAddress" Multiplicity="*" /></Association>

As you can see, it's a simple change and you only have to do it to the object of Multiplicity="1", which of makes sense you wouldn't want a user deleted if an address is. But it's still annoying and a real pain if you have more than say one to fix.

• .Net 4.0 Beta 2 Entity Framework – How To Set Up Complex Types, Now With More POCO
• .Net 4.0 Beta 2 Entity Framework – Many To One and POCO / INSERT statement conflicted with the FOREIGN KEY constraint issue
• .Net 4.0 Beta 2 Entity Framework – How To Start
• Entity Framework: Am I Just Being Stubborn?

The old idea was to have a single context that was held in a static (Therefore the context was static). Couple problems:

• All queries and updates will be sharing this context... for every user. Hrm. I can't see anything wrong with Sally Starshine hitting the old update button and saving Dick McGurk's changes. Nothing wrong with that all.
• Any changes to an object in the context will stay in the context until the various ways of "resetting" a static object are used, regardless of being persisted to the database. Basically, if you changed the user.UserName = "YouIdiot", "YouIdiot" will now show up anywhere you use that context... which is everywhere.

So as you can see, disaster. Now, where could I have gone from here? Well insane first, then I found a solution... Page Requests. You see, when a request is made there are two events fired of importance:

    protected void Application_BeginRequest(object sender, EventArgs e)
    {
    }

    protected void Application_EndRequest(object sender, EventArgs e)
    {
    }

Pretty snazy, right? Well these are fired with every request, so basically these are fired every postback... and then some. The next step I took was to make context creation and tear down methods. Something like on BeginRequest: If the context doesn't exist, create and on EndRequest: If the context does exist, DESTROY. Well this worked at first... until I realized something. That cute little method BeginRequest fires on every request (Duh) meaning anytime the page requests an image. Hrm. That's a lot of useless building right? Well it occurred to me the tear down on EndRequest was a good idea since it won't do anything if the context doesn't exist. No harm no foul. The problem was the BeginRequest. Fact is, the answer was stairing at me... I already had the build up method, I just had to call it when it mattered: First use. SO can you figure out what I did? I bet you can!

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

    public class EntityContext
    {
        private TISQLEntities _context;
        private static String MAIN_CONTEXT_KEY = "MainContext";

        public static TISQLEntities Context
        {
            get
            {
               if (HttpContext.Current.Items[MAIN_CONTEXT_KEY] == null)
                {
                    CreateContext();
                }

              return (TISQLEntities)HttpContext.Current.Items[MAIN_CONTEXT_KEY];
            }
        }

        private static void CreateContext()
        {
           HttpContext.Current.Items[MAIN_CONTEXT_KEY] = new TISQLEntities();
        }

        public static void RemoveContext()
       {
           if (HttpContext.Current.Items[MAIN_CONTEXT_KEY] != null)
           {
             ((TISQLEntities)HttpContext.Current.Items[MAIN_CONTEXT_KEY]).Dispose();
             HttpContext.Current.Items[MAIN_CONTEXT_KEY] = null;
            }
         }
    }

Idiot simple, as it would have to be coming from me. You might have seen that I'm holding it in the current HTTPContext. This is to hold the needed context for the current request. Yippee.

Now for the use (In the Global.asax.cs file)

    protected void Application_EndRequest(object sender, EventArgs e)
    {
        EntityContext.RemoveContext();
    }

So what happens? First time I use the context:

    EntityContext.context.SiteUser.Load();

The EntityContext class creates the context and goes to town. When the request is done, the EntityContext class removes said context.

Now on a side not, you might notice that when doing unit tests, there is no HTTPContext. This is a problem and involves one more step (That I'm not completely happy with right now) that actually takes the old Static idea and applies it. Now you might thing that I'm undoing everything I just posted, but in reality when you unit test, most likely you'll be doing it on your computer and therefore you won't be running into anyone else's context. (Unlike a web site)

    private static String MAIN_CONTEXT_KEY = "MainContext";
    private static TISQLEntities _context;

    public static void RemoveContext()
    {
        if (HttpContext.Current != null && HttpContext.Current.Items[MAIN_CONTEXT_KEY] != null)
        {
            ((TISQLEntities)HttpContext.Current.Items[MAIN_CONTEXT_KEY]).Dispose();
            HttpContext.Current.Items[MAIN_CONTEXT_KEY] = null;
        }

        if(_context != null)
        {
          _context = null;
        }
    }

    public static TISQLEntities Context
    {
        get
        {
            if (HttpContext.Current == null)
            {
                if(_context == null)
                {
                    _context = new TISQLEntities();
                }
                return _context;
            }

            if(HttpContext.Current.Items[MAIN_CONTEXT_KEY] == null)
            {
                HttpContext.Current.Items[MAIN_CONTEXT_KEY] = new TISQLEntities();
            }

            return (TISQLEntities)HttpContext.Current.Items[MAIN_CONTEXT_KEY];
        }
    }

I don't like this one fully, but for now it's good. There has to be a better way though.

• .Net 4.0 Beta 2 Entity Framework – How To Set Up Complex Types, Now With More POCO
• .Net 4.0 Beta 2 Entity Framework – Many To One and POCO / INSERT statement conflicted with the FOREIGN KEY constraint issue
• .Net 4.0 Beta 2 Entity Framework – How To Start
• Entity Framework: Am I Just Being Stubborn?

So in THIS MIGHTY POST I asked why Entity Framework context likes to query the database despite the object (data row) already being loaded into the context. Well even though it's not a perfect answer, Craig Stuntz had an answer at The O that gave some light to the situation:

context.SiteUser is an property of type ObjectQuery. When you execute an ObjectQuery, it will always hit the backing store. That's what they do. If you don't want to execute a database query, then don't use an ObjectQuery.

Furthermore I could use GetObjectByKey:

GetObjectByKey tries to retrieve an object that has the specified EntityKey from the ObjectStateManager. If the object is currently not loaded into the object context, a query is executed in an attempt to return the object from the data source.

Which actually seems to me like how it should work naturally. After all, if it's in the context and I am positive I don't want to update the object from changes in the database, wouldn't it make sense to not bother with the database at all? Seems like a wasted action. Again, I am guessing that the reason it does this is that it's an all or nothing thing. It either does it all the time (IE query no matter the reason) or never. Grey area just doesn't seem to fit Entity Framework design in this matter.

• .Net 4.0 Beta 2 Entity Framework – How To Set Up Complex Types, Now With More POCO
• .Net 4.0 Beta 2 Entity Framework – Many To One and POCO / INSERT statement conflicted with the FOREIGN KEY constraint issue
• .Net 4.0 Beta 2 Entity Framework – How To Start
• Entity Framework: Am I Just Being Stubborn?

Concurrency Mode allows you to make sure that nothing has changed in the database before or during the current save. Basically it checks the database to make sure the record being updated still is in the same condition it was when you loaded it to the context. If it isn't, then an exception is thrown. (Maybe not the way I would prefer handling this situation, but hey I don't work for the M) How do I get this to happen? Well it's a pretty easy change, though it has an annoying short coming. First the change.

Open up the model browser (IE double click on the .edmx file) and select any property on any entity. Then view the properties.

And in the image you can see that there is a property surprisingly named "Concurrency Mode" and there are two options: Fixed and None. Guess which one I'm talking about in this post.

Now if I just left you with that, you'd have everything you need to know and you wouldn't waste the next minute you're going to waste on my findings. Good thing you aren't smart enough to walk away.

You might wonder how the Entity Framework is able to do that, after all even I did and as we all know, I am genius.
Say you have a User entity where the UserName and MainEmail properties had Fixed Concurrency. Now suppose the old values of these were 'oldValue' and you just changed them (UI Side) to 'HIHIHI'. At this point you want to save the changes. Well if you use profiler and a watch as it saves, you'll see something like this:

exec sp_executesql
N'update [TIDBA].[TI_USER]
set
  [MainEmail] = @0,
  [UserName] = @1
where
  ((([UserID] = @2)
and
  ([MainEmail] = @3))
and
  ([UserName] = @4))
',N'@0 nchar(6),
@1 varchar(6),
@2 int,
@3 nchar(6),
@4 varchar(6)',
@0=N'HIHIHI',
@1='HIHIHI',
@2=1,
@3=N'oldValue',
@4='oldValue'

Which cleans up into:

update [TIDBA].[TI_USER]
set
  [MainEmail] = 'HIHIHI',
  [UserName] = 'HIHIHI'
where
  ((([UserID] = 1)
and
  ([MainEmail] = 'oldValue'))
and
  ([UserName] = 'oldValue'))

As you can see, the Entity Framework matches the originally loaded values against the database (Only on Fixed Concurrency properties) and sees if it can find a record. If it can't, it means those values have changed. The exception follows.

Now besides the exception part (A bit much but can be handled), the only annoying thing is that you have to do this property by property. I don't see a way yet to make it standard for the entire entity. Such is life.

• .Net 4.0 Beta 2 Entity Framework – How To Set Up Complex Types, Now With More POCO
• .Net 4.0 Beta 2 Entity Framework – Many To One and POCO / INSERT statement conflicted with the FOREIGN KEY constraint issue
• .Net 4.0 Beta 2 Entity Framework – How To Start
• Entity Framework: Am I Just Being Stubborn?

So in THIS POST I talked about how querying worked on a conceptual level but turns out there is something going on that's not expected. Remember how I said that if the object is in the context, the database won't be hit? Turns out that isn't true to an extent. With the help of profiler, I found outconfusing thing or two, and neither have to do with why this is was on the front page of CNN.

Say you for some reason want to select a user like so:

    SiteUser someUser = context.SiteUser.First(role => role.UserID == 1);

WOW THAT IS NEW AND AMAZING!!!117!

Right off the bat, I bet you can guess what happens. If not (You know, if you didn't read THIS POST or you have difficulties with revolving doors), here's the idea in script form:

            CONTEXT
    Am I having this Object?

Context looks into its bag, notices it doesn't have the object,
and then looks over at Database with confused look.

            DATABASE
   No but I gots it for you.

Database hands object to Context.  Context looks happy.

            CONTEXT
  I has a object now.

At this point, two things are obvious: I've lost it and Context now has a User with an UserID of one and it got this by querying the database. Now suppose for no real reason you want the same user. (Assume it is the same context and the user is already in the context.)

            CONTEXT
    Am I having this Object?

Context looks into his bag and pulls out the object.  Database walks over.

           CONTEXT
    You has object?

            DATABASE
   Yes but I gots it for you.

Database hands object to Context.  Context doesn't take it.

            CONTEXT
  I has it already.

So in this stunning display, we can see that even though the context already has the user, it still asks the database for the thing. How do I know this? Well I used profiler on both statements. What I thought would happen is on the first eh First it would hit the database, hydrate the object, and go on its merry. Second First would just grab it from the context and give it to me. Fact is, it STILL HITS THE DATABASE. Now the next possible idea is that it's going to the database to see if the record has changed and then will update the object with any changes EXCEPT what has been changed on the object. Yeah not so much. (Although there is a way you can force that, but I'll post that in the next post) Fact is, it really doesn't do anything with it as long as you have the default settings. In fact, (FACT FACT FACT FACT) the default settings say that:

Objects that already exist in the object context are not loaded from the data source.
This is the default behavior for queries or when calling the Load method on an
EntityCollection<(Of <(TEntity>)>).

Seems kind of odd that by default something in the context will not be loaded if it's already there but it still hits the database regardless. So what this default really means is that it may or may not hit the database, but any changes in the database will not be reflected in the object. It really doesn't mean that the database won't be queried. Seems kind of odd.

What not good enough? Fine, figure this out.

• .Net 4.0 Beta 2 Entity Framework – How To Set Up Complex Types, Now With More POCO
• .Net 4.0 Beta 2 Entity Framework – Many To One and POCO / INSERT statement conflicted with the FOREIGN KEY constraint issue
• .Net 4.0 Beta 2 Entity Framework – How To Start
• Entity Framework: Am I Just Being Stubborn?

    using(SomeEntities context = new SomeEntities ())
    {
       //where SomeEntities  : ObjectContext
       Site neededSite = context.Site.Where(site => site.ID = siteID);
    }

Ok so what happens here? Well basically the context will check itself to see if it holding said Site and if it isn't, it will grab it from the database. This doesn't seem like a big deal since it's pretty obvious it won't have the given Site yet since the context was just created. Now let's get a silly example going for the sake of learning.

    using(SomeEntities context = new SomeEntities ())
    {
       //where SomeEntities  : ObjectContext
       Site neededSite = context.Site.Where(site => site.ID = siteID);
       neededSite.SiteName = someString;

       if(context.Site.Any(site => siteName == neededSite.SiteName))
       {
          //return error since the name already exists in the table.
       }

    }

Now as it is, this doesn't seem too bad right? I change the name of the site and then see if that name is taken already in the database. If these seems ok to you it just means you don't yet understand how the Entity Framework eh... works. The first time you go to get the Site, it fills it's Site list with the Sites from the database, then checks the list for the one you want. It will then proceed to give you a reference to the Site in that list. Next time you do a query on the Sites list, it will NOT query the database but rather it will just query the Sites list it has in memory. Next, the line:

    neededSite.SiteName = someString;

Is updating the object in that list. Now you would think (If you are used to say not caching results from database queries) that the next query:

    context.Site.Any(site => siteName == neededSite.SiteName)

Would hit the database again and check the items there and make sure that SiteName doesn't exist. But far as Entity Framework is concerned it already loaded that list, so it doesn't need to hit the database again. This is good to save the performance hit of getting from the database but dangerous if you don't understand this. Fact is, the context is just going to look at it's cached list of Sites and run that query and guess what's in that list? The object that you just changed. So basically that query will compare the object to itself at some point as it iterates through the list and yee haw it will find a Site that already has that SiteName... the one you just changed. Solution?

You can include the SiteID in the query:

    context.Sites
            .Any(
                  site => siteName == neededSite.SiteName
                  && site.SiteID != neededSite.SiteID
                 )

This way you know that you won't compare the same object to itself.

OR You can create a new context if you really want to get a fresh look at the database. This will allow you to have a context with the new changes and a context pre changes so you can be sure you are comparing the object to a list without it.

Now you might look down the list of methods on the context and see the Refresh method. This might be temping because you might think that a refresh would give you what you want, a completely new list to compare against. There are two ways you can handle this:

     context.Refresh(RefreshMode.Store, context.Site);

Seems like this would be good since it basically means I want to completely restore the list from the database and clear out any changes I made in the list. Oh wait, what was that? " clear out any changes I made in the list". This means those changes we made to the object, yeah gone. So now the:

    context.Sites
           .Any(
                  site => siteName == neededSite.SiteName
                  && site.SiteID != neededSite.SiteID
                )

Query is hosed because the neededSite.SiteName has been reverted to whatever was in the database originally.

You could try this:

     context.Refresh(RefreshMode.ClientWins, context.Site);

In which any changes made to the objects will overwrite any information being brought in from the database. Hmm, 6 of one and a half dozen of the other. This just brings us back to the same problem. The list will still contain the changes to the object and therefore we will once again compare the object to itself.

Now you might think that maybe you should just check the list BEFORE applying the changes to the object, and that would be a good way of going about it:

    using(SomeEntities context = new SomeEntities ())
    {
       //where SomeEntities  : ObjectContext
       Site neededSite = context.Site.Where(site => site.ID = siteID);

       if(context.Site.Any(site => siteName == someString))
       {
          //return error since the name already exists in the table.
       }
       else
       {
          neededSite.SiteName = someString;
          //Continue or save
       }
    }

This would work since you are checking the list before the object has been changed. This might work if you do your saving in the same layer that you have your UI, but if you do something like this:

    ...
    Site someSite = Site.GetSiteById(id);
    someSite.SiteName = txtSiteName.Text;
    someSite.Save();
    ...

In this example, I have created a Save method on the Site object that will take care of validation and saving all in one. It also means that I either am sharing a context between the GetSiteId method and the Save method, or that I am using two contexts. If it's the latter, then it won't matter since the context in the Save method will not "own" the current someSite object. (And therefore will not have the changes to the someSite object reflected in its list) However, if they do share the same context then you will run into the above problem.

In the next post, I'll talk about how to share a context... which I won't try to sell you as the right thing to do. Just something to think about.

• .Net 4.0 Beta 2 Entity Framework – How To Set Up Complex Types, Now With More POCO
• .Net 4.0 Beta 2 Entity Framework – Many To One and POCO / INSERT statement conflicted with the FOREIGN KEY constraint issue
• .Net 4.0 Beta 2 Entity Framework – How To Start
• Entity Framework: Am I Just Being Stubborn?

First off is lazy loading. Now I could put the obligatory stupid joke here that gives some kind of novel, but incorrect, explanation of the phrase (Like say making someone else wash your clothes) but I so much better than that. So what is lazy loading? Simply put it's not getting something until you need it. Kind of like "If it ain't broke then don't fix it" instead you trade "broke" with "needed" and "fix" with "get". So it's really not like that phrase. It is however, when talking about objects being hydrated (ie loaded) from some kind of storage (ie database) in a program written by some idiot. (ie me) Let's say you have a User table and a Site table in which there are many Users to one Site. Now with an ORM this will be represented by an User object, a Site object, and a property on User that is of type Site. It would look something like this:

    public class User
    {
      private Site _site = null;

      public Site ParentSite
      {
         get
         {
            if(_site == null)
            {
               _site = SomeMethodToGetSite();
            }

            return _site;
         }
      }
    }

When you load the User from storage, initially the Site object on the User object is null. This is done because if you don't need the Site yet, why take up space until you do? This is the concept of lazy loading. Now in most ORMs, the Site would automatically be hydrated the first time the Site property was accessed. Entity Framework is slightly more complicated when dealing with the many to many or one to many situation.

This happens when you have a Users list on the Site object that basically represents every User in the User table that has the same SiteID as the Site in question. OR maybe you have a hanging table UserSite that allows for one Site to have many Users and one User to have many Sites. Either way, you will be left with a collection that represents this relationship. (Users list on the Site object) Now say you do this:

  Site someSite = LoadSiteByID(siteID);

and then you try to do this:

  someGrid.DataSource = someSite.Users;
  someGrid.DataBind();

When the page loads, there are no records in the grid. In a normal ORM this wouldn't be a problem. It would see that you are accessing the .Users property and hit the database to fill the list. Entity Framework requires you to take one more step in this case.

  someGrid.DataSource = someSite.Users.Load();

Not that big of a deal. Now there is a check even to see if it is loaded in the first place:

  order.Users.IsLoaded

This is a boolean property that says true when it has been loaded. Next post I'll hit on what happens when you query and how that relates to this situation.

• .Net 4.0 Beta 2 Entity Framework – How To Set Up Complex Types, Now With More POCO
• .Net 4.0 Beta 2 Entity Framework – Many To One and POCO / INSERT statement conflicted with the FOREIGN KEY constraint issue
• .Net 4.0 Beta 2 Entity Framework – How To Start
• Entity Framework: Am I Just Being Stubborn?

The latest bump in my path has been the ObjectContext. Just to let it be known, I'm like most kids with a new game, I don't bother to read the instructions and the throw the controller when I don't have a clue what I'm doing. My use of the Entity Framework has been no different. So using "o' skool" standards, I immediately decided that I would have some kind of Singleton context so that I didn't keep making new ones, and assumedly new connections. Everything seemed fine and dandy until I hit this situation which brought some, at the time, unexplainable or difficult issues.

First off, say you have a Site and Role class, and Role is Many to One with Site. Now let's say you are creating a page that is used to create/update/delete roles. On this page you have the usual section for updating or creating a new role that involves a Name for the Role and a drop down list to pick a Site from. Now on the update side of it you have basic rules: The Role must have a name, the Role must have a Site, and the Name of the Role can't already exist in the database for the site. So a new role might look like:

  Role editRole = Role.GetByID(someID);
  editRole.RoleName = txtRoleName.Text;
  editRole.Site = GetSiteFromID(ddlSite.SelectedValue.ConvertTo<Int32>);

The GetByID is just a query that gets the Role by and ID by using the Singleton ObjectContext. (KEY POINT) Beyond that, nothing special except my awesome string convert. Yah. Now the next step before committing to the database is something like:

  if
  (
    context.Any
    (
      role => role.Name == editRole.RoleName
      && role.Site == editRole.Site
    )
  )
  {
     //return error or whatever
  }

So right there I'm checking to see if the new name for the role exists already. Now say I'm updating a role and that I KNOW the new name doesn't exist. You would think that query would return false and life would be good. Unfortunately two things happened... and they will change your life forever. (EDIT: I realize I could also check to make sure the ID doesn't match and should do that, but if I had done that initially I wouldn't have figured out the next part)

First:

I got back an error saying the name already exists. Now as I said, I know it didn't so how could that happen? Well remember that Singleton ObjectContext idea? First time I grab the Role, it doesn't exist in the ObjectContext.Role list. So it grabs it from the database and then stores it so that every time I now run that GetByID method, I am actually getting the object from the context NOT THE PERSISTENCE LAYER. (IE database or whatever) Therefore, any changes I make are changes to the object in that context. So what does that mean? Well say I do update the RoleName on that object and then run a query to see if that name exists, guess where that query is looking? Yup the context. And since it's looking at the same stupid object I just changed, of course the name is going to exist now. Basically I comparing the object to itself to see if it's name exists. Ouch.

B:

After cancelling, (IE not saving) The grid that I had displaying all the Roles now has that new RoleName in it. What the f? My code specifically says NOT to save unless that (name already exists) query returns false. So how the hell has the name changed? Well just like before, the query that gets the list of Roles is no longer looking at the database but now at the Roles list in the context. That same Roles list that has the Role I changed earlier. Therefore any change to that object will now be reflected when getting the list from the context. Uhg.

So what can you learn about this? Once a list is "loaded" for the first time, it is held in the context until (presumably) you use the Refresh method on the context to refresh the given list. (Not sure how well this works). Therefore, any queries after the first will reflect all changes to the objects in the context, whether you saved to the database or not. The Singleton idea isn't looking real great right now.

• .Net 4.0 Beta 2 Entity Framework – How To Set Up Complex Types, Now With More POCO
• .Net 4.0 Beta 2 Entity Framework – Many To One and POCO / INSERT statement conflicted with the FOREIGN KEY constraint issue
• .Net 4.0 Beta 2 Entity Framework – How To Start
• Entity Framework: Am I Just Being Stubborn?

So here's the problem I ran into the other day. I have a Site table and a Role table, and every Role record has a SiteID (Foreign Key) that the Entity Map represents in a property. (Site Class) Now, when I "hydrate" a Role, the Site property is null. This is because Entity Framework, in a round about way, supports lazy loading sort of. (Lazy Loading meaning that any relationship, be it a Site object on a Role or say a Users list on a Role, will not be loaded at the time you "hydrate" the main object and will only be loaded when the property is accessed.) So it makes sense that the Site object exposed by the property is not loaded yet because I haven't accessed the property.

With the Entity Framework, and one to many relationships (Say a Users list on a Role object) you have to not only access the property, but you have use the Load method to make sure it gets loaded:

    from user in someRole.Users.Load()

Well with a many to one relationship (Many Roles to one Site) this is a propblem since the Site property returns only a single Site:

    someRole.Site.Load(); //Boom, not possible

Load can't be used since Site isn't a collection. So how the hell do I load this stupid thing? Well that has to be done in the query itself. Kind of annoying:

    context.Role.Include("Site").Where(someClause).ToList();

As you can see, in that query I had to add the Include method and the value is actually the property name. Now when I look at the list of roles returned, the roles now have the Site property loaded. As I said, kind of annoying, but there is something interesting about these relationships that I'll post about next.

• .Net 4.0 Beta 2 Entity Framework – How To Set Up Complex Types, Now With More POCO
• .Net 4.0 Beta 2 Entity Framework – Many To One and POCO / INSERT statement conflicted with the FOREIGN KEY constraint issue
• .Net 4.0 Beta 2 Entity Framework – How To Start
• Entity Framework: Am I Just Being Stubborn?