Diego Vega

Entity Framework Feature CTP 2

divega — Thu, 05 Nov 2009 00:21:41 GMT

We have just released a new version of the Feature CTP that works on top of Visual Studio 2010 Beta 2. I have been focusing on Self-Tracking Entities a lot lately, and so it feels great to have this out for people to try it and give us feedback on it.

The new version of Code-Only is great too.

You can see the announcement here.

Thanks,
Diego

Standard generated entity classes in EF4

divega — Tue, 08 Sep 2009 04:35:00 GMT

A customer recently asked if there is still any advantage in using the entities that Entity Framework 4 generates by default instead of POCO classes.

Another way to look at this is: why are non-POCO classes that inherit from System.Data.Objects.DataClasses.EntityObject and use all sort of attributes to specify mapping of properties and relationship still the default in EF4?

This perspective makes the question more interesting for me, especially given a great portion of the investment we made in EF 4 went into adding support of Persistence Ignorance, and also given that using POCO is my personal preference, and I am aware of all the advantage this has for the evolvability and testability of my code.

So, let’s look from closer and see what we find.

Moving from previous versions

If you simply diff the entity code generated using the first version with what we generate nowadays, the first thing you will notice is that they haven’t changed much.

The fact that there aren’t many changes is actually a nice feature for people moving from the previous version to the new version. If you started your project with Visual Studio 2008 SP1 and now you decide to move it to Visual Studio 2010 (i.e. the current beta), it is a good thing that you don’t have to touch your code to get your application running again.

It is worth mentioning that many of the improvements in the new version of EF (i.e. lazy loading) were designed to work with all kinds of entities, so they didn’t really require changes to the code we generate.

Even if you later decided to regenerate your model to take advantage of new features (i.e. singularization and foreign key support), you might need to do some renaming, and some things may be simplified, but most things your code do will remain the same.

New code generation engine

As soon as you look under the hood though, you will notice that we actually changed the whole code generation story to be based on T4 templates. This opens lots of possibilities, from having our customers customize the code to suit their needs, to have us release new templates for entity types optimized for particular scenarios. This last idea is exemplified in the work we have been doing in the POCO template and the Self-Tracking Entities Template included in the Feature CTP 1.

At this point, we don't have plans to include templates for generating entities of other kinds in Visual Studio 2010, so the default, EntityObject-based template is the only one that is included “in the box”.

Change tracking and relationship alignment

It is also important that default entities enjoy the highest level of functionality in Entity Framework. To begin with, they participate in notification-based change tracking, which is the most efficient. Also, navigation properties on default entities are backed by the same data structures Entity Framework uses to maintain information about relationships, meaning that any change you make is reflected immediately on the navigation properties on both sides.

By comparison, plain POCO objects do not notify Entity Framework of changes on them, and relationships are usually represented by plain object references and collections that are not synchronized automatically. To work well with POCO, Entity Framework needs to compare snapshots of property values and reconcile changes in linked navigation properties at certain points of a transaction. To that end, we introduced a new DetectChanges method that allows user code to control explicitly when that change detection happens, and we also added an implicit call to it in SaveChanges.

As an alternative to that, we also introduced POCO Proxies that inject most of the change tracking and relationships management capabilities of default entities into POCO types by the means of inheritance. This kind of POCO Proxies are created only (basically) if you make all properties virtual in the POCO class and, if you need to create a new instance, you invoke the new ObjectContext.CreateObject<T> method.

Again, why is non-POCO still the default?

To summarize:

a. Default code-gen classes provide the easiest path for people moving from the previous version

b. When creating a model from scratch or from the database, you don’t even need to write the code for the entities themselves

c. You never need to worry about invoking DetectChanges or about making sure your code always uses POCO Proxies

d. Finally, if you really care the most about writing entities yourself, we make it very easy for you to opt-out of code generation and start writing your own POCO classes.

I hope this information is useful. So, now what kind of entity classes are you going to use?

WPF databinding with the POCO Template

divega — Sun, 26 Jul 2009 15:42:40 GMT

The new support for POCO in Entity Framework seeks to enable better ways of coding application domain logic without polluting domain classes with persistence concerns. Persistence Ignorance can in fact improve maintainability, testability and evolvability of an application by making it possible to write domain classes that the contain domain logic and nothing more.

Persistence isn’t however the only common infrastructure service that might affect how you write your classes. Others, such as databinding and serialization, sometimes require more than POCO types to work really well.

Disclaimer: I am not trying to enter a debate on whether you should use domain entities directly in databinding and serialization, I am aware of the recommended patterns :)

