http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660@Brian Chavez Why? nHibernate don’t have proper support for Linq (example join). Don’t tell to use HQL that don’t have support for strongly typed (intellisense) @Ayende any plans for linq to nhibernate 2 which won’t use Criteria API? http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment53http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment53Thu, 26 Nov 2009 21:51:25 GMTMicrosoft needs to dump EF and just use NHibernate. http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment52http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment52Mon, 19 Oct 2009 06:15:43 GMT@Mark QUOTE Although EF is still in its infancy... UNQUOTE Microsoft have been talking about EF and writing articles about it since 2006. That makes it a technology in its "Toddleracy" at the very least! Title: Visual Studio 2005 Technical ArticlesThe ADO.NET Entity Framework Overview Date: (June 2006) link: [http://msdn.microsoft.com/en-us/library/aa697427](http://msdn.microsoft.com/en-us/library/aa697427)(VS.80).aspx http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment51http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment51Thu, 15 Oct 2009 13:01:49 GMT@Frank - I can't really explain in depth as this is not the place for it.. but basically the object model has relations that force the loading of child/parent data. We are fixed in to having to return data against this model, so eager loading loads many related objects, even when you don't need the data from them. Lazy loading is not possible via ActiveRecord on one to many relationships, so thats out. The one to many relations can be lazy loaded, but this causes excessive server roundtrips. With EF I would be able to define an entityset that only includes the data Im interested in, whilst not disturned the overall model. http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment50http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment50Thu, 15 Oct 2009 10:13:33 GMTFrans, You are probably aware that I am not overly impressed with repositories. The issue isn't eager loading evil or not. The issue is that if you don't have lazy loading as well, you model is broken when you try to touch the parts that weren't eagerly loaded. There are situations where it is actually MORE efficent to page things using lazy loading than any other way. http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment49http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment49Thu, 15 Oct 2009 09:40:30 GMTCare to elaborate why NHibernate is causing performance problems with loading data and how EF will solve that? http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment48http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment48Thu, 15 Oct 2009 09:08:44 GMTFunny how its ok to slam EF but when anyone criticises nHibernate they're wrong. Although EF is still in its infancy I can see it being far better for the nHibernate application I am working on which currently has many performance problems with loading data - both eager and lazy loading. http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment47http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment47Thu, 15 Oct 2009 08:18:10 GMT"Having a model that force ONLY eager loading is evil. " I don't see that. Eager loading is a way to tell the o/r mapper to load what you want and pass back the graph to the caller so the code in the caller doesn't have the chance to touch the DB. That's essential in code which uses repositories: any object returned from a repository which supports lazy loading _bypasses_ the repository of the element that's lazy loaded. In fact, I'll go as far as that with a puristic DDD implementation, there's no lazy loading nor is there eager loading, simply because all related entities are always loaded through their repositories: the orders of a customer are read by the order repository, not by touching the Orders property on a customer instance. I have read 'evil' a couple of times now here, but no-one has given even the slightest argument why. So let's give that one, shall we? Eager loading is 'evil' _if_ the eager loading system is not allowing you to define the exact graph in detail, as the 'evil' part comes from the fact that you will load data you don't need. That _might_ be inefficient, but in practice, that's just BS in a lot of cases, simply because the DB engine has read these rows anyway. A solid eager loading system can load related entities with 1 query per graph node. that's much more efficient than lazy loading. Lazy loading is also 'evil', namely in the situation where you need to load a lot of related elements which cause a lot of queries, which could have serious impact on the performance as well. So calling one 'evil' over the other is really stupid, as both aren't evil all the time, they're only evil in some situations, namely, the situation where their downsides are noticeable. I know I've been a big fan of lazy loading as well, however as I built a solid eager loading system later, I understood it's not all black and white: both are less-optimal versions of what's really required: a custom projection of a joined set. I'll point to an old blog by Matt Warren, one of the Linq to sql developers. It's about spans in objectspaces. the blog talks about the pro's and cons of lazy loading and eager loading (spans). If you scroll down you'll read a reaction from me from 2004 which supports your PoV. But as I said, eager loading is IMHO not evil, it's just not always the best choice, so is lazy loading (SELECT N+1 problem comes to mind): [blogs.msdn.com/.../90275.aspx](http://blogs.msdn.com/mattwar/archive/2004/03/15/90275.aspx)http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment46http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment46Thu, 15 Oct 2009 07:47:48 GMTResharper! *smacks forehead* For the particular architecture you're talking about, your solution is absolutely correct. It's a disconnected service layer providing "completely loaded" data as per the service contract. Lazy loading starts to really shine and make more sense in architectures that are more stateful... where there are no explicit service boundaries... where the domain layer is much more interactive all the way up. A lot of things all of a sudden start to fall into place. You can now take advantage of contextful lazy loading, sorting, paging, etc. Whether I agree with lazy loading being default on an ORM, I'm not too sure. It's almost like saying paging should be there by default. http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment45http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment45Thu, 15 Oct 2009 01:27:07 GMTThilak Nathen, R# = Resharper [QUOTE]Evict (Detach) the object from the session from your service layer and you won't get that nasty exception.[/QUOTE] As you said, this doesnt fix the problem; it just stops the errors from coming up. The fix is just to not lazy load. http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment44http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment44Thu, 15 Oct 2009 00:11:53 GMTFrank, To be clear, when I say client I am not meaning UI. The client is just means the client machine. My domain model is what is loaded through NHibernate and what I ship back and forth between the client and the service layer. However, the domain model is never pushed into the UI layer. To me the client is a physical layer that is composed of 2 logical layers; the presentation layer (view models & presenter) and the UI layer (controls aka. views). The presenter invokes the service layer, gets a domain object, pushes it into a stateful store, and then maps aspects of the domain model into view models that are tailored for databinding on the UI. The translation from domain model -> view model is where lazy loading can really sting you. So a solution is to introduce a 3rd type of model that has no connection with NHibernate, and you use just to ship the aggregate root across the wire but what does that buy you? At this point im fighting with a tool that is supposed to be helping me. The alternate solution is to never lazy load any collections and have a fine tuned aggregate root that doesnt kill the system when its loaded/flushed. I am sorry if I am hijacking this thread, but I really want to make it clear that lazy loading, in some contexts, is not a great idea. http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment43http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment43Thu, 15 Oct 2009 00:05:03 GMT"You are better off making a honest string out of that column name, at least that way tools like R# can track it" Excuse my ignorance, What is R#? I went on a small wild goose chase googling it with no apparent result. http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment42http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment42Wed, 14 Oct 2009 23:53:27 GMTP, "If i hit a lazy loaded portion of my root while creating my presentation model its all over." Evict (Detach) the object from the session from your service layer and you won't get that nasty exception. But that still doesn't solve the problem of the data for the property not being loaded. :) http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment41http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment41Wed, 14 Oct 2009 23:46:07 GMT"...but I apply somewhat the same strategy even when using DataSets..." Ouch!!!! I feel your pain brother! http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment40http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment40Wed, 14 Oct 2009 23:38:54 GMTWe are probably misunderstanding each other. I can certainly agree with your decision to return the complete aggregate when you ask the business tier for it. In my case, I would probably go with a domain model which stays in my business tier and cannot be directly accessed by the UI tier. For presentation purposes I would have DTOs that represent the complete aggregate. When the UI tier asks for it, I would start a session (or datacontext, etc.), then retrieve the actual domain model entity, convert it to the DTOs, and end the session. That way you won't be bothered by lazy loading or whatsoever in the UI tier. For executing commands on the business tier, like updating the complete aggregate, I would use about the same steps. (Re)using the DTOs from UI to business tier, start a session, update the actual domain model entity with data from the DTOs (or whatever exciting business case you might execute), flush the session, and close it. In both cases I can leave lazy loading at it's default, and where possible, based on some hard facts, decide where to actually default to eager loading. I hope this all made sense. And if people have better ideas, or think differently about this, I would love to hear. I'm all for new ideas to improve my own applications. PS: At my current company, we are unfortunately not using OR/Ms, but I apply somewhat the same strategy even when using DataSets and when the application logic (business tier and data tier) must be centrally located. The rest of my thoughts is based on playing around with NHibernate, LINQ to SQL and such. So, don't consider me to be a big expert on the subject. http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment39http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment39Wed, 14 Oct 2009 22:00:02 GMTFrank, [QUOTE]P, in my opinion that is bad design. You are using your domain model for UI purposes. That will get you into trouble anyways if your business tier and data tier are deployed separately.[/QUOTE] The application has a rather large aggregate root that is brought down to the client. There is a series of presentation models that are all mapped to different UI components, and each presentation model represents a specific chunk of the aggregate root. After hitting about 10-15 different UI pieces in a wizard like fashion, the aggregate root is flushed to the service boundary and where a unit of work is wrapped around persisting the root and executing commands against the root. I am not sure why this is bad design? We chose to optimize for a single call to the service boundary and build all of our presentation models from this, rather then call the service boundary 15 times when a user is taken to the next phase of the wizard. The problem is creating the presentation models from the root. If i hit a lazy loaded portion of my root while creating my presentation model its all over. Please tell me why this is bad design? Please tell me why in every scenario, lazy loading is always better. I wish I had never played devils advocate because now there is going to be endless claims about how bad my example is without actually having any context. +1 Ayende for the default setting I didnt know about +1 Frans for saying what I was trying to say, but better http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment38http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment38Wed, 14 Oct 2009 21:02:20 GMTEF in .net 4.0 is going to be pretty nice, but not perfect. I think people will have to weigh the benefit of integrating nHibernate into a new/existing solution and having to potentially write plumbing code...or get EF "as is" (the bad and good) and have it work automagically with Microsoft's other ADO.NET-type middleware/services. http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment37http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment37Wed, 14 Oct 2009 19:45:21 GMT"Having lazy loading enabled can introduce bugs into your application. In a 3 tier winforms scenario, you jump to an application service to load your domain object, jump back to the client and hit a lazy loaded collection and now im trying to execute a query on a workstation that doesnt even know about a database." P, in my opinion that is bad design. You are using your domain model for UI purposes. That will get you into trouble anyways if your business tier and data tier are deployed separately. Best design practice in my opinion is to map queries to special DTO's for displaying purposes. And send commands to your business tier, which will actually use your domain model with lazy loading. Since - at least in my applications - most commands to the business tier only operate on one aggregate (for example order, with order lines, delivery settings, etc.), lazy loading will be perfect. Looking at it from that perspective, then NHibernate does the correct thing. Lazy loading by default. http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment36http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment36Wed, 14 Oct 2009 18:56:01 GMTBut it does not force eager loading unless you are talking about local properties that come from the same table/view. In fact the only way to force eager loading is through the Include (prefetch) extension method in LINQ or do a similar thing in ESQL. http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment35http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment35Wed, 14 Oct 2009 18:25:48 GMTI agree fully that forcing eager loading is VERY EVIL. It'll just kill off any application in production, especially web one. Lazy loading is actually the best default you can use and the most failsafe method, as it does not torture your data bandwidth with all that data you don't need. However, in EFv1 I missed lazy loading the most. Magic strings and having to know how database is structured and type all those table names? - Horror! Smart LINQ 2 SQL lazy loading model is soooo ftw. Eager loading is evil. http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment34http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment34Wed, 14 Oct 2009 17:45:32 GMT@Alex James I haven't finished all the comments, but you really need to make sure that any example you post on the EF site is written properly. This has long been an issue with Microsoft (just look at the horrible WCF documentation for example). There are plenty of developers who read posts that come from the mothership as gospel, so you owe it to them to only produce quality examples. I'm sick of hearing developers say "But I built it just like Microsoft said!" when trying to example why something crashed and burned. http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment33http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment33Wed, 14 Oct 2009 17:25:27 GMTLukeB - I understand what you are saying now. Frans, [QUOTE]Eager loading of data into a model doesn't mean you load everything, you still tell the db what to load. So I'm a little curious why you point to eager loading as something utterly evil.[/QUOTE] This was my thought exactly. http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment32http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment32Wed, 14 Oct 2009 17:24:23 GMTFrans, Having a model that force ONLY eager loading is evil. http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment31http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment31Wed, 14 Oct 2009 17:00:30 GMTWith a proper way to load things eagerly (e.g. with proper prefetch paths which allow you to filter, sort etc.) eager loading isn't that performance intensive. The thing with lazy loading is that it allows developers to bypass repositories, or a service, and for example allow a GUI developer to cut corners and use lazy loading to fetch data. Eager loading of data into a model doesn't mean you load everything, you still tell the db what to load. So I'm a little curious why you point to eager loading as something utterly evil. http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment30http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment30Wed, 14 Oct 2009 16:54:31 GMTp - the problem is that the client is receiving *entities*, and not DTOs. http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment29http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment29Wed, 14 Oct 2009 16:52:39 GMTDmitry, This is totally broken, then. http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment28http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment28Wed, 14 Oct 2009 16:43:54 GMTA huge problem with this explicit loading is if the data context is shared across multiple functions (say inside an MVC controller), a query can produce different results based on whether the association was loaded or not inside previous methods calls. I totally agree that the model is broken. http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment27http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment27Wed, 14 Oct 2009 16:43:03 GMT@Oren, This is exactly how EF v1 works and the default behavior of the data context in v4. You can enable lazy-loading and proxies manually in the constructor by extending the data context class. But if you do that, you need to be responsible to make sure everything is virtual or you will get strange behavior silently. It does not through exceptions like NHibernate but rather defaults to snapshot/explicit loading behavior. Dmitry http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment26http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment26Wed, 14 Oct 2009 16:40:43 GMTOur service boundary is our UoW. http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment25http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment25Wed, 14 Oct 2009 16:18:45 GMT"In a 3 tier winforms scenario, you jump to an application service to load your domain object, jump back to the client and hit a lazy loaded collection and now im trying to execute a query on a workstation that doesnt even know about a database." You're sending entities over a service boundary and thus outside of your UoW. Most often a very bad decision. http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment24http://ayende.com/4246/what-is-up-with-the-entity-framework-vnext#comment24Wed, 14 Oct 2009 16:16:21 GMT