All posts in ADO.Net Entity Framework

Those of you that are interested in EF probably know by now by now that if you wanted to start playing around the new features of EF like POCO entities, Self tracking Entities and Code Only EF, you had to download and install EF4FeatureCTP2.exe.

Unfortunately the second CTP which was released last November, the update for Visual Studio 2010, was released without the POCO Template (the new code generation mechanism for EF relies on T4 mechanism) and raised a lot of debate and comments from developers.  Last week though the EF Team announced the Entity Framework POCO Template update for Visual Studio 2010 Beta 2, you can download the C# version here and the Visual Basic version here.

Besides being compatible with Beta 2, the new template includes a number of bug fixes, generated code improvements, handling of relationship fixup that includes support for Foreign Keys in the Model (see more details here about this new feature of Entity Framework) and compatibility with change tracking POCO Proxies and ObservableCollection<T>.

The POCO Template is not going to be part of Visual Studio 2010 in RTM. Instead the team’s plan is to continue to deliver updates for it through the Extension Manager and the Visual Studio Gallery.


One of the great advantages offered by Entity Framework compared to Linq to SQL is the fact that it is designed to support any database not just MS SQL. All you need to have in order to connect to third party databases is the right ADO.NET provider.

Unfortunately till recently there were no implementations of such providers. Devart (formerly Core Lab) though, has released a new version of their ADO.NET providers, which includes support for the Entity Framework.

So with DevArt’s new ADO.NET providers you’ll be able to connect to Oracle, MySQL, and Postgress using Entity Framework.


I’ve been working and am a huge supporter of Microsoft’s Entity Framework. That doesn’t mean that I haven’t found issues that prevented me from tackling requirements of the day to day challenges faced when building real-world applications and services. I always thought that if only I had the chance to communicate and exchange ideas with the guys behind it, in the early stages of the Framework’s development process, most of the issues would be solved and I wouldn’t have to face those issues. Well I guess I wasn’t the only one that had that idea…

Today, the EF group guys announced that they’re starting the engineering and opening up their design process for the second version of the framework.

… we would like to enable folks that are interested in Entity Framework version 2 to follow the design topics as we discuss them, and have the opportunity to provide feedback right during the time where we are actively discussing a certain aspect and before we have made a final decision.

Great news, way to go guys, the idea only of being able to contribute in a Microsoft product is exciting. So if you’re interested in helping design V2 of Entity Framework subscribe to http://blogs.msdn.com/efdesign.


I don’t know how deep you’ve gone with entity framework and if you’ve given any thought on advance enterprise issues, like caching for example, yet. Diving in it though and trying to use it in an enterprise wise project gave me the opportunity to start thinking on these kind of issues. So how can you cache using EF? I won’t go into much detail about the type of Cache as this is not what this post is about so I’m just going to assume that Cache is some kind of memory based storage that I’m planning to use. You can see what a graphical representation of what I want in the following short video.

Generally what anyone would expect as caching support from EF is the ability to put EntityObjects in some kind of Cache and retrieve them next time you need them, instead of going back to the DB and get them every time. Well you can actually go ahead and do just that. Of course, you’ll first have to detach the EntityObject,  from its current context to avoid an exception when you use it with a different one, and then put it on your Cache. Note that you’re actually caching a reference to the object and not the object it self.

Let’s assume now that you want to get back the object you cached and use it in another context that you’ve created. What you normally would do is take back the reference you’ve cached and attach the referenced object to the newly created context and work with it normally. Can you see the problem with this scenario? …

The keyword of this problem is “Reference”. Since you’re storing references to your cache, multiple threads will have access to the same EntityObject right? So attaching the referenced object to a thread’s Context may very well cause another to crash (Exception is thrown when you try to re-attach an EntityObject that’s already been attached to another context) as the object will be already attached.

You might argue that that’s not really a problem cause you could design a smart, thread safe Cache, that locked on the EntityObject reference before returning it, thus forbidding all other threads from accessing it for as long as it’s in use. Well, the problem with this solution is that if a thread gets an EntityObject reference from the Cache and doesn’t release it soon, then it will block all other threads that need the same object basically taking away all of the advantages of actually having a Cache.

You could resolve the locking problem by making copies of the referenced by the Cache objects and return those prior to attaching them to some context, then there’s no need for locking, as each context will have its own version of the EntityObject. But lets examine what copy actually means. Since there’s no member wise clone method available for EntityObjects, you’d have to make the copies yourself by using reflection or some other technique. You would of course, have to copy not only the primitive properties of the object but the Navigational (Relationship) ones as well by going into all the child objects and copying those too and so forth till you’ve exhausted all the object graph. Argghhh… this is a road I wouldn’t take…