For instance, to get databinding to fully work with a domain model, each object and collection type has to implement a number of interfaces for things like change notification, type description, capability negotiation, etc. That said, a decent level of databinding support can be achived with simple POCO types and collection types that implement IList, such as List<T>.

In the POCO Template that is included in the Entity Framework Feature CTP 1, we use T4 code generation to produce POCO entity classes and a “typed” ObjectContext class based on an Entity Data Model. The POCO Template emits a special collection type named FixupCollection that has the capability to synchronize changes on both sides of a relationship (typically a one-to-many relationship is represented as a collection on the one side, and as a reference in each object of the many side). But as a colleague of mine found today, Since FixupCollection derives from ICollection<T> and not IList<T>, WPF databinding will not work with it in read-write scenarios.

If you try to bind to a collection emitted by the POCO Template (i.e. in a master-detail form), and the you try to edit it, you will run into this exception message:

'EditItem' is not allowed for this view.

The exception indicates that WPF considers that the collection is read-only.

Here is a way to overcome this:

Extend FixupCollection in a partial class to implement IListSource.
The implementation of IListSource.GetList has to return a binding list. For instance, I implemented a custom ObservableCollection that has the necessary hooks to update the underlying FixupCollection whenever elements are added or removed.
Currently, this doesn’t work the other way around. For instance, when entities added or removed in the underlying collection, the ObservableCollection is not updated.

Here is the code:

using System.Collections.ObjectModel;
using System.ComponentModel;

//TODO: update the namespace to match the same as the code-gen
//FixupCollection
namespace Model
{
    public partial class FixupCollection<TFrom, TTo> : IListSource
    {
        bool IListSource.ContainsListCollection
        {
            get { return false; }
        }

        System.Collections.IList IListSource.GetList()
        {
            return new FixupCollectionBindingList<TFrom, TTo>(this);
        }
    }

    public class FixupCollectionBindingList<TFrom, TTo> :
        ObservableCollection<TTo>
    {
        private readonly FixupCollection<TFrom, TTo> _source = null;

        public FixupCollectionBindingList(
            FixupCollection<TFrom, TTo> source)
            : base(source)
        {
            this._source = source;
        }

        protected override void InsertItem(int index, TTo item)
        {
            _source.Add(item);
            base.InsertItem(index, item);
        }
        protected override void RemoveItem(int index)
        {
            _source.Remove(this[index]);
            base.RemoveItem(index);
        }
    }
}

Hope this helps,

Diego

Beth Massi on Entity Framework + WPF

divega — Mon, 20 Jul 2009 19:23:21 GMT

I haven’t met Beth in person but I noticed her awesome blog posts and videos focused on using Entity Framework with WPF. Very useful stuff!

Rowan on Entity Framework Events and Alex’s Tips

divega — Tue, 07 Jul 2009 22:30:17 GMT

I don’t post much on my blog lately (too busy working on Entity Framework for .NET 4!), but this post from my teammate Rowan struck me as something that would help lots of customers, so I wanted to link to it. It explains basically everything you need to know about events available in the Object Services API of Entity Framework.

While I am here, the tips series in my other teammate Alex James’ blog probably don’t need much publicity from me, but they are an awesome resource for customers.

Third post about POCO, first post about Code Only

divega — Thu, 11 Jun 2009 01:28:53 GMT

It is always busy here with all the improvements we are doing in Entity Framework to make your code work better with it. That is why I haven’t been posting to my blog much in the last months. Today however, there are two important posts from people that sit very close to me, so I am going to link to them.

Faisal posted the third part in a series on the POCO experience with EF4. His post delves into the details of how snapshot change tracking compares with notification based change tracking and on some of the API considerations for it.

Alex, who sits in my office (although he likes to think I sit in his :)) made the first post about the Code Only experience we are working on. I like to think of Code Only as “POCO on steroids”, because it not only gives you the right level of decoupling between your domain classes and the persistence framework, but it also puts mapping artifacts out of the way. I am especially fond of the way you can customize mapping using LINQ queries, although that feature is not going to be included in the first preview.

Please go read the posts, play with the bits (you will need to wait a few weeks to play with code-only) and tell us what you think!

Server queries and identity resolution

divega — Wed, 25 Feb 2009 00:02:29 GMT

I answered a Connect issue today that deals with a very common expectation for users of systems like Entity Framework and LINQ to SQL. The issue was something like this:

When I run a query, I expect entities that I have added to the context and that are still not saved but match the predicate of the query to show up in the results.

Reality is that Entity Framework queries are always server queries: all queries, LINQ or Entity SQL based, are translated to the database server’s native query language and then evaluated exclusively on the server.

