Try out www.llblgen.com. Does everything entity framework does AND MORE, including Linq and lazy loading...Also, BEST support of any product anywhere, period.

Personally, I'm committed to writing a book on Entity Framework and have already written a lot of pages already, so I'll have to stick with it. Thanks for the suggestion though.

I'm just kidding, Wayne.

EF is a different type of framework. But EF is for working with an entity data model, not directly with a database. You might want to check out this post by Zlatko Michailov on the EF team:

http://blogs.msdn.com/esql/archive/2007/12/14/EntityFramework_5F00_ORM.aspx

Generally speaking, unless they want to get the advantage of the modelling that EDM supports, fans of tools like LLBLGen and nHibernate are not going to be keen on EF in its current iteration.

Julie,

Hopefully, Jeremy, Timothy and you will find this experimental project interesting:

http://blogs.msdn.com/diego/archive/2008/05/12/lazy-loading-in-entity-framework.aspx

I would recommend you to give it a try :)

-Diego

Timothy Khouri's solution to modify the EDM Designer's generated code is excellent; check the IsLoaded property, if it's false, then call Load() on the EntityCollection<T>. However, while making all of those individual modifications would be quick and trivial, the machine-generated EDM designer csharp (or vb) file contains this warning at the top:

//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
// Runtime Version:2.0.50727.1433
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------

So any change to your model through the designer will end up rewriting the whole file, and the additions to support lazy loading will be lost. Unless there is some tool to automatically modify the machine generated code, perhaps using regular expressions to find and modify all of the public properties of type EntityCollection<T>, making changes to the model are going to be very painful.

This is the first comment I've left on any EF related blog, though for many months I have been reading Julie's blogs daily, as well as meek, ScottGu, Mike Taulty, Diego, and many others. It seems that EF is under a lot of criticism regarding the lack of lazy loading, and that the potential user base wants it included as an option out of the box. We can all appreciate the reasons for wanting absolute control over when trips to the database are made, but if our main concern were really absolute control over everything, we probably wouldn't be programming in automatic-memory-managed languages.

Timothy Khouri mentioned that for many, as soon as they realize that EF doesn't support lazy loading, they immediately stop considering it as an option. LLBLGEN, NHibernate, LINQ to SQL; all of these have excellent implicit lazy loading. Given that just a FEW lines of code (as illustrated by Timothy Khouri) can implement implicit lazy loading, why not make it a designer supported option? It's a feature that would please the majority of potential EF users, and that would be very easily implemented. I feel like if it were easier for the potential user base to communicate with the EF development team, it would become more apparent that forcing explicit loading is probably not the best decision.

-Sam

Hi Sam. Good thought about implemeting the option for Lazy Loading.

WRT the additional code being overwritten, the code-gen'd classes fo rthe model are partial classes, so all of the extra logic can be housed in separate files.

Just in case (I don't like to presume) here is a link to the MSDN Partial Classes topic for C#
[http://msdn.microsoft.com/en-us/library/wa80x488(VS.80).aspx]

and a linke to the MSDN topic for VB
[http://msdn.microsoft.com/en-us/library/yfzd5350.aspx]

I wish partial classes would solve the problem, but Timothy Khouri's solution isn't adding NEW public properties to the class -- it's modifying existing ones by adding a call to Load() when (IsLoaded == false) for the EntityCollection<T> or EntityReference<T> public property getters. In a separate file that has the other half of a partial class's definition, I can't declare a public property that has the same name as a public property in the other file. You'll get the error:

The type '[ClassName]' already contains a definition for '[PropertyName]'

And it isn't like inheritance where I can hide the base class implementation with the "new" keyword or anything. If I wanted to have a separate file that contained my implicit-lazy-loading-enabled EntityCollection<T> and EntityReference<T> properties, then I would have to go through the machine-generated designer.cs file and delete those properties to avoid naming conflicts.

Well, Sam. The joke's on me! I wrote my reply in between doing a lot of things, had not spent a lot of time looking at Timothy's solution and had no idea that you had such a good understanding of EF. (And probably didn't need the explanations of Partial Classes). I will ping Timothy and ask him to look at this thread and respond.

First of all, I have to say that I didn't pay Sam to use my full name so much, but I'm totally Googleable now!!! (just kidding). I personally think that EF will have the option in the future (most likely not for this launch).

Also, it's important to note that you can build a custom exe to re-format the auto-generated code upon site build (I'll probably show how to do that in an article soon)...

I'll be visiting MS next week, and I'll see if I can talk to EF guys (and gals) to see what they think of this approach, or if they have better ideas (more than likely the case).

On a side point: I went to the Sarasota Dev user group meeting yesterday (a talk on the Entity Framework and LINQ by John Papa), and your name (Julie) got brought up a lot (only good things were said)... including your upcoming book, and your "Golden Rule" (which I informed him that it's not the "Platinum Rule").

More to come on this subject I'm sure :)