I knew that Intellitrace existed, but not until I saw Nikhil Kotahari’s tweet from PDC09

“Cool VS demo – intellitrace – see your db queries, and track it back to your LINQ code #pdc09”

did I think to look at what IntelliTrace reports with respect to Entity Framework database interaction.

I fired up a sample that executed a query and then demanded some lazy loading to take place.

IntelliTrace picked up the explicit query execution but not the queries executed by lazy loading. They must be too deep in the pipeline.

In the screenshot below, tracing is displayed from the top to the bottom. I can see the step just before the query is executed , the actual command that was sent to the database and then a number of steps after that.

By the time the 8 steps were hit after the first query, my code had performed two hits to the database for lazy loading. So unfortunately, IntelliTrace is not picking them up.

I checked what happens with an explicit load (e.g., myContact.Addresses.Load()) and I can see the query in IntelliTrace. The first query (highlighted) is the explicit query, the second one, expanded, is the result of the call to Load.

I ran another bit of code that did an update via SaveChanges, and IntelliTrace did pick up the database call.

Of course, now that I have EFProf, I can see each and every call to the db, including Lazy loading calls, plus I get extra bells & whistles.

In an earlier post, I wrote about the new awesomeness that ASP.NET 4.0’s Dynamic Data brings to many to many relationships.

I frequently notice that most DD demos demonstrate creating the data model within the same project as the DD website.

Even though a typical Dynamic Data app is for RAD development and isn’t focused on application architecture (come on, the data access is buried in the UI), I still can’t bare to store my model inside of the UI project. All of my EF Entity Data Model’s are housed in their own projects.

This is not a problem at all for a Dynamic Data site. Like any other project that leverages an EDM in a separate project, you only need to perform three steps to point to the external model:

1. Add a reference to the project that contains the data model
2. Add a reference to System.Data.Entity.dll
3. If it’s the executing app (in this case it is), provide the EntityConnection string, most typically by adding it into the web.config file

For Dynamic Data, there is one additional consideration that I was torn over.

I have my model in it’s own project because I like to be able to reuse it in other applications.

In a DD site, I typically do  not expose the *entire* model for the scaffold (e.g., for use in the dynamic application). Instead, I set ScaffoldAllTables to false in the global asax file:

 DefaultModel.RegisterContext(typeof(MyEDM.MyEntities), 
     new ContextConfiguration() { ScaffoldAllTables = false });

and explicitly mark the classes which I want to include with the scaffold attribute:

[ScaffoldTable(true)]

And here is where I run into the conundrum.

The ScaffoldTable attribute is something that I specifically want for the Dynamic Data site. It’s not needed by any other apps that might be using my model. The only way to add it to the generated class in my model project is to use partial classes. As far a I know*, partial classes need to be in the same project as the rest of the partial classes so that the compiler can pull them all together. That means, I’m forced to “dirty” my model project with the attributes that are meaningless to any other application that might also use my model. Fortunately, the ScaffoldTable attribute is in System.ComponentModel.DataAnnotations, not System.Web.DynamicData, so it doesn’t feel so bad. I suppose that because I’ve been focused on repositories and MVC lately, this is why I’m feeling so anal about this and perhaps it’s overkill.

My first instinct, because I was looking for separation, was to put the partial classes with the attributes into the dynamic data project, but of course I was quickly reminded by the error message telling me that I had ScaffoldAllTables set to false but I had not designated any classes to be used, that the extra partial class logic was not getting picked up by my classes because it was in the wrong project. So I bit my tongue and put them where they belonged, into the model’s project.

An approach that I’m considering is having different code generation templates for my model, so that I can generate entity classes to be used in different applications. Even so, I wouldn’t automatically mark all of the entities as a ScaffoldTable anyway. So I’ll have to think a bit more about that if I’m going to really worry about implementing it.

In the meantime, the key takeaway here is that you can have the model in a separate project to be used by Dynamic Data apps and you can specify which entities to use. You just need to include the partial classes with the ScaffoldTable attributes in the EDM’s project, not the Dynamic Data project where you might think you really want them to be.

*just a small caveat on the partial classes rule in case something changed in .NET 4.0 that I’m unaware of.  I don’t know how they would pull it off, but hey, you never know! 🙂

In my EF Tips & Tricks talk that I just did at DevConnections, I have a suggestion to reduce redundant methods where you might expose queries to generate reference lists.

E.g.

static List<CustomerType> CustomerTypeList(MyEntities context)
  {
    return context.CustomerTypes.OrderBy(ct => ct.Type).ToList();
  }

static List<States> StatesList(MyEntities context)
  {
    return context.States.OrderBy(ct => ct.StateName).ToList();
  }

Instead I have a single generic method, GetRefernenceList<TEntity> that uses some tricks with Entity SQL and MetadataWorkspace  to dynamically build the query and return the requested list.

This is still the right way to do it in VS2008. However, Zeeshan Hirani suggested to me that with EF4, there’s a better way – the new CreateObjectSet method.

This let’s me pass in the entity type and create a queryable set.

A simple version would be:

public List<TEntity> ReturnSomeObjects<TEntity>()

{ context.CreateObjectSet<TEntity>(); }

Easy peasie.

Now what if I want to provide a field for sorting. I could use functional programming to pass in and use a strongly typed property to sort on. Alternatively, I could pass in a string and append a Query Builder method to the object set.

context.CreateObjectSet<TEntity>().OrderBy(“it.” + sortproperty)

Sweet. Much easier than dealing with MetadataWorkspace.

Thanks for getting me to think a little harder on this, Zeeshan!

The EF team just released the newest version of the Feature CTP that is now compatible with VS2010 Beta2. Hooray for compatibility, but more importantly, we can now work with a greatly enhanced version of the Code Only feature and Self-Tracking Entities. Code-Only is the API that allows you to use EF without a model at all. Self-Tracking Entities provides tracking for entities across WCF Services and their clients .

I’ll talk a bit about Code Only here, which will be of great interest to Domain Driven  Developers.

Under the covers, EF depends on the metadata for a model. Code Only will create this metadata on the fly based on your classes.

Code Only uses convention over configuration. First with convention, it builds the metadata using whatever it finds in your classes combined with a set of assumptions. However, you can do some major tweaking to those assumptions and force it, through configuration, to define the metadata more to your liking. there are two important benefits to this. the first is that if you are leveraging code-only’s ability to generate DDL and therefore define your database schema, you can have more control over how inheritance is "translated” in to tables, more control over attributes of columns, tables and constraints as well as constraints between tables.

The configuration is not done through attributes, but through code.

Here’s a very simple example.

By convention, Code Only will use any property named “ID” as an identifying property (EntityKey) as well as the presumed primary key in the back end data store. However, if you don’t happen to follow this pattern in naming your identity properties, then you can instruct code only which property to use as the identifier.

ContextBuilder is the class that knows how to build the ObjectContext and metadata from your classes.

This code modifies how the entity for the Category class should be configured beyond the initial assumptions. Specifically, it uses the HasKey property to define that the CID property should be used as the key rather than ID (which doesn’t exist in the Category class).

builder.Entity<Category>()
            .HasKey(c => c.CID);

This is merely the tip of the iceberg.

The ADO.NET team has a list of improvements to Code Only and Self-Tracking Entities to look for and will be providing detailed walkthroughs of the new features in their blog post ADO.Net Entity Framework Community Technology Preview Released!

You can get the new bits here: update of the Entity Framework Feature CTP