Note: LINQ to SQL actually relaxes this principle in two ways:

1. Identity-based queries are resolved against the local identity map. For instance, the following query shall not hit the data store:

var c = context.Customers
.Where(c => c.CustomerID == "ALFKI");

2. The outermost projection of the query is evaluated on the client. For instance, the following query will create a server query that projects CustomerID and will invoke a client-side WriteLineAndReturn method as code iterates through results:

var q = context.Customers
.Select(c => WriteLineAndReturn(c.CustomerID));

But this does not affect the behavior explained in this post.

In sum, Entity Framework does not include a client-side or hybrid query processor.

MergeOption and Identity resolution

There are chances that you have seen unsaved modifications in entities included in the results of queries. This is due to the fact that for tracked queries (i.e. if the query’s MergeOption is set to a value different from NoTracking) Entity Framework performs “identity resolution”.

The process can be simply explained like this:

The identity of each incoming entity is determined by building the corresponding EntityKey.
The ObjectStateManager is looked up for an entity already present that has a matching EntityKey.
If an entity with the same identity is already being tracked, the data coming from the server and the data already in the state manager are merged according to the MergeOption of the query.
In the default case, MergeOption is AppendOnly, which means that the data of the entity in the state manager is left intact and is returned as part of the query results.

However, membership of an entity in the results of a given query is decided exclusively based on the state existing on the server. In this example, for instance, what will the query get?:

var customer1 = Customer.CreateCustomer(1, "Tiger");    
var customer2 = Customer.CreateCustomer(2, "Zombie");     
context.SaveChanges();     
customer1.LastName = "Zebra";     
var customer3 = Customer.CreateCustomer(100, "Zorro");     
context.AddObject("Customers", customer3);     
context.DeleteObject(customer2);     
var customerQuery = context.Customers     
    .Where(c => c.LastName.StartsWith("Z"));     
foreach(var customer in customerQuery)     
{     
    if (customer == customer1)     
    {     
        Console.WriteLine(c.LastName);     
    }     
}

The answer is:

The modified entity customer1 won’t show up in the query because its LastName is still Tiger on the database.
The deleted entity customer2 will be returned by the query, although it is a deleted entity already, because it still exists in the database.
The new entity customer3 won’t make it, because it only exists in the local ObjectStateManager and not in the database.

This behavior is by design and you need to be aware of it when writing your application.

Put in some other way, if the units of work in your application follow a pattern in which they query first, then make modifications to entities and finally save them, discrepancies between query results and the contents of the ObjectSateManager cannot be observed.

But as soon as queries are interleaved with modifications there is a chance that the server won’t contain an entity that exist in the state manager only and that that would match the predicate of the query. Those entities won’t be returned as part of the query.

Notice that the chances that this happens has to do with how long lived is the Unit of Work in your application (i.e. how much does it take from the initial query to the call to SaveChanges).

Hope this helps,
Diego

EntityDataSource and Bind: What are those square brackets?

divega — Mon, 02 Feb 2009 09:25:44 GMT

This post is about a small issue that I have seen in the forums and that arises often in cases in which EntityDataSource is used in combination with bound controls that use templates, like FormsView or a GridView with template based columns.

If you can create your page correctly, simply using the different drag & drop features and context menus provided by the design surface. However, in the end, some Bind expressions will get enclosed in square brackets that produce compile or run-time errors, then your code may look like this:

<EditItemTemplate>    
    <asp:DropDownList ID="CategoryDropDownList" runat="server"     
        DataSourceID="CategoryDataSource"     
        DataTextField="CategoryName"     
        DataValueField="CategoryID"     
        SelectedValue='<%# Bind("[Category.CategoryID]") %>'>     
    </asp:DropDownList>     
</EditItemTemplate> 

This annoyance may keep you blocked until you realize how simple the workaround is: just remove the square brackets!

People that watched my video here, may have noticed that I had to remove the square brackets manually around minute 8:10. I wish I had blogged about it then, but it wasn’t clear at the time I recorded that video that the issue would still be there in the RTM version.

Here is a short explanation:

In order to adapt entity objects that do not have foreign key properties to work better with ASP.NET databinding, we decided to wrap each entity returned with a databinding wrapper object that, among other things, flattens the members of EntityKeys in related entities (for more details on how and why the EntityDataSource returns wrapped entities you can go here).

The name of flattened reference keys are usually composed by the corresponding navigation property, plus the name of the property in the related end. For instance, in a Product, the key of the associated Category, will be exposed as “Category.CategoryID”. We decided to use dots to delimit the parts of the name because that plays well and is consistent with the use of dots in most programming languages, and also in Eval expressions, like the one used in the following code:

