system.data.objects dev guy

It’s time to rip up EntityBag and throw it away

dsimmons@microsoft.com — Thu, 05 Nov 2009 18:36:05 GMT

A couple of years ago when the overall shape of what we would ship in the first release of the entity framework became apparent, I realized that one of the biggest issues users of that release would fight with was creating N-tier applications. So I started a project to explore the space by creating something I called EntityBag. In spite of the fact that I wasn’t too thrilled with the overall approach, I thought it would be a good exercise and if nothing else it would help illuminate the issues with building this kind of application on the EF and demonstrate to folks what techniques they could use with the EF to solve these problems. The result of this investigation was a series of blog posts and a sample project which I uploaded to code gallery. You can check out the project at: http://code.msdn.microsoft.com/entitybag/ That site also has links to each of the relevant blog posts which is where the real interesting data lives.

At the time that I created EntityBag (mostly January 2008), the version of the Entity Framework was called “beta 3”, and it was before the first RTM of the product. Unfortunately, when the first version was finally released we included a change to by default generate classes which would serialize an entire graph of related entities as one (at beta 3 only one entity would serialize at a time) which ended up breaking EntityBag and the fix involved fairly major surgery. From the beginning this project had never been intended as a full-quality production solution—I just wanted to teach people how they could use the EF to build the right solutions for their particular projects. In addition I wanted to work with the team to produce a much better, long-term solution for N-tier apps, so whatever time I had available for this topic I poured into the next release of the EF (EF4) rather than into updating the EntityBag project.

If not EntityBag, then what have we been doing for N-tier?

The team has been working hard to make N-Tier much easier with EF4, and the result is several key features that are available now when you combine Beta 2 of VS2010/.NET 4 and yesterday’s release of what we call the EF Feature CTP 2.

The first critical addition to the product are core changes to the ObjectContext and ObjectStateManager APIs which make working with entities which spend some time detached from a context MUCH easier. These changes were described about a year ago in this post to the EF Design blog. There have been a few small adjustments to the APIs as we went through the experience of the first and second betas for this release, but the core changes are all there along with much of the reasoning behind them.

Next, we added support for foreign-key relationships which allow FK properties to be added to entities, and the system does intelligent fixup between the FK properties and the collection and reference “navigation” properties which were the only representation of a relationship which the EF had in its first release. FK relationships are important to N-Tier apps for two reasons: First off, they make it easier to support scenarios where you don’t want the perf hit (magnified in N-tier applications) of retrieving an entire object in order to establish a relationship. With FK properties you can just set the key value for the relationship. This was possible before by setting an EntityKey property, but that was harder than it should have been and MUCH harder (and sometimes impossible) when you have POCO entities. Even more interesting for N-tier applications, though, is the fact that FK relationships give the EF the knowledge that a relationship’s persistence is fundamentally tied to a particular entity rather than being conceptually completely separate, and this is important because it allows the EF to use concurrency checks for the entity to cover concurrency checks for the relationship as well. In the first release of the EF, the framework had no way to know from the conceptual model which if any entity “contained” the FK for the relationship so it performed concurrency checks for the relationships separately from the entities which meant that you needed the original value of a relationship not just the original value of whatever concurrency token you used for the entity. Uggg… That’s a little long-winded and obtuse, but the key point to realize is that having FK-relationships makes n-tier applications more efficient and intuitive in at least a couple of ways.

Finally, we had resounding feedback in response to the initial N-tier post on the EF Design blog and in other places saying that while the core APIs were flexible and made things easier, there was still just too much work required to build end-to-end N-tier solutions. So we created the self-tracking entities template which ships for now in Feature CTP 2 but will be in the box when .NET 4 launches on March 22, 2010. Self-tracking entities won’t be right for everyone, and for those folks where they aren’t a great fit as is there will either be the option to modify the template (Long live T4!) or to write code by hand using the core API improvements on which the STE template is built. If they do match your situation, though, they make things MUCH easier. The amount of code required is dramatically less, and the functionality is really pretty great. You can write simple service methods that return entities. On your client (which does NOT require .Net 4 or any version of the entity framework—it works on silverlight, for instance) you can manipulate entity graphs by adding, deleting and modifying entities as well as splicing more than one graph together if you like, and the entities will keep track of the minimum required set of original values as well as whatever changes are made to them all by themselves. NO BAGS OR OTHER EQUIPMENT REQUIRED. The only constraint is that you must use the generated self-tracking entity code on your client (not a simple proxy). Then back on your service, the code to reattach that graph to the context with appropriate original values and all the tracking information is literally one method call: ApplyChanges.

How can I learn more about all this?

In addition to the posts referenced above, I recommend taking a look at the Self Tracking Entities walkthrough which was published after the first release of the feature CTP. The current release of the STE template is a little different, but this is a great starting point, and more information will be available on the ado.net team blog soon. The other resource to consider is that over the course of this summer I wrote a short series of articles in MSDN magazine about the topic of N-Tier in general and especially around using it with the Entity Framework. The third article in that series just came out in the November issue, and it contains samples both of using STEs and using the core APIs to build other N-tier solutions. You can find the articles online here:

So, death to EntityBag! Long live EF4!

- Danny

D3: Building Great Software is a Battle, Don’t Leave Any Assets on the Sidelines

dsimmons@microsoft.com — Tue, 30 Jun 2009 12:01:56 GMT

Another D3 release is up. This time I continued my focus on fundamentals. Some of this is tedious, but as I establish solid mechanics I’m starting to gain some momentum. The theme for today is using every last asset at your disposal to fight the battle to build great software. When I first came to Microsoft a number of years ago, I was given the book Writing Solid Code to help get me on the path to building world-class, reliable software. While the book is a bit dated these days, the key message I took away is as important to me now as it was then:

Writing software is hard. So hard, in fact, that we need to play every trick in the book (and then some) if we’re going to have any hope of really getting it right.

The previous two versions of DPMud were just hacks, but this time around I’m trying to build something that demonstrates how the EF can be used as a key component in software to be proud of. So, I ought to do things right—at least as much as I can given time constraints and everything else.

Often Overlooked Asset #1: Analysis Tools

This weekend I spent some time enabling fxcop and stylecop for D3. Actually I’m using the VSTS code analysis feature rather than fxcop because it’s built in to the VSTS download of VS2010 with really nice integration. Turning it on was a breeze, I just right clicked on each of my projects, chose properties, clicked on the code analysis tab and then checked the Enable Code Analysis on Build box. Actually, the first step was to download and install the VSTS flavor of VS2010 since I had initially just installed VS-Pro. I was happy to find, though, that the web install was able to install VSTS on top of my existing pro install without any trouble and was even smart enough to skip all the minor components that were already on my machine…

