POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

POCO in the Entity Framework : Part 2 ??? Complex Types, Deferred Loading and Explicit Loading | ASP NET Hosting

Thu, 28 May 2009 19:26:40 GMT

PingBack from http://asp-net-hosting.simplynetdev.com/poco-in-the-entity-framework-part-2-%e2%80%93-complex-types-deferred-loading-and-explicit-loading/

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

Peter Goodman — Fri, 29 May 2009 01:33:03 GMT

There is an issue in NHibernate dynamic proxies with inheritance. Lets say we have a Customer entity which references an Account entity, Account can be SavingsAccount or ChequeAccount via Inheritance.

When following the lazily-loaded Account association, the actual target type cannot be determined easily as the proxy is subclassing the Account entity type instead of the actual Account type (Savings or Cheque) so a standard "is" will not work.

Has this been considered?

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

Karl — Fri, 29 May 2009 02:35:19 GMT

@Peter: You might have missed:

2 - You cannot use inheritance with your complex type classes

Why Defer Loading in Entity Framework isn

Ayende @ Rahien — Fri, 29 May 2009 03:04:43 GMT

Why Defer Loading in Entity Framework isn

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

joe — Fri, 29 May 2009 03:36:04 GMT

IPOCO still makes me chortle.

Just out of curiosity, why are you guys calling it "deferred loading", when the rest of the world has settled on "lazy" (and his holiness the Reverend Martin Fowler even formalized the pattern name)? Is there a subtle difference in the two?

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

divega@microsoft.com — Fri, 29 May 2009 09:32:40 GMT

@Joe,

There is actually no subtle conceptual difference between "deferred loading" and "lazy loading". Deferred and lazy are being used as synonyms. The main reason we tend to use deferred internally and in the documentation is that the name of the API that you use to turn it on and off is “DeferredLoadingEnabled”.

This flag was named like that after the homologous flag in LINQ to SQL, which has had this feature since .NET 3.5.

I can assure you we are listening to the feedback on this.

Thanks,

Diego

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

Mike Scott — Fri, 29 May 2009 13:59:07 GMT

+1 for calling it by the established name, lazy loading.

In case you missed Ayende's post, have you considered the valid issues he raises here:

http://ayende.com/Blog/archive/2009/05/29/why-defer-loading-in-entity-framework-isnrsquot-going-to-work.aspx

This road has already been followed by NHibernate and found to lead to a dead end. Please consider the points Ayende raises.

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

Imran — Fri, 29 May 2009 15:19:35 GMT

Is inheritance support planned for a future release? Lack of inheritence support would be quite limiting in DDD scenarios. If inheritance is not supported the entity model will not be as 'rich' and the need for a complex persistence framework is somewhat reduced. This might limit the use of entity framework to only trivial applications.

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

simon.segal — Fri, 29 May 2009 15:26:01 GMT

Faisal

What is the behaviour when I mix and match .Includes() with context.ContextOptions.DeferredLoadingEnabled = true ? Will the eager and lazy fetching work independently across the single ObjectContext in the same query?

Thanks,

Simon

POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

progg.ru — Fri, 29 May 2009 17:45:30 GMT

Thank you for submitting this cool story - Trackback from progg.ru

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

sergejus — Fri, 29 May 2009 19:21:26 GMT

I have actually a question on statement:

"In order to enable creation of proxy instances for adding/attaching, you can use the CreateObject factory method on ObjectContext for creating entity instances"

I've successfully newed POCO with all properties declared as virtual just with new operator. Context.AddObject worked for me like a charm!

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

Hemanshu Bhojak — Fri, 29 May 2009 23:07:06 GMT

Persistence ignorance means you can switch your persistence layer from EF to something else without affecting your model. But what the EF proposes for using with POCO is all contrary to PI. First it wants me to create a model from the DB and it imposes rules like marking a property virtual to achieve lazy loading. This may not be favorably to my model. I guess MS is going all in the wrong direction.

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

divega@microsoft.com — Sat, 30 May 2009 00:38:52 GMT

@Peter and Karl,

We don't support inheritance of complex types, but I think Peter is referring to entity types, for which we support inheritance.

On the other side, I am not sure I understand Peter’s question correctly, so I am just going to try to explain how inheritance interacts with proxies:

Let’s say you have Account and SavingsAccount and ChequeAccount that derive from it. EF can create proxy types for all the concrete types of the hierarchy. For instance, let’s assume that Account is abstract, then it will create SavingsAccount’ and ChequeAccount’.

SavingsAccount’ is a SavingAccount and an Account, since it derives from SavingsAccount. ChequeAccount’ is a ChequeAccount and an Account, since it derives from ChequeAccount.