<ItemTemplate>    
    <asp:Label ID="CategoryLabel" runat="server"  
        Text='<%# Eval("Category.CategoryName") %>'>     
    </asp:Label>     
</ItemTemplate> 

The problem is that for the particular case of Bind (often used in template based databound controls to perform two-way databinding) the design time component of ASP.NET will catch property names that contain dots, and it will try to escape them by surrounding them with square brackets (leading to ta Bind expression of the form “[Categories.CategoryID]”).

Unfortunately, the rest of the ASP.NET components which need to evaluate the binding expression are actually not capable of parsing the square brackets escaping notation (i.e. for DataBinder.Eval() the brackets actually indicate that a lookup in an indexed property is necessary, and there is no indexed property in this case).

Given that the EntityDataSource in fact exposes property descriptors that contain dots in their names, the escaping is unnecessary. So, next time you find this issue, just remove the square brackets.

The good news is that the issue will be fixed in the next release.

Hope this helps!

Exposing EDM and database server functions to LINQ

divega — Thu, 09 Oct 2008 06:36:23 GMT

Alex published today a description Colin and I wrote on a new feature the team has been working on for LINQ to Entities.

Beyond all technicalities, it is a very simple and attribute-based way of exposing any arbitrary server-side function to LINQ. It goes beyond what LINQ to SQL does with SqlMethods and it leverages our metadata system so that you don't have to specify the full mapping of parameters in the attribute.

The post itself may be a little boring ;), but the scenarios it enables are quite impressive.

Quick tips for Entity Framework Databinding

divega — Thu, 09 Oct 2008 06:26:15 GMT

One of our customers asked this question yesterday on the Entity Framework forums. There were a few details missing and so I am not completely sure I got the question right. But I think it is about an issue I have heard quite a bit, and so I think it may be useful to share my answer here for others.

Given this simple line of code (i.e. in a WinForms application):

grid.DataSource = someQuery;

Several things will happening under the hood:

Databinding finds that ObjectQuery<T> implements the IListSource interface, then it calls IListSource.GetList() on it, to obtain a binding list (an internal object that implements IBindingList and some other well-known interfaces that databound controls know how to communicate with)
GetList() gets the query executed and it copies the contents of the resulting ObjectResult object to the binding list
The new binding list is finally passed to the databound control

When a binding list is created this way from a tracked query (i.e. MergeOption in the query is set to anything but NoTracking), there are several other interesting details in the behavior:

Changes made to entities in the binding list will get noticed by the state manger. Therefore changes will be saved to the database when SaveChanges is invoked on the tracking ObjectContext
Additions of new entities to the context will not result in the new entities being added automatically to a binding list (this is a common expectation). Whether an entity belongs to a binding list is decided at the time the binding list is created. If we wanted to do something different (i.e. have the binding list get new objects added to the context automatically), we would hit some considerable obstacles:
- The binding list does not remember which filter condition was used in the query.
- Even if it did, our queries are server queries, expressed in either ESQL or LINQ, but always translated to server queries and then expressed in terms of the current values on the server.
- Even for LINQ queries, we cannot assume that the same query will have equivalent behavior while querying in-memory objects when compared to the same query translated to the native SQL of the database.
As a consequence of #2: You can have multiple binding lists based on the same EntitySet with overlapping or disjoint sets of entities. You can use different queries (or even from the same query, but with different parameters) to get a different set of entities in each binding list.
Deletion of entities from the context will result in the deleted entity being removed from all binding lists that contain it. The principle behind this is that the binding list is a window into the "current state of affairs" in the state manager. Even if we don't know if a new entity belongs into a binding list, we do know when it doesn't belong anymore, because it has been deleted.
A binding list has its own Add() method you can use. If you could get a reference to one of our binding lists you could “manually” add new entities to the binding list, and the entity you add will also be added to the context automatically, the same as if it had invoked AddObject() on the context.

All these facts, especially #5, warrant me to give you a couple of tips:

If you are interested in getting a reference to the binding list directly (i.e. to use its Add method), you can do something like this:
var bindingList = ((IListSource)query).GetList() as IBindingList;
There is a more convenient ToBindingList() extension method included in the EFExtensions you may want to take a look at.
If you are not interested in getting the reference to the binding list for yourself, and you are using databinding directly against a query as in the sample at the top of this post, you should know that WinForms will call IListSource.GetList() twice, causing the query to be executed on the server twice! The recommendation then is to bind to the results, rather than the query, using code similar to this:
grid.DataSource = someQuery.Execute(MergeOption.AppendOnly);
In this case, since the resulting ObjectResult acts as a foward-only, enumerate-once cursor, its implementation of IListSource.GetList() is different from the one in the query: the call will consume the results (i.e. it will iterate through the whole results) and will cache the binding list in the ObjectResult instance. All subsequent calls to IListSource.GetList() will return the same binding list.