The hard part was discovering just how many issues it could find even with the very small amount of code present in D3 so far. As you can see above I’m just using the minimum recommended rules right now, and even with that I had to fix quite a few issues. Most of them were essentially cosmetic things, but it did catch a place where I was doing string concatenation of a SQL query that should have been using a parameter. There wasn’t any user input in sight, so I didn’t really have to worry about an injection attack, but it’s still a much better practice to use parameters wherever possible so I was happy to fix it. At some point I expect that I’ll go back and crank the rule-level up even higher, but there were enough issues when I did that which were more about personal preference than really being super important (like requiring that assembly names begin with a capital letter) that I decided it wasn’t worth the effort just yet.

I also downloaded stylecop and turned it on. It’s a little more work since it’s not part of the core product, but like fxcop it really was surprisingly easy to turn on and then the real work was making the project comply. I’m so glad that I did it now rather than later in the project, because keeping things going as I make incremental changes appears quite easy—the hard part is in the conversion. If you have a large amount of code already, I would still recommend making the switch to these tools, but you might want to checkout the stylecop team blog where there is a post about ways to make sure all new code is checked and then gradually convert older code. Fxcop is probably a bit more difficult but still worth it.

In order to turn on stylecop, I copied the binaries for the tool to a directory under my source control, modified the batch file I load for my development environment to set an environment variable pointing to the directory where stylecop is present. Then I unloaded each csproj, edited the XML and added one import element pointing to the stylecop targets file (I put mine next to the Import element for the standard csharp targets):

<Import Condition="'$(StyleCopPath)' != ''" Project="$(StyleCopPath)\Microsoft.StyleCop.targets" />

I put the condition attribute on it so if you don’t have the environment variable defined, it won’t try to load anything. That way everything builds and works without stylecop. (Code analysis also has the feature that if you don’t have it installed because you have VS-pro or something instead of VSTS then the configuration is just ignored and everything builds fine.) Unfortunately, this same edit needs to be made to each csproj file so the trick is to make sure not to forget this when adding new assemblies in the future.

By default both code analysis and stylecop report things as warnings, but I wanted to make certain everything was fixed so I also added a couple properties to the csproj files that change them into errors rather than warnings:

<CodeAnalysisTreatWarningsAsErrors>true</CodeAnalysisTreatWarningsAsErrors>
<StyleCopTreatErrorsAsWarnings>false</StyleCopTreatErrorsAsWarnings>

One interesting issue that I ran into is that the stylecop VS integration doesn’t seem to work for VS2010. Most of the time that’s fine because the VS integration is really only about editing the stylecop settings to turn off certain checks and the like. The build integration that I describe above is all you need to make sure your source code is checked and warnings or errors appear in the VS IDE, but if you do have something you want to turn off (and in my case I decided to turn off the requirement to add documentation comments to everything as well as a few other small cosmetic things) then you need to edit the stylecop settings. Fortunately if you double click on a Settings.Stylecop file in windows explorer, it will launch the UI for editing the settings independent of VS. Probably there’s some other way to bootstrap this process, but for me the easiest way was to just launch the VS integration in VS2008 and then copy the settings file to my other project. Once you have the right settings file, you just need to put it in the root directory of your project.

Asset #2: Check Constraints in the DB

I don’t recommend trying to add check constraints for everything, but there are places where the database is in a good position to enforce constraints on your data. In many cases the EDM itself will enforce constraints—in the case of D3, the association between Actor and Room has cardinality 1:* rather than 0..1:* which means that every Actor must have a Room, and the EF will enforce that. In the case of the association between Item and Room and the association between Item and Actor, we need there to be one and only one of those associations for each Item at any one time, and the EDM doesn’t have any way to represent that. For both of these kinds of issues we will want to add business logic to the classes to make sure these things are prevented well before the time of saving changes, but it’s still good to enforce them in depth.

In the case of the item associations, I decided to use a check constraint in the database. So I added a partial method call to the generated database creation code so that it’s easy to do this:

internal partial class SqlDb
{
    partial void Customize()
    {
        // Check Constraint which requires that Items live in either a room or on an actor.
        this.ExecuteCommand(@"ALTER TABLE [dbo].[Items] 
                              WITH CHECK ADD CONSTRAINT [CK_Item_one_and_only_one_location] 
                              CHECK ((([Room_Id] IS NULL OR [Actor_Id] IS NULL) AND 
                                  NOT ([Room_Id] IS NULL AND [Actor_Id] IS NULL)))");
        this.ExecuteCommand(@"ALTER TABLE [dbo].[Items] CHECK CONSTRAINT [CK_Item_one_and_only_one_location]");
    }
}

Which brings me to the last asset in my list for today.

Asset #3: Unit Testing Your Brains Out

I’m sure this isn’t anything new to most of you, but like many others I’d say that I probably can’t emphasize enough the impact really drinking the unit testing kool-aide can have on your development. D3 truly doesn’t have all that much code yet, and every time I add more tests I discover more issues. Testing makes your code better as you go, plus it creates both documentation and automated verification which will help prevent regressions later.

Conclusions

There are always things you can do to make your code better. Even more important, though, is to find things you can do to make CERTAIN that your code is better and will stay better. Your software will benefit from it—D3 already has.

- Danny

D3: Fun with Concurrency and Model First – Part 2

dsimmons@microsoft.com — Sat, 27 Jun 2009 11:14:37 GMT

In my last post I began the story of how I added concurrency checking capabilities to D3—we conquered a bug in the model first workflow activities in VS 2010 beta 1. Next we need to look into ways to customize the SSDL generated so that the concurrency column will end up with the RowVersion type that SQL Server will automatically update when any part of the row changes.

This lead to the next surprise. At first I thought that I would add a new custom activity to the workflow which would fix-up the SSDL, but this turned out to have its own complexities. As it turns out, the model first process runs the workflow within the visual studio process which means the DLLs containing activities for the workflow are loaded in the same way other VS DLLs are loaded, namely from the VS install directories or from the GAC. This also means if the DLL changes, you have to shutdown VS and restart it before model first will reflect the change. Conclusion: If you want to create a general purpose activity that many folks will reuse, then this is a reasonable approach You can carefully debug an activity and set something up to install it centrally. But, if you need a one-off customization, this is just too hard.

So we’re looking into options to help here, but in the meantime I’ve discovered another approach which seems to work well. The default workflow described in DbGen.xaml has two activities. The first one takes the conceptual model and produces an MSL and SSDL string, while the second one takes the SSDL and produces something which will create the database (normally a SQL file, but after my first round of customizations for D3 it will produce a c-sharp file with a method that will create it).

It turns out, though, that the second activity under the covers is a general-purpose mechanism that can be configured to take in a string, run it through a T4 template and produce an output string. The nice thing about using a template is that it allows you to write arbitrary code as a one-off in your solution and easily iterate on your design, modifying and rerunning without any need to restart VS, etc.

Eureka! The second activity can be used twice. In between the two default activities, it can be inserted again and configured to take the SSDL in, transform it with a different template and send it on to the final activity. In addition model first makes some useful bits of information like a path to the EDMX file available to the template, so we can access the CSDL in order to make better decisions about how to modify the SSDL.

The relevant part of the resulting XAML looks like this:

<Sequence>
    ...
    <edm1:SsdlToDdlActivity ExistingSsdlInput="[ExistingSsdl]"
                            SsdlInput="[Ssdl]"
                            DdlOutput="[Ssdl]"
                            TemplatePath="DbGen\SsdlUseRowVersion.tt" />
    ...
</Sequence>

For D3, the fix-up we need is to find properties in the SSDL which correspond to properties in the CSDL with the following characteristics: type is binary, maxlength is 8, concurrency mode is fixed and store generation pattern is computed. So we read the EDMX into an XElement tree in memory and then use LINQ to XML to gather the names of properties that need to be changed in the SSDL grouped by the name of the table in which they appear:

var query = from property in csdl.Elements(edm + "EntityType").SelectMany(t => t.Elements(edm + "Property"))
            where (string)property.Attribute("Type").Value == "Binary" &&
                  (string)property.Attribute("MaxLength").Value == "8" &&
                  (string)property.Attribute("ConcurrencyMode").Value == "Fixed" &&
                  (string)property.Attribute(store + "StoreGeneratedPattern").Value == "Computed"
            group (string)property.Attribute("Name").Value
            by entitySetName(property.Parent, csdl, edm);

This query depends on knowledge of the algorithm used by the CsdlToSsdlAndMslActivity to map conceptual model properties to the database—namely that the column names are the same as the property names on the entities and (at least for the base types of entity sets) the name of the table is the same as the name of the entity set that contains the type. So we query the csdl for all the elements that represent properties which have the required facets and extract the name of the property, then we group those property names by the name of the entity set containing the entity type to which the property belongs using these two functions:

string entitySetName(XElement entityType, XElement csdl, XNamespace edm)
{
    return (from set in csdl.Element(edm + "EntityContainer")
                            .Elements(edm + "EntitySet")
            where entityTypeName(set) == entityType.Attribute("Name").Value
            select (string)set.Attribute("Name").Value).Single();
}

string entityTypeName(XElement entitySet)
{
    XElement schema = entitySet.Parent.Parent;
    string nsPrefix = schema.Attribute("Namespace").Value + ".";
    string aliasPrefix = schema.Attribute("Alias").Value + ".";
    string typeName = ((string)entitySet.Attribute("EntityType").Value).Trim();

    if (typeName.StartsWith(nsPrefix))
    {
        return typeName.Substring(nsPrefix.Length);
    }
    else if (typeName.StartsWith(aliasPrefix))
    {
        return typeName.Substring(aliasPrefix.Length);
    }
    else
    {
        return "UNEXPECTED TYPENAME -- Where is the namespace?";
    }
}

The result of this query is an IGrouping<string, string> where the first string is the name of the entity set and the second string is a collection of property names from the base type within that set. With that information it’s a simple matter to load the SSDL into memory, search for the relevant entity types (in the case of the SSDL, each table is represented by an entity type and each column within the table is a property of that type) and properties within them. Then we swap out the attributes on the XElement for that property and set the name, the type to rowversion and the store generated pattern to computed. Finally, the template serializes the XML for the SSDL to its output.

But what about derived types?

The above algorithm is all well and good for a model with no inheritance—every entity’s corresponding SSDL can be fixed up properly, but what if I want to put a concurrency property on an inherited type? As it turns out the EF doesn’t allow that; concurrency properties can only be present on the base type for an entity set. While I generally don’t like limitations of any kind, I can’t really think of any scenario where I’d want a concurrency property only on a derived type, and if I do have them on a base type, then I don’t need a different or additional property on any of the derived types.

In fact, for standard TPH and TPC scenarios all of the properties for a particular entity instance appear in a single row of a single table. With TPH all of the instances are in a single table, and in TPC there are multiple tables involved but each type has its own table with all of the properties both from the base type and added in the derived type in that table. So the concurrency property will appear on each table and a rowversion will work just fine because any property changing in that row will cause the concurrency property to change.

I got to thinking about TPT, though, and became a little worried. First off, TPT is the default inheritance strategy used by model first. In this strategy the properties from a base type all live in one table which has a row for every single entity in the set, while extra properties added by derived types are placed in their own tables with just those properties and the primary key. So for example, if I have entity type A with an id, scalar properties a and b, and a version, and I have type B which inherits from A and adds scalar property c, then the database would have table A with columns for id, a, b and version PLUS table B with columns for id and c. (A similar sort of case exists with entity splitting or mixed mode mapping, but it’s easier to think about the pure TPH, TPC and TPT scenarios.) In this kind of mapping, what happens if I have an instance of type B and only property c is modified? Then only table B needs an update, and the rowversion would not be updated since SQL Server only maintains it for changes to the row of the table where it resides. Doh!

After banging my head against the wall for a little while, I decided to check with some folks on the team to see what might be done to solve this problem. Could we relax the restriction on concurrency properties only being allowed in the base type (in which case maybe for TPT scenarios we could add a second concurrency property on each derived type which would track changes on the extra tables)? As it turns out Colin Meek, one of the brightest guys I know and a key member of the team, was way ahead of me. He was able to tell me that the design for the update code that handles concurrency checks already takes this condition into account, and whenever any part of an entity which has a concurrency token is modified, the update system of the EF guarantees that the table with the concurrency value is “touched”. In cases where there isn’t a real modification being made, a fake update statement is issued which doesn’t really change anything but does force the rowversion to update.

So, in the end there was nothing to worry about. The SSDL modification algorithm described above works just fine, and once the updated workflow XAML and template were put into place in the project, model first sales through cleanly and produces code which creates a database with rowversion properties for each entity type. And the whole thing is verified by the successful completion of the unit test described in the first part of the article.

Conclusions

AppWeek has come and gone, and in the end I spent the whole week getting my one test to run, but we have that much more of a stable foundation for D3 work to build on. In addition at least one key bug was found and fixed, and some extensibility scenarios were explored and opportunities for improvement identified. The really good news, though, is that the EF in general is starting to become flexible enough that even if it doesn’t work out of the box in just the way I want, I can customize it for my needs.

- Danny

D3: Fun with Concurrency and Model First – Part 1

dsimmons@microsoft.com — Sat, 27 Jun 2009 03:10:00 GMT

The second D3 release is now up at: d3-0.0026.zip It’s the fruit of my labors pretty much full-time this week because it has been “App Week” on the EF team this week.

What a great time! My kids got out of school for summer break last Friday (which means I have the option of sleeping in rather than waking up early to drive the car pool), and this week I got to almost completely clear my calendar and spend time working on DPMud. App week is a time we set aside periodically to devote as much of our attention as possible to using the EF and related technologies to build applications so that we can experience some of the joys (and pain) of our valued customers. Most everyone looks forward to it, and we invariably find lots of great opportunities to improve the product.

While most other folks have been building new applications from scratch, I devoted my week to concentrated time on my long-running favorite app and just picked the next task off my to-do list and went to work. That task was to add a concurrency-token property to each of my entities and a simple test to verify that optimistic concurrency checks are working correctly. Seems pretty simple right? The model currently only has 4 entities, so how hard could it be? Can you say “working all week on this one task”? :-(

I won’t claim to be a test-first kind of developer, and the test code below is something I wrote after I had things working rather than first, but I’ll show it to you first so you can capture the goal. Then we’ll talk through the challenges I encountered and how I conquered them (in the hope that I can save you some pain). If you remember from my post about the last release, each entity currently in the model has a similar set of scalar properties but different relationships. My idea was to just add a Version property which would be marked as a concurrency token and setup to be automatically updated in the database any time any property on the entity changes so that we would get automatic concurrency checks. This property should actually have protected visibility because I don’t want to interact with it directly when using my entities—I just want the EF to use it and maintain it for me. The result would enable this test helper method:

private void VerifyConcurrency<T>(Func<T> create, Action<T> modify) where T : class
{
    using (var ctx = Utilities.CreateTestContext())
    {
        var objectSet = ctx.CreateObjectSet<T>();
        var obj = create();
        objectSet.AddObject(obj);
        ctx.SaveChanges();

        using (var ctx2 = Utilities.CreateTestContext())
        {
            var key = ctx.ObjectStateManager.GetObjectStateEntry(obj).EntityKey;
            var obj2 = (T)ctx2.GetObjectByKey(key);
            modify(obj2);
            ctx2.SaveChanges();
        }

        modify(obj);
        ctx.SaveChanges();
    }
}

I made the method generic and gave it two delegate parameters so that I can easily re-use it for each entity type I currently have plus extend it as I add more types over time. I also designed the code so that it will work with POCO types since I anticipate switching D3 to use POCO classes in the near future. As a part of this release I also introduced a simple utility method which creates the D3Context with a connection string to my little test database—this way it’s quick and easy to type since intellisense finds things for me.

The basic pattern in this method is that it uses one context to add an entity to the database. I use the create delegate because different entities have different requirements as far as what must be set on them to make them persist successfully. Each of our current entity types requires a non-null Name property, for instance, but while the Room entity doesn’t have any other required properties, an Actor must have a non-null Room reference, etc.

Once the new entity is added, I then create another context instance (which means another connection to the DB, etc.) and on it retrieve another copy of that same entity. I do this retrieval by having the state manager in the first context lookup the entity for me by reference (works for POCO) and then give me back the EntityKey corresponding to it (also works for POCO even though the entity itself doesn’t have an EntityKey property). Then I can use that key with the second context to load another copy of the entity, and call the modify delegate which makes a unique update to some property on the entity and saves that update to the database.

At this point the first instance of the entity is being tracked by the first context, and it’s concurrency token (assuming everything is configured correctly) represents the state of the entity before the second context updated anything. So we call the modify delegate on this entity and SaveChanges which throws an OptimisticConcurrencyException because the concurrency token in the database doesn’t match what’s in this context.

In the actual test, I create a list of Action types which call this method specifying the appropriate type and passing in lambdas for the create and modify delegates. Then it just loops over that list running the action and verifying that each call produces the appropriate exception. You can look at the file Tests\Concurrency.cs in the release if you want the full details.

The point of all this, though, is that to make this test pass I needed my entities to have concurrency properties that were configured properly in the database. With recent versions of SQL Server, the best way to accomplish that is with a RowVersion column (previously called a timestamp). This special column type is stored as an 8 byte binary, and the server guarantees that it will have a unique value any time any part of a row in its table is modified. The trick is that this special type only exists in the server—it’s not available in the CLR or the EDM conceptual model. If I were reverse engineering a model from the database, that would be no big deal. The tools would automatically map the RowVersion column in the database to an 8 byte binary property in my model. In this case, though, I’m using model first to generate the database from my model, and when I create the property, model first has no way to know that it should create a RowVersion type rather than a binary type in the DB.

So it was time to customize the model first process again, but before I got even that far I ran into a bug. Ahhh… The joy of AppWeek and of beta software. The issue is that if you set Concurrency Mode to Fixed on any of your entities in VS 2010 beta 1, then when you choose Generate Database Script from Model, the tool will display an error rather than generating the script. Considerable debugging and discussion with the developer who did most all of the work for model first later, we were able to track the problem down to a one line problem where model first was assuming that all property facets that could be set in the conceptual model were at least valid possibilities for the storage model, when in fact Concurrency Mode is the one property which can only be in the conceptual model and not the storage model. So the workflow activity that generates the SSDL from the CSDL was triggering an exception from the metadata system.

This bug will be fixed in beta 2, but that doesn’t help us much for D3 right now. So my final solution was to extract a small piece of the model-first workflow into a separate DLL, make a fix to the code and then modify the DbGen.xaml file which describes the workflow to call out to that DLL rather than the core version that ships with the product. The final result is part of this release, and it’s called modelfirst-bugfix.dll. If you go the misc directory under the release and run the batch file install-bugfix.cmd it will copy the DLL to a directory in your VS installation (make sure you run this from a VS command prompt where the DevEnvDir environment variable is set). Naturally this little hack is completely unsupported, but it works for me, and it might work for you too if you need to use model first with concurrency and beta 1 of EF4.

Now at least I can run model first when I have concurrency configured, but I’ve still got the problem that my properties come through as binary rather than RowVersion type in the DB. That’s where I’ll pick up the next post… Until then, happy coding.

- Danny

D3: Release 0.0010

dsimmons@microsoft.com — Thu, 11 Jun 2009 02:22:57 GMT

OK folks, after way too much delay, I’ve finally gotten all my ducks in a row and begun the process of rewriting DPMud. Since my goal is to completely rebuild it from scratch, the process is going to take a while, and I intend to let you all look over my shoulder a bit as I go. So don’t expect too much from this first release—all we have is a basic solution with a very simple model and some unit tests. You can download the release from: d3-0.0010

First, let’s take a look at a few decisions that came up along the way, and then we’ll dig into some specific code areas.

Decisions

Source Control and Licensing: It is very important to me to make this project as relevant and useful as possible for folks trying to build applications using the EF. So we decided to release the code via MS-PL which is a very permissive license. I’m no lawyer, but my understanding is that this basically means you can copy the source and use any part or all of it in your own projects. Originally it was my hope that I could just put the project on codeplex and use it for source control so that anyone interested could enlist and just sync down changes to their local machine as the project progresses, but there were various hang-ups with this approach, and in the end I decided to just use local source control and then periodically push releases up to code gallery which has a simple site system and where everything is automatically licensed with MS-PL.
Version Numbers: One of those mundane but required decisions along the way is how we will create version numbers for the releases. Here’s what I decided: Until we have the thing up and running, everything is version 0.something. The last four digits of the version are in the form MMDD where MM is the number of months since I started releasing (so 00 is June ‘09), and DD is the day of the month for that release. I haven’t done it yet, but that allows me to have a very simple algorithm to automate version stamping and such as I make subsequent releases.
EF Versions and Dependencies: One critical area of decisions was around what EF features do I take dependencies on—particularly when we’re in the state where EF4 is not yet complete. In the end I decided that the main principle was to avoid taking dependencies on EF features that aren’t yet available outside the team so that you can stay up with me if you like. This means, for instance, that I’m not going to take a dependency on foreign-key support even though I have access to an internal build where it’s working great. When FKs are publically available, we’ll take a look at the project at that point and evaluate whether or not it’s worthwhile to refactor the app to take advantage of them (almost certainly we will do that refactoring). Similarly, I’m not yet going to take a dependency on self-tracking entities because it isn’t yet available. It will become available much sooner than FKs, though, so I will plan on taking advantage of it soon. A harder question was code-only. The first CTP of it will also be available soon (in the same download with self-tracking entities), but I already know of some areas where I’ll need more control over the model and database generation than code-only will support in its first CTP, so we’ll have to wait on that refactoring until a later CTP of code-only. So the basic approach will be to use EF4 beta 1 with model-first to make it efficient to design the model and generate the database and code from that model.

Initial Model

Like every other part of the system, we’re going to start with a simple model and expand. Here’s a first look:

A few things to notice:

Each entity has an Id property which is a server-generated integer.
Each of these entities is a “real” thing which players will interact with in the virtual environment of the game, and as such we have given them all a few common properties including Name and Description. Eventually we’ll define an interface for these common properties so that we can reason about the commonality of these objects. We could have an abstract base class for each of these entities, but we want them each in their own entity sets, and the designer doesn’t support more than one entityset with the same base type, so using an interface gets the key aspects we want while allowing us to still use the designer (we don’t really need implementation inheritance here anyway).
The two associations between Room and Exit have each had one of the navigation properties removed so that Room only has one collection of “Exits” (it doesn’t also have a collection of entrances, so to speak), and Exit has only the TargetRoom navigation property. This makes our entities follow the intended model where exits go only one way. If you want two rooms to be connected in a symmetrical fashion, you need two exits one going from room A to room B, and another one going back from room B to room A. This is important because it means that we can easily give different names to the exits (from room A you go East to room B, but from room B you have to go West to get back to room A), and it means that you don’t always have symmetrical paths (when you jump off a cliff you can’t necessarily get back to the top of the cliff using the same way you got down, etc.).
We don’t yet have version fields for concurrency checking. That will come later, because it requires some additional customization to the database generation.
Item has a relationship with Actor and one with Room, but logically an item can only be related to one of them at a time (and it must always be related to one or the other so that items have location). These constraints we will represent in the database rather than the conceptual model. They aren’t currently enforced, but they will be once we make additional customizations to database generation.

Customizing “Model First”

The feature we call model first shows up in the entity designer (aka Escher) as the option “Generate Database Script from Model” on the context menu when you right click on an open part of the designer surface. Out of the box this will generate a SQL DDL script that you can use to create a database for persisting the entities in your model. It also automatically generates the SSDL and MSL which corresponds to that model. This is great because it means that I can concentrate on the thing that is important to my program, the conceptual model. If I make a change to the model, once that change is complete, I’m done. I don’t have to also modify the database and the mapping to reflect that change. Since I’m also generating entity classes from the model, I get a nice “DRY” (Don’t Repeat Yourself) development experience even though various parts of the system do have repetition, I don’t have to engage in that repetition myself. Naturally we want to have an even more DRY experience, and code-first will lead us there for folks who want to do everything in code, but for the design-time experience this is not half bad.

Naturally, though, there are times where I want more control over the database generation process, which is why there are customization hooks built-in. The process of generating the database is orchestrated by a customizable workflow which has a couple of activities that manage generating an MSL and SSDL for the CSDL and then generating SQL from that SSDL. This second step (SSDL->SQL) is further customizable because it is accomplished with a T4 template. Eventually we will take advantage of these customization mechanisms to allow us to automatically generate rowversion columns for concurrency, constraints that keep item relationships straight and other things.

All of this seemed somewhat academic, though, for the first few phases of the project until I started thinking through my testing strategy. Eventually we’ll test parts of the system using fakes and mocks and the like, but we also need integration tests that send data all the way down to the database and back, and I wanted to start writing those tests right away and deliver them with my initial stab at the model. To make that work I really wanted APIs for creating and dropping the database somewhat like we can get from L2S so that my tests can create a temp version of the database (separate storage but same schema) and test pushing data in and out of it. Eventually this will also be useful for deployment, import/export of data, version-to-version upgrades and the like.

So, I decided to customize the db generation process now by modifying the SSDL->SQL template to generate a C# method for creating the database schema rather than a SQL script. The process to set things up for customization looks like this:

Copy the workflow xaml file from %ProgramFiles\Microsoft Visual Studio 10.0\Extensions\EntityFrameworkTools\Workflows\DbGen.xaml and the SQL gen template from %ProgramFiles\Microsoft Visual Studio 10.0\Extensions\EntityFrameworkTools\Templates\SsdlToSql10.tt to my project.
I renamed the template to SsdlToCode.tt and modified the xaml file’s TemplatePath to just have that name rather than the full path to the original template.
Both files I added to my project in VS, but because they aren’t actually used at compile time (they are just used by the designer when I choose the menu option to generate the database) I made sure that the Custom Tool property for each of them is blank and the Build Action property is set to None.
I clicked on a blank part of the Entity Designer surface and then set the “Generate Database Script Workflow” property to just DbGen.xaml (just the file name because the xaml file is in the same project and directory with the EDMX).

Now when I choose the option to generate the database it runs the workflow as specified in my project which then uses the template from my project rather than the default versions.

Next, I modified the template file to output C# code rather than SQL. You can find the template file in the release and do your own diff against the default template, but the basic approach was to wrap each batch of SQL statements up to a “GO” in an ado.net command with a C# @”” string and execute it. I eliminated a chunk of the template that would drop existing tables because my approach is to drop the whole database and recreate it, and I put all of these execute statements into a method on an internal partial class that I added to my model DLL. That way most of that class is defined outside the template but this one method can be defined by the code generated from the template. Then I further created a partial class file for my generated EF context and added methods to check for existence of the database, drop the database, and create it (using the generated method).

One current limitation in the designer is that the generate database command always by default creates a file with a name based on the name of the EDMX file and with SQL for the extension. I’ve already started discussions with the designer folks about adding some customization hooks here, but for now you just have to remember that whenever you generate the database you should rename the file.

All of this enabled me to write the following simple test:

[TestMethod]
public void DropAndCreate()
{
    using (var ctx = new D3Context("name=D3TestContext"))
    {
        ctx.DropDatabase();
        Assert.IsFalse(ctx.DatabaseExists());
        ctx.CreateDatabase();
        Assert.IsTrue(ctx.DatabaseExists());
    }
}

Not only is it simple to perform these operations, but also everything is based on the connection string given. So I just created two different connection strings in my app.config file—one called D3Context (the default) and the D3TestContext which is the exact same as the other except that it has a different initial-catalog name for my test database.

The SqlDb Internal Class

It’s probably also worthwhile to take a brief look at the internal class I called SqlDb which does the heavy lifting for these database interactions. The first interesting piece of the puzzle is that in order to create or drop the database with SQL Server (or in this case Sql Express) we need to make sure that we don’t use a connection string with the database in question as the initial-catalog. So, we extract the connection string from the StoreConnection property on the EntityClient connection instance created by the context and create a SqlConnectionBuilder from it. SqlDb’s constructor takes a DbConnection parameter since that’s what ObjectContext exposes and creates the builder like this:

var builder = new SqlConnectionStringBuilder(((EntityConnection)entityConnection).StoreConnection.ConnectionString);

Then we store the initial-catalog property into a string field so we know the name of the database we should be working with, and then we replace the initial-catalog with “master” since that database is present on every SQL instance.

The constructor then extracts the new connection string from the builder and uses it to create a new SqlConnection instance. We use this connection to execute commands without directly connecting to the database. The class also implements IDisposable so that its Dispose method can Dispose of the SqlConnection.

The other interesting trick which came up was the fact that while my initial executions of the above test succeeded while stepping through in the debugger, running the whole test straight through failed because the first part of the DropDatabase method executes a command to check if the database exists, and after that the drop command would fail with an error saying that the database was in use. Eventually I fixed this by adding a ClearAllPools method to the class which closes the connection, calls SqlClient.ClearAllPools() to make sure that there are no connections in the connection pool holding onto the database and then re-opens the connection. This method is called after the existence check and before the command to drop the database.

Conclusions

We’re finally off and running! We have an initial model, a simple way to deploy the database and some initial tests. (Those tests have already found a couple of issues I had in my first crack at the model, by the way. So the testing is already paying off. Yay!) Next I’ll probably tackle some further customizations of the generated database. Soon we’ll look at replacing the default code gen with a POCO template, and in the not distant future I hope to fill out more pieces of the architecture so we can get a small end-to-end slice going with a WCF service and Silverlight, but all in good time…

- Danny

Links: EF4 Podcast, N-Tier Anti-Patterns, and some thoughts about DDD

dsimmons@microsoft.com — Wed, 03 Jun 2009 10:56:50 GMT

Here are a few more resources I hope you will find useful:

Recently I had a conversation about EF4 with Carl and Richard of .Net Rocks, and it went up on their site today. Have a listen at http://www.dotnetrocks.com/default.aspx?showNum=451.

In addition, I have an article about design/architecture decisions related to n-tier applications in the latest issue of MSDN Magazine. This article is actually the first part of a two-part series. Originally it was a single longer article that wasn’t so depressing as this one came out (all about what *not* to do without really giving any help on what you should do). There are some important concepts, though, so hopefully you’ll find something useful even in this first part.

At the same time that I’ve been busy with these, some other folks have been trying out the beta of EF4 and some very interesting posts are starting to appear like this dive into producing a POCO repository with the EF by Keith Patton and a great discussion of LINQ Expression Trees and the Specification Pattern by the EF team’s own David DeWinter.

- Danny

Some Great EF Resources

dsimmons@microsoft.com — Tue, 26 May 2009 02:33:57 GMT

One of the things that’s cool about working on the EF team and getting the chance to talk to customers about what we do and answer questions and such is that I get to hear about lots of things that folks outside the EF team do with the EF. It’s especially neat when folks tell me about books, tools and other resources which help folks get more out of the EF or related technologies. Unfortunately I’m often so buried under various responsibilities that I don’t always share these great resources as quickly as I should. I also try to make sure that I give things a look over before I share them so that what I point you to are only the best, most valuable things which of course means that it takes even longer… Sigh.

The only reason I’m wasting your time with all the apologies today, is that I have three particularly good resources which I’m way overdue sharing. I assure you (and the creators of these resources) that the delay has nothing to do with their quality. If you haven’t seen these things, I highly recommend you check them out.

The first one is Julie Lerman’s book, Programming Entity Framework. Julie’s tireless efforts on behalf of the EF and its users hit a new height with the release of this book. There’s an incredible volume of material covering all parts of the first release of the EF, and all samples are written in both C# and VB.Net.

Next is the product of the Swiss MSDN team which put together a hand’s on lab for learning about the EF and even building an n-tier application using it. It’s all done using the first release of the EF (.net 3.5 sp1) so it doesn’t take advantage of the new features we have added in EF4 beta1, but it will help you learn the fundamentals, and if you are working on an application using the EF which must deploy before EF4 releases, then it will be an especially useful tool.

Finally, I’ve done some blogging about T4 and how you can use it to customize EF code generation in the first release. In addition you may have heard that EF4 uses T4 not only for all the built-in code generation but also for database generation. So learning to work with T4 is a good idea for anyone programming with the EF. Unfortunately, though, VS doesn’t have great built-in support for editing T4 templates. You can edit in VS, but it just treats them as a basic text file with no syntax coloring or intellisense support. Hopefully that will be fixed in a future release of VS, but in the meantime there are two companies which have released T4 editors that plug into VS which make the experience of working with T4 much more pleasant. Check out Clarius Consulting’s Visual T4 and Tangible Engineering’s T4 Editor. Particularly interesting is the fact that Tangible’s editor already has a version which works with VS 2010 beta 1, and you can download and install it from the extension manager within VS 2010.

If you give these a try, I’d love to hear about your experiences with them, and if you know of something else which makes it better or easier to work with the EF, I’m always looking for information about those things as well.

- Danny

EF4 beta 1 Forums & Docs

dsimmons@microsoft.com — Wed, 20 May 2009 22:02:56 GMT

Should have included this info in the last post, but better late than never.

If you have questions about EF4 beta 1, the place to ask is the EF4 pre-release forum:

http://social.msdn.microsoft.com/Forums/en-US/adonetefx/threads

If you are looking for the documentation, then you’ll be interested in this link to the MSDN online docs. For beta 1 docs are only available online, but they will be available both online and offline by the time the EF4 & VS2010 ships.

http://msdn.microsoft.com/en-us/library/bb399572(VS.100).aspx

- Danny

EF4 Beta 1 now available!

dsimmons@microsoft.com — Wed, 20 May 2009 21:21:40 GMT

In case you haven’t heard yet, VS 2010 beta 1 and .Net 4 beta 1 are now available for public download, and that means EF4 beta 1 is available as well:

http://msdn.microsoft.com/en-us/vstudio/dd582936.aspx

Lots of goodies! Check it out, and let us know what you think.

- Danny

Online TechTalk about POCO and other EF4 Features

dsimmons@microsoft.com — Fri, 15 May 2009 09:47:31 GMT

Yesterday, while we were here at TechEd, Alex James and I sat down and recorded a short discussion about POCO and other features coming EF4. Check it out at: http://www.msteched.com/online/view.aspx?tid=ef76e96c-7471-44a6-aa88-1ada037471ca

- Danny

Code Sample from my Applied Entity Framework talk at TechEd 2009 now available

dsimmons@microsoft.com — Fri, 15 May 2009 08:51:14 GMT

This week I gave a talk at TechEd focusing on architectural considerations as well as some useful tips for creating n-tier applications with the Entity Framework v3.5SP1. The code from the simple sample application is now available at http://code.msdn.microsoft.com/dtl401sample/. It includes:

an Entity Framework-based Business Object and DAL
some rudimentary validation implemented using a T4-template to create customized code generation with an OnValidate partial method much like is available from LINQ to SQL
a repository which abstracts the UI from data access & a fake implementation of that repository
an asp.net MVC-based UI with URL routing that allows you to specify either to run on the fake repository or on the real one
a WCF implementation of that repository which remotes calls from the web tier to the midtier
several unit tests

Have a look and let me know what you think. Of course this is not the end-all-be-all of anything. It’s just a sample designed to illustrate a few concepts, but maybe someone will find it useful.

- Danny

Cool things are coming in EF4!

dsimmons@microsoft.com — Tue, 12 May 2009 04:36:05 GMT

I’m off at TechEd this week talking to customers about the EF—especially about ways to be successful using the EF right now with 3.5sp1. Meanwhile, though, we’re getting close to releasing the first beta of EF4 (yeah!). As we gear up for that release, the team has begun a series of posts on the ado.net team blog about all the great new features.

Here are the posts released so far:

Update on the Entity Framework in .NET 4 and Visual Studio 2010: This has a quick overview of some of the most exciting new features—sort of a brochure if you will.
Sneak Preview- Persistence Ignorance and POCO in Entity Framework 4.0

There are a lot more posts to come over the coming weeks. So stay tuned to the blog, and let us know what you think.

- Danny

Lots of EF Fun at TechEd Next Week

dsimmons@microsoft.com — Wed, 06 May 2009 07:45:22 GMT

I’m off to TechEd North America in LA next week where I’ll be presenting a 400-level session titled “Applied Entity Framework”. The session will mostly be focused on helping folks be more successful using EF3.5sp1 but also with some info about features coming in EF4 and how to prepare for them. If you are going to be at TechEd, you might want to check out DTL401.

There are quite a few other sessions that are either completely about the EF or contain EF content. So I created the following I-Cal file which makes it real easy to view them all in Outlook or your favorite calendar system: http://www.the-simmons.net/teched-2009-ef.ics In addition to the break out sessions, there are some birds-of-a-feather sessions that sound like they will be very interesting. A helpful resource for folks unable to make the conference in person or who want TechEd info before or after the conference is TechEd Online.

While I’m there, I’ll also be spending plenty of time in the technical learning center and just generally hanging out trying to meet with folks to hear about what you are doing with the EF, to help solve any dilemmas you may be struggling with, and to help folks start getting excited about EF4. While I’m on the topic of EF4 the first beta is coming pretty soon, but if you are at TechEd there will be a hands-on-lab where you can get an even earlier preview of the bits. I know I’m biased, but I think EF4 is really cool. I’m hoping it will really blow your socks off!

One last thing… Julie Lerman recently posted about the fact that we have been referring to the next release of the EF as EF4 to help people keep straight the fact that this is the version of EF going out with .net 4, and that led to an email thread where she suggested that we get some t-shirts made which sounded like lots of fun to me. I would have loved to get a whole bunch of these to give away at TechEd but given tight budgets that wasn’t in the cards (and make no mistake, I’d rather see Microsoft funds going into people and products than shirts). So I did some hunting on the web and found a place that will make custom shirts in small lots and ordered a few to commemorate the fact that EF4 feels like a lot more than the average second release (in spite of the fact that we didn’t have a full release worth of time to devote). The shirts look something like this:

In the off chance that you are crazy like me and interested in such a shirt, you can get your own here: http://www.zazzle.com/v2_squared_ef4_tshirt-235150309421493680

The way this site works, if you buy one of these, they give me a 10% kick-back, but I’m certainly not trying to make any money off of these shirts. So any royalties that come my way from folks buying these will be donated to a local worthy cause: Seattle Union Gospel Mission which does a lot for the homeless and others dealing with hard times in the Seattle area.

In any case, here’s hoping to see you next week!

- Danny

Building N-Tier applications with the EF – The Basics

dsimmons@microsoft.com — Thu, 09 Apr 2009 08:08:00 GMT

Today I was looking at a post in the forums where someone asked a very natural and common question about the EF that I end up answering pretty frequently. So I decided to put my answer here on my blog to make it easier to refer back to the answer in the future. The question was essentially this:

I’m building a silverlight client (but it could just as easily be a rich client or an ajax app or any other client of a WCF service) with a WCF service on the mid-tier that uses the EF to persist changes to a database. I can easily write a WCF service method to retrieve entities, and I can also create one which will add new entities to the database by just calling AddObject and then SaveChanges, but I can’t figure out how to do an update. I was hoping there would just be an UpdateObject method or something like that. What do I do?

Unfortunately this is more difficult than we'd like it to be in EF3.5 (the first release). It's a bit difficult because the problem space is more complicated under the covers than it seems to be on the surface, so you have to think carefully about a few things. That said, the EF API could help more in these scenarios, so in EF4 we're working on a series of improvements which you can read about in posts on the EF Design blog such as this one: http://blogs.msdn.com/efdesign/archive/2009/03/24/self-tracking-entities-in-the-entity-framework.aspx
In the meantime, there are three important things you need to think about:

Keeping track of concurrency tokens for the purpose of doing concurrency checks when you update (you don't want to blindly overwrite a change that some other client has made to the same part of the database between the time when you read the data and the time when you try to write back your changes).
Keeping track of which properties you have modified on an entity. This is important if you want to make sure that the update to the database only includes the modified properties. If you are OK with sending an update statement that includes even unmodified properties (which by the way can sometimes even be faster because it might allow the database to reuse a query plan rather than generating a new one for each combination of modified props), then it may be OK not to worry about this one.
If you have a graph of related entities then you need to worry about tracking what kinds of operations happened to what parts of the graph--one entity modified, another one is a newly added entity, another one deleted, etc.

All of this amounts to tracking this information on the client side, communicating it back to your mid-tier through your WCF service methods, and then replaying information to the ObjectContext so the changes can be persisted. If you skip option #3 for now (one of the hardest parts with EF3.5 and something which can occasionally be skipped if you are willing to just have WCF service methods which operate on one entity or which treat all entities in the graph the same way--so you have separate methods for add, update and delete), then you already know how to do the add method. The delete method is also pretty straight forward, you just need to call Attach on the entity you pass to the method to bring it into the context and then call DeleteObject on it and SaveChanges. The interesting method, as you mention, is update...

The simplest but not terribly efficient way to solve the update method is to make a copy of the entity on the client before you make any changes so that at the time you want to update things you have both a copy of the original version of the entity and the modified one. Then your update service method can look something like this:

void Update(MyEntity original, MyEntity updated)
{
    using (var context = new MyEntities())
    {
        context.Attach(original);
        context.ApplyPropertyChanges(updated);
        context.SaveChanges();
    }
}

You can improve on this, though, if you are willing to make a few assumptions. First, if you can guarantee that the client will not change the property used for concurrency checks, then you don’t need the original value of the concurrency property. Secondly, if you are willing to always send all properties to the server on an update rather than just those properties which have changed, then you don’t need an original value for all the other properties to compare against to see if they are changed. In this case you can get away with only sending a single, updated entity from the client back to the mid-tier, and you just have to use some trickier APIs to get the entity attached to the context in a form so that the EF will treat it as modified. I wrote a previous blog post about how to do that. With the extension method from that post, you can get rid of the original entity argument to the update method and just call the AttachAsModified method followed by SaveChanges().

- Danny

D3: Using T4 to Generate Entity and Context Classes

dsimmons@microsoft.com — Wed, 08 Apr 2009 10:00:00 GMT

Sorry for the DPMud hiatus. Here’s another installment for those interested in the process. I’m still trying to get a public source repository up. Until that’s functional I’m not going to do a lot of development because I want to share the process with you. In the meantime I’m still laying groundwork where I can, and one aspect of that is using T4 to generate classes for the entities and for the data access layer.

Side Note: We’ve been trying hard to refer to EF versions using the corresponding .net version rather than “v1” and “v2” since talking in terms of .net versions makes it clear when and how the corresponding versions ship. So don’t be surprised when I refer to EF4 or EF3.5.

The idea behind using T4 for code generation is that I’d like to create the DPMud model using the EF Designer and then generate both the classes and the database from the model (database generation has been discussed previously on the EF Design blog). There are two key architectural requirements for these classes that we generate:

The entities should be completely persistence ignorant. That is, they should live in an assembly which doesn’t have any dependency on Entity Framework or ADO.Net DLLs. One concrete reason for this is that I want to reuse the entity classes in Silverlight. Happily, EF4 adds extensive support for POCO entity classes.
The DAL should be designed in a way that supports easy introduction of a fake implementation. That is, it should be a “seam” in the terminology of design for testability. Another feature of EF4 which supports this is the introduction of a new interface, IObjectSet<T> which is implemented by the ObjectSet<T> class which provides both a starting point for queries and a place to add and remove entities of that type.

So I created a couple T4 templates. They share some infrastructure for helping to read EF metadata, escaping identifiers, generating multiple files, one per class, etc. We’re working on getting that infrastructure into the core product, so I’ll concentrate on the unique parts of these templates.

The entity template iterates over each entity type in the metadata and generates a partial class with each property marked virtual so that an automatic EF proxy can be generated if necessary. For navigation properties, it generates properties that are simple CLR references or ICollection<T> instances with an implementation that does fixup. The fixup implementation is generated so that it can be included in the entity DLL and not introduce any other requirements to the entity classes.

The context template generates a class which inherits from ObjectContext and has properties that return ObjectSet<T> instances. It also generates an interface for the seam with IObjectSet<T> properties and a fake context implementation which has fake object set instances which have a very simple wrapper around hashset<T>.

This way I can put the entities into one DLL and the context, interface and fake context into a separate DLL for the DAL.

- Danny