There’s though a work around, that some have found convenient, in order to make copies without going into the trouble of doing a member wise clone. Since EntityObjects are serializable, they serialize the whole object graph, then copy the stream and de-serialize it back, to construct a copy of it. Although this is better than member wise cloning the objects, performance wise it’s very slow and surely unacceptable for a large Enterprise applications.

In my opinion the optimal solution is to store and return references of objects in Cache and avoid copies as much as possible. As for the the EntityObject status issues (Unchanged, detached,…etc.) that were discussed earlier you will just have to take two decisions and stick with those:

1. All objects in the Cache are read only. This means that you’ll never attach them again to a context (except for updating them in which case read the second decision) but instead always use them as detached.

2. When you need to modify a cached object you’ll have to lock on the reference so that other threads will wait till the modification is finished. This lock though is different from the one discussed earlier and something that you would do in any case since you wouldn’t want multiple threads modifying the same resource.

Although this seams to do the trick, it certainly breaks the programming model of EF. So you won’t be able to do Object1.Children and get the child related objects of the Object1 Entity object if they’re cached. You’ll instead have to fetch them from the cache and use them as detached.

Things are slightly better as far as windows forms applications are concerned, as the DataContext can be kept alive (don’t worry about the db connection, this is closed and opened as needed) for as long as the application running, playing the role of the Cache by keeping all instantiated objects alive. Unfortunately DataContext is not Tread Safe thus ruling this solution out from using it like that in a Web application.


IMGP0002 If you had only had tine for just one Session in this year’s TechEd then I would definitely recommend Mike Taulty’s one on Linq to Entities (is going to be repeated on Friday). If you didn’t make it this year then I would suggest watching its replay at The virtual side as soon as it comes available.

It’s not just the subject (which is interesting as it is), it’s also the fact that he’s a great speaker, one that speaks with a lot of examples and demos and avoids lengthy power point presentations. I was lucky to see him on two sessions today, Linq to XML and Linq to Entities, although the second one was packed full and had to wait till some people left to get in.

IMGP0003 I also had the chance to attend Pablo Castro’s project Astoria presentation which was also great. His enthusiastic presentation on project Astoria renewed my interest on the project and plan to have another look once back home.

 

Having lunch today at the top floor of the exhibition center revealed the great view the exhibition center has to the ocean and got me thinking how great it would be if we could get the chance of hosting TechEd at Greece. After all the 2004 Olympic games left us with an infrastructure that can be utilized for such events (like the Taekwon-Do center which is planned to be converted into a convention center) and we certainly could use all the Tourism and advertisement this event would bring to Greece.

IMGP0006 Stitch

Today is also the Greek delegates party, we’re going to eat and have drinks at Red Lounge somewhere in Barcelonita. Let’s hope that food there’s going to be better from what I’ve eaten lately ;-). Barcelona’s cuisine constitutes mainly of fish which is not my greatest food.


I’ve been following ADO.NET Entity Framework for over a year now and the truth is I was bit surprised when DLinq was released. From the initial look at things – it seemed as though the ADO.NET EF folks and the LINQ to SQL folks were operating in completely isolated environments – each producing their own copy of a wheel but with very different attributes, benefits, and even target audiences.

From what I’ve been reading lately though I came to understand that that isn’t the case. The ADO.NET Entity Framework has a different scope than LINQ to SQL. The ADOEF is responsible for three things:

  • mapping a database schema to a model,
  • creating a model
  • allowing eSQL queries against that model.

Combined with Linq, which allows you to run LINQ queries against in-memory structures, you are free to issue LINQ queries against the generated ADOEF classes.

Furthermore with ADOEF you also have features like

  • Entity inheritance – DLinq derived classes have a 1:1 table mapping structure. You get one class per table. EF on the other hand lets you create entities like Customer and EliteCustomer and SuperEliteCustomer that allow you to maintain progressively more information in the object model while still using the same normalized back-end relational store.
  • Entity composition – You can have a single EF entity that is composed of data retrieved from multiple locations within the relational store. For example, you can have a single object that has properties that originated in 3 different tables.
  • Composed Entity Updates Using EF, you can actually insert or update a single entity that originated from 3 different tables. If you modify three properties that originated from 3 different tables, then when the EF does an update for that data, it will issue 3 different queries. This is impossible to do in DLinq alone. The best you can do is manually create a transaction, manually add rows to 3 tables, and then call update. In short, EF preserves the object-oriented view of the data whereas the DLinq object-oriented view does half of that.
  • Change schema – if you make a change to the schema in the underlying database in simple DLinq, you need to re-generate the classes, potentially screwing up any customizations you made to those classes. With EF, all you need to do is change the mapping specification and you can leave the Entity Data Model (EDM) completely untouched.

From the looks of it ADOEF combined with Linq promises to be the foundation of an extremely powerful persistence and business object framework.