Now, let’s assume that Account is not abstract. Then EF can also create a proxy type for Account, Account’.

In the case you have two instances of Account’ and SavingsAccount’, if you try to establish if the type of the first instance is assignable from the type of the other instance, the answer will be no. They both derive from a common root, but they are on different branches of the inheritance tree.

Thanks,

Diego

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

divega@microsoft.com — Sat, 30 May 2009 01:05:06 GMT

@Hemanshu,

EF in .NET 4.0 works with pure POCO objects, using a snapshot based change detection mechanism.

It is true that in Visual Studio 2008 you could only create the model from the database or start with a model from scratch. But the EDM designer in Visual Studio 2010 also supports creating the database schema from your model.

In that case, you can have non-virtual properties and use the new keyword to get new instance.

If you specify properties as virtual we can subclass your entity types and provide with services that you probably wouldn’t want to code yourself inside your entities (precisely because they need to use the persistence infrastructure).

Even in that case, we support object graphs that are a mix of proxies and non-proxies: objects that came from server queries, objects that you instantiated yourself using new or the CreateObject<T> factory method, can be connected, and we will use a mix of snapshot and notification based change tracking.

Lazy loading is an interesting example because it means that navigation properties in your model acquire query capabilities, which clearly belong inthe persistence infraestructure.

If you had to write that code yourself, you would need to somehow invoke the persistence framework from inside your entity.

I would like to understand what your expectations are. How would you get lazy loading to work and still preserve persistence ignorance of your code without something like a proxy?

Thanks,

Diego

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

divega@microsoft.com — Sat, 30 May 2009 01:14:54 GMT

@sergejus,

Glad to hear that non-proxy POCO objects work like a charm for you :). Change trackig proxies optimize the change tracking mechanism by enabling change notifications and removing the need to do a snapshot comparison to detect whether an entity has been modified. But regular POCO entities work as well, even mixed with proxies in the same object graph.

The overhead of detecting changes using snapshot is not that big in many scenarios.

Thanks,

Diego

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

divega@microsoft.com — Sat, 30 May 2009 01:19:17 GMT

@Simon.Segal

Yes, eager loading and lazy loading can be mixed in the same context. You specify eager loading at the ObjectQuery level using Include and lazy loading at the ObjectContext level. Eager loading will load all the requiered paths in a single shot and you can continue loading from there lazyly as you navigate your object graph.

Thanks,

Diego

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

Jason — Sat, 30 May 2009 16:59:45 GMT

Thank you for adding the lambda expression support for LoadProperty! L2S made great use of generics instead of strings which not only provides type-safety, but allows easy refactoring.

ADO.NET team blog : POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

9eFish — Sun, 31 May 2009 06:09:10 GMT

9efish.感谢你的文章 - Trackback from 9eFish

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

Hemanshu Bhojak — Sun, 31 May 2009 21:16:55 GMT

I have an existing model and want to provide lazy loading for a child. Is it possible to do that without marking it virtual.

I am currently using proxy objects to do the same.

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

divega@microsoft.com — Mon, 01 Jun 2009 08:33:48 GMT

@Hemanshu, what kind of proxy object are you using now? In Entity Framework, proxy objects derive from the original POCO class and therefore require proerties to be virtual in order to override their behavior and enable things like lazy loading.

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

Hemanshu Bhojak — Mon, 01 Jun 2009 09:00:18 GMT

For all the children (IList) I attach a proxy IList which uses the lazy load pattern to provide deferred loading...

New and Notable 325

Sam Gentile's Blog (if (DeveloperTask == Communication && OS == Windows) — Mon, 01 Jun 2009 19:32:51 GMT

ASP.NET/ASP.NET AJAX/ASP.NET MVC/jQuery Creating a Simple .NET 4.0 Web App using Visual Studio 2010 ScottGu's May 30 Links: ASP.NET, ASP.NET MVC, Visual Studio Oslo About the "Oslo" May 2009 CTP Channel 9 - Chris Sells: On the History of DevCon,

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

Taz — Tue, 02 Jun 2009 07:03:56 GMT

Here is an example of the issue Peter mentioned, I have also run into this with NHibernate.

class Customer

{

public virtual Account Account { get; set; }

...

}

class Account { ... }

class SavingsAccount : Account { ... }

class CheckingAccount : Account { ... }

...

if (customer.Account is SavingsAccount)

{

// This won't work with defered loading, the proxy will have already subclassed the Account type

}

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

Marcelo — Tue, 02 Jun 2009 10:42:37 GMT

Can you, please, write a complete sample of generic repository and unit of work together, using EF.4.0

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

Phillip Smith — Fri, 05 Jun 2009 10:05:54 GMT

I too need a complete repository and unit of work example covering all CRUD operations using EF.4.0

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