We have a few ideas around things we may improve in future versions. Some of them you may be able to guess from this explanation. But I will save that for another post...

Jarek publishes his excellent Entity Framework POCO Adapter

divega — Tue, 09 Sep 2008 20:50:06 GMT

I have been back from vacation for some time but I haven't had time to post anything (i.e. I was on vacation the day Entity Framework went RTM in .NET 3.5 SP1!).

Finally, something happened that I cannot wait to talk about.

Jarek and I went discussing how persistence ignorant classes could be supported by building a layer on top of the EF v1 API for a long time.

He finally figured out a good way to do it. The result is this sample that wraps Entity Framework APIs and uses simple code-generation to create "adapters" and "proxies" for your POCO classes:

Entity Framework POCO Adapter

You can read Jarek's blog post explaining it all.

We hope people will find it interesting and will send useful feedback that can help us improve the core product.

Sample Entity Framework Provider for Oracle now Available

divega — Tue, 24 Jun 2008 03:03:22 GMT

This new sample builds on top of System.Data.OracleClient and showcases some techniques a provider writer targeting databases different from SQL Server can use.

The code is not meant for production, just a sample directed to provider writers. It has also a few limitations related both to SP1 beta bits and with types not supported in OracleClient.

For more details, read Jarek's post.

You can download the source code from our home page in Code Gallery.

Entity Framework Sample Provider Updated for SP1 Beta

divega — Tue, 03 Jun 2008 20:18:29 GMT

Just to get the news out: The updated version of the Entity Framework Sample Provider that is compatible with .NET 3.5 SP1 Beta is now available in our Code Gallery page. From the description:

The Sample Provider wraps System.Data.SqlClient and demonstrates the new functionality an ADO.NET Provider needs to implement in order to support the ADO.NET Entity Framework

Provider Manifest

EDM Mapping for Schema Information

SQL Generation

Update: for more details on provider API changes since the Beta3 release, you can read Jarek's post here.

EntityDataSource's flattening of complex type properties

divega — Sat, 24 May 2008 20:11:40 GMT

I explained a few days ago the rules of wrapping in this blog post. But why do we wrap after all?

Julie asked for some details today in the forums. I think the answer is worth of a blog post.

In ASP.NET there are different ways of specifying which property a databound control binds to: Eval() Bind(), BoundField.DataField, ListControl.DataTextField, etc. In general, they behave differently.

The flattening we did on EntityDataSource is an attempt to make the properties that are exposed by EDM entities available for 2-way databinding in most of those cases.

For instance, for a customer that has a complex property of type Address, we provide a property descriptor for customer.Address, and also for customer.Address.Street, customer.Address.Number, etc.

At runtime, in the case of a control binding to Eval(“Address.Street”) from a customer, Eval will use the property descriptor corresponding to Address, and it will drill down on it to extract the value of the Street property on it.

A grid column of a BoundField derived type with DataField = “Address.Street” will work differently: it will just look for a property descriptor in the data item with a name as “Address.Street”. In fact, EntityDataSource is the first DataSource control that I know off that will provide such a thing.

Bind(“Address.Street”) will work in a similar fashion to Eval() when reading the properties into the data bound control, but will act a little bit more like BoundField when sending back changes to the DataSource.

There are a few cases in which the behavior is not any of the above and hence you end up with a control that cannot have access to a complex type’s properties. You can expect us to work closely with the ASP.NET team in making the experience smoother in future versions. But for the time being, what you can do is create an explicit projection of the properties. For instance, in Entity SQL:

SELECT c.ContactId, c.Address.Street AS Street
FROM Northwind.Customers AS c

I think it is worthy of mentioning:

Remember flattening of complex properties only happen under certain conditions (see wrapping).
We worked very closely with the ASP.NET Dynamic Data in this release, to enable their technology to work EDM through the EntityDataSource. I think it is very worthy of trying.

Hope this helps.

Entity Framework Extensions Project Update

divega — Wed, 14 May 2008 05:10:47 GMT

Just a couple of links:

Colin posted a refresh today today that is compatible with .NET 3.5 SP1 Beta and includes some optimizations for the materializer using dynamic methods. Here is his post about it.