Phillip Smith — Mon, 08 Jun 2009 14:09:15 GMT

Can you map enumerated properties to string fields in the EF model?

Daily tech links for .net and related technologies - June 9, 2009

Sanjeev Agarwal — Tue, 09 Jun 2009 13:23:28 GMT

Daily tech links for .net and related technologies - June 9, 2009 Web Development A view from the cloud

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

chris seed — Tue, 09 Jun 2009 15:29:27 GMT

Taz,

For NHibernate: if your modify your domain model so that each domain entity implements an appropriate interface and then change your if statement to something like

if (customer.Account is ISavingsAccount)

then you'll find it works.

Does a similar approach work for the EF?

POCO in the Entity Framework : Part 3 – Change Tracking with POCO

ADO.NET team blog — Wed, 10 Jun 2009 18:43:06 GMT

In my last post on POCO , I mentioned the fact that there are two types of change tracking possibilities

POCO in the Entity Framework : Part 3 – Change Tracking with POCO

VS2010学习 — Thu, 11 Jun 2009 08:19:40 GMT

In my last post on POCO , I mentioned the fact that there are two types of change tracking possibilities

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

Muhammad Mosa — Thu, 11 Jun 2009 11:55:52 GMT

Is it possible to use Include method to define preloading with POCO classes?

Using Repository and Unit of Work patterns with Entity Framework 4.0

ADO.NET team blog — Wed, 17 Jun 2009 02:08:49 GMT

If you have been watching this blog, you know that I have been discussing the various aspects of POCO

Using Repository and Unit of Work patterns with Entity Framework 4.0

VS2010学习 — Thu, 18 Jun 2009 08:16:11 GMT

If you have been watching this blog, you know that I have been discussing the various aspects of POCO

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

Nilotpal Das — Tue, 07 Jul 2009 22:06:30 GMT

Why is inheritance not allowed with complex types in Entity Framework .Net 4.0? What I would like to know is what is the design intent behind such a constraint?

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

englishnewbie — Fri, 17 Jul 2009 01:20:58 GMT

<i>You need to only use CreateObject when dealing with proxy based entities.</>

I am not an english speaker, so can you elaborate on this one?

e.g. when creating new product inside context, say:

using ctx {

Product p = new Product () { Name = peugeot, Description = French brand car...};

}

later on I'll save it to DB. When do I need to use createObject instead of newing up an object?

sorry for my english, but please be more verbose on this. EFv4 looks awesome !!!

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

radyo dinle — Sun, 19 Jul 2009 17:37:37 GMT

For all the children (IList) I attach a proxy IList which uses the lazy load pattern to provide deferred loading...

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

Muhammad Mosa — Tue, 11 Aug 2009 19:43:26 GMT

Regarding using ObjectContext.CreateObject<T> I noticed that i can get same effect by normal instantiation using new!

Why should I consider using CreateObject when creating POCO instances that will be used with EF 4?

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

Muhammad Mosa — Tue, 11 Aug 2009 19:54:30 GMT

Ok I figured out something, CreateObject must be used with Proxy Enabled classes in instantiation. But Even without using it I was able to use AddObject method. The only difference I noticed is that after saving when modifying the object the entity state doesn't change.

Any justification and more clarification on this point?

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

matt — Tue, 01 Sep 2009 08:00:15 GMT

I am wondering how the "deferred" loading works with WCF-like applications? I probably would not want this enabled for SOA/WCF type applications, correct?

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

michel — Sun, 13 Sep 2009 19:39:02 GMT

Hi,

I am trying this in a WCF context.

All works fine, but only if the Products list in Category is not virtual?

Also if I query for all Categories and Include their Products, Products fails to serizalize due to the Category parent property, cyclic problem?

Am I missing something here?

kr,

Michel

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

matt — Sat, 03 Oct 2009 23:28:49 GMT

It looks like there is no "silver" bullet to kill the werewolf! ORM? Hmmm, the debate continues. Which one to use, etc.? It really boils down to writing some "data access" code, doesn't it? EF has its place for sure - but not as the "defacto" standard on how to build data-driven applications.

The mapping is always the issue here. Remember when programmers wrote code instead of using "code generation". I'm not saying don't use code generation, I use it in every project; the trick is kowing when to use and when not to.

This post: http://ayende.com/Blog/archive/2009/05/29/why-defer-loading-in-entity-framework-isnrsquot-going-to-work.aspx HAS REALLY GOT SOME PEOPLE THINKING.

Thinking is good!

re: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

Jujiswa — Thu, 03 Dec 2009 08:12:26 GMT

Your Article is based on Beta 1 and is therefore complete outdated. Poco-generation works completely different now. You should not waste peoples time and mark this article with Beta 1.