Ayende @ Rahien

cowgaR commented on Why Defer Loading in Entity Framework isn’t going to work

Fri, 17 Jul 2009 02:07:06 GMT

ok been through all the discussion and my head is going Ka-Boom right now at 3:55am :) @Karl, the EF isn't allowing you to expose IEnumerable on navigational properties but you can have ICollection

Mark commented on Why Defer Loading in Entity Framework isn’t going to work

Fri, 19 Jun 2009 09:52:32 GMT

Whilst I kind of agree with some of the points raised here I can't but help this is unproductive. Hammett has joined Microsoft to try and help build a better product, his knowledge and effort will be a benefit for MS and its users. I can't help but think that picking holes in EF, wihich is a new framework (thus a little immature) and at the same time saying "EF doesn't work, nHIbernate does" is destructive. Having had to use nHibernate I can see it has plenty of downsides too, but have I got a blog whining about it ? no. If everyone tried to work together we'd see much more progress.

karl commented on Why Defer Loading in Entity Framework isn’t going to work

Tue, 02 Jun 2009 12:39:00 GMT

@Dinesh: Maybe my idea of "Controls Development" is wrong, but what stake do you possibly have in an O/R framework? And just because *YOU* aren't able to apply DDD, doesn't mean that the Entity Framework should impose non-DDD patterns. What Ayende is suggesting would allow me to build it the way I want (using IEnumerable where appropriate), and others to do it the way they want (always using List). Through lack of foresight or understanding, the EF won't let me expose IEnumerable (well, not without a lot of pain) - this is a mistake because it violates sound class design principles - which ironically is likely the main market that EF is targeted at.

Dinesh Gajjar commented on Why Defer Loading in Entity Framework isn’t going to work

Tue, 02 Jun 2009 03:33:40 GMT

@Ayende : I did not mean to insult anyone. Just that I am amazed by the politics of things here. I apologize if it's personal. @Karl that's your opinion and it's not universal. It all depends on type of development you do. I do "controls development" and no matter how hard I am trying, I am unable to apply DDD to it.

Karl commented on Why Defer Loading in Entity Framework isn’t going to work

Mon, 01 Jun 2009 17:07:30 GMT

I'm interested to see how it works. I completely see both points of view. Even I think Ayende's example is poor. However, I do think that -The NH team has more experience with how these things actually turn out in production, and I'd automatically be drawn to their concerns. -There are plenty of cases where you do want to access the underlying field directly. The best example, already given, is if your property is exposed as IEnumerable. In fact, change Ayende's example from List

Ayende Rahien commented on Why Defer Loading in Entity Framework isn’t going to work

Mon, 01 Jun 2009 11:00:26 GMT

Dinesh, Please try to be at least somewhat accurate. I have worked on a few dozens production applications, including some pretty big & interesting ones. I don't work in vacuum, and frankly, I find your accusations insulting.

Dinesh Gajjar commented on Why Defer Loading in Entity Framework isn’t going to work

Mon, 01 Jun 2009 09:40:07 GMT

I went through all the comments. Look on NH Side who is defending Frans Bouma - Who sells his own closed Source LLBLGen. Eager to attack anything that comes out of MS because his business is threatened! Ayende Rahien - Making money on nHibernate coaching and Tools. How many sites or production applications have you really worked?? He desperately wants Microsoft to adopt nHibernate so his business booms. EF is not a mature product either! So guys do youself a favor and don't believe either Microsoft or nHibernate gurus. Do your own reasearch. This blog is nothing more then a publishing blurb. Don't fall in publicity stunts.

Dmitry commented on Why Defer Loading in Entity Framework isn’t going to work

Sun, 31 May 2009 20:32:28 GMT

I agree with what Frans is saying. There are certainly multiple approaches in how to deal with such scenarios. _In my opinion_ in the object oriented world a developer would expect to have the whole collection in memory when they see IList/ISet/ICollection return types. Otherwise, there would be an IQueryable/IEnumerable return type for the collection. In order to perform queries orders efficiently there should be a way to do this: bool hasOrders = orderRepository.Any(o => o.OrderDate.Year == 2008) EF (by the default convention) uses repositories that are IQueryable properties in the context instance.

Gunnar Liljas commented on Why Defer Loading in Entity Framework isn’t going to work

Sun, 31 May 2009 19:44:39 GMT

Don't know if I think that this is informative, or just yet another example of Ayende the Whiner taking a piss at someone else's efforts. I guess it's both. Constructivity points deducted though. Too bad, since constructive criticism of EF is indeed needed.

Frans Bouma commented on Why Defer Loading in Entity Framework isn’t going to work

Sun, 31 May 2009 10:30:40 GMT

@Stefan: Looking at the code of re-linq, are you afraid of comments? ;) @Ayende: The 'Count' property access on: int numberOfOrders = c.Orders.Count; which will result in the # of orders... it's debatable if this should be a scalar query without fetching the orders. The thing is: if c.Orders is fetched already fetched, it will do it in-memory without refetching, if it's not fetched, aren't you asking for things to be ran in-memory as if c.Orders was already initialized with data? (I'm not saying you should look at this all the time, I just want to give a different PoV on this). It's the same as: should c.Orders always contain _ALL_ the orders of the customer in 'c', or can you also load for example its last 10 orders in c.Orders? Some will say: "noo!! you should always load all orders, as that's what it represents!" and they do have a point, while others will say: "I don't need all 1000 orders, for this particular scope I need just the last 10 orders and I load them into that property so I can consume that graph in this particular piece of code", and they also have a point. I.o.w.: it's not black-white what to do. For example: bool hasOrdersIn2008 = c.Orders.Any(o=]o.OrderDate.Year==2008); one could argue: if you can do 'Count' in the db, why not this simple EXISTS query as well? I'm not saying you should, I just can imagine that someone could say: "indeed, that's what I want". Of course there are workarounds for this, but it's about what the developer thinks is happening vs. what does happen. That aside: lazy loading is something that's misused in a lot of scenario's often by developers who have no clue what they're doing. You can limit that a bit with optimizations like the one you described with Count, however, that's not covering the many cases a developer can still accidentally fetch large buckets of data to read just 1 property. Just because intellisense says they can. ;)

Ayende Rahien commented on Why Defer Loading in Entity Framework isn’t going to work

Sun, 31 May 2009 05:25:10 GMT

Dmitry, Because when you load the object from the database, it _should_ be initialized. And I don't want IList to act as IQueryable. I want the ORM to have reasonable default for good OO behavior with regards to performance. It really bothers me that EF is _closing off_ those options.

Dmitry commented on Why Defer Loading in Entity Framework isn’t going to work

Sat, 30 May 2009 20:34:55 GMT

@Ayende, Why is it a problem to get an exception when the list is not initialized? That's what happens in .NET. And why would you want IList to act as IQueryable? That is code magic (in a bad way) to me.

Peter Morris commented on Why Defer Loading in Entity Framework isn’t going to work

Sat, 30 May 2009 16:55:06 GMT

I didn't find your example of using the private List

Ayende Rahien commented on Why Defer Loading in Entity Framework isn’t going to work

Sat, 30 May 2009 14:35:55 GMT

Peter, It is actually quite common for me to expose collections as IEnumerable, and only provide an add method on the owner class

Ayende Rahien commented on Why Defer Loading in Entity Framework isn’t going to work

Sat, 30 May 2009 14:32:46 GMT

Dmitry, See my previous example on how you _won't_ get an error with NH. And lazy loading and queries are two totally different subjects.

Ayende Rahien commented on Why Defer Loading in Entity Framework isn’t going to work

Sat, 30 May 2009 14:31:54 GMT

David, I like your use of unfounded. Please check my history with ORM and tell me how unfounded I am. EF _cannot_ handle the Count. Now if the property type of List

Peter Morris commented on Why Defer Loading in Entity Framework isn’t going to work

Sat, 30 May 2009 10:08:40 GMT

@Ayende I didn't try to find a more complex example, I tried to find a more realistic one, it just happens to be more complicated. Personally I have never done something like _products.Add(p); I always use the property for access. I added my example because 1: I think a number of people might think "That's silly, I wouldn't do that!" 2: There was a more subtle case (which I outlined) which can bite you without you thinking about it. It certainly wasn't obvious to me from the start why we couldn't only make the state properties virtual. Regards Pete

Stefan Wenig commented on Why Defer Loading in Entity Framework isn’t going to work

Sat, 30 May 2009 06:25:31 GMT

@Fabio there's a download link at [http://www.re-motion.org/](http://www.re-motion.org/) it's quite large (re-motion is almost the size of NH), but don't let that turn you off. Remotion.Data.Linq.dll is what you need. We can remove the few dependencies from re-linq and provide a neat little assembly you can ilmerge into NH. We'll post some instructions for using the query model in a few weeks, when the current refactorings are complete and we have something stable enough to write about. If you _really_ want to waste some time, here's an initial proof-of-concept prototype we made a few weeks ago: [svn.re-motion.org/.../NHibernate.ReLinq/](https://svn.re-motion.org/svn/Remotion-Contrib/trunk/NHibernate.ReLinq/) However, this code abuses our SQL emitter to create HQL strings, which is obviously not an option when we want to generate an HQL AST. The new provider will build directly on the QueryModel, but for that you're going to have to wait for us to finish the tasks I outlined above.

Fabio Maulo commented on Why Defer Loading in Entity Framework isn’t going to work

Sat, 30 May 2009 05:29:31 GMT

@Stefan where is the download of re-linq ?

Dmitry commented on Why Defer Loading in Entity Framework isn’t going to work

Sat, 30 May 2009 03:14:10 GMT

I don't see the problem with NullReferenceException thrown if you do not initialize the collection. It would do the same thing without any proxies unless you expose the setter and initialize it yourself which is a bad practice in my opinion. Lazy collection loading can be done by querying the context/repository and returning IQueryable

David Nelson commented on Why Defer Loading in Entity Framework isn’t going to work

Sat, 30 May 2009 02:52:27 GMT

Frankly, none of this post makes any sense. You are making a lot of unfounded claims about the way EF is going to have to handle certain scenarios, with no evidence at all of why that would have to be the case. For example, given that EF is proxying the List property, there is no reason why accessing the Count property will have to load the entire collection; it could instead simply execute the required SQL (which, I believe, is exactly what NHibernate does). Nor do I see the "all too many cases" that will require eager loading, simply because the property is virtual. Your category class is ridiculous; of course if you design a class that accesses a field without initializing it, a NRE will be thrown! What else would you expect? There is nothing about the design of EF that requires you to write your classes in such an inane way. Also, as has already been mentioned, using the factory methods is not required. It seems like, once again, you are tilting at windmills from Redmond.

Ayende Rahien commented on Why Defer Loading in Entity Framework isn’t going to work

Fri, 29 May 2009 22:02:16 GMT

Peter, Why try to find a complex example? This is a very simple one that shows the issue.

Stefan Wenig commented on Why Defer Loading in Entity Framework isn’t going to work

Fri, 29 May 2009 21:25:28 GMT

@Dmitry: no, it's about the difference between a programmer overriding a method and therefore creating an obstacle to change for the original library, and a tool overriding it in some generic manner and adapting to any changes automatically. @Frans: I've been wondering what your 100-part LINQ DIY blog series was about - helping out the competition or just scaring them away ;-) @Ayende: Why do they call it defer loading? While MS never really had a consistent ORM story for more than a few months, the one thing they were consistent about is that they think that lazy loading is evil. Maybe avoiding the term made it easier for them?

Frans Bouma commented on Why Defer Loading in Entity Framework isn’t going to work

Fri, 29 May 2009 18:44:28 GMT

@Stefan: heh :) Of course, with re-linq it might be less than a few months. I was talking about 'here's the tree, this is what you should be emitting, fill the gap' kind of start, which takes alot longer. If re-linq can get this project going it would be great. That might sound strange coming from me, but we too benefit from this, with v3 which will support nhibernate as well (and has a feature to design queries and emit them as linq queries, so it would be great to have linq support from the get go ;))

Dmitry commented on Why Defer Loading in Entity Framework isn’t going to work

Fri, 29 May 2009 18:42:25 GMT

@Chris, You would be able to use "sealed" keyword to prevent overriding methods. The intellisense should be able to to recognize non-sealed methods without any issues. It is just an opt-in/opt-on issue.

Steve Strong commented on Why Defer Loading in Entity Framework isn’t going to work

Fri, 29 May 2009 18:39:01 GMT

As Stefan said, I'm currently on hols, and "bandwidth limited" - but I'd say that Stefan's summary is pretty close to the mark. Thanks, Stefan, saved me a load of typing on my iPhone :)

Chris commented on Why Defer Loading in Entity Framework isn’t going to work

Fri, 29 May 2009 17:06:36 GMT

@Stefan You're right its an excellent discussion and I can see the reasons for and against. I agree with you - it comes down to control and documentation. If everything was virtual how would I know what methods Im supposed to be override (plus there can be no way I could guarantee that you wont chnage core functionality by overriding sensitive methods IYKWIM). Also this discussion always winds up the Java boys....and thats gotta be good no :)

Stefan Wenig commented on Why Defer Loading in Entity Framework isn’t going to work

Fri, 29 May 2009 16:48:42 GMT

@Chris that's an interesting point, and I tried to discuss this with Anders at last year's lang.net. My personal view is that a static override should only be possible if the developer allows for that, for exactly the reasons that Anders usually gives (which is that this changes the interface of the class and needs to be supported later - I didn't read your link but that's what he always says) But for dynamically generated overloads (code gen) this should not be true. This follows the same reasoning as reflection: statically referencing a private member is evil, but if you only access private members that you discover dynamically, the orginal class remains free to change. Generic serializers are a good example. The same should be true for subclass proxies, which would support any interception framework for AOP or (my pet topic) mixins. Anders' response was basically, "so if you take a step back, what you really want is a way to dynamically modify any behavior?" Fair enough, only that we're not going to get anything to enable this, even in .NET 4.0. There's some talk about vNext, but we'll have to wait and see. Maybe the EntLib and EF teams should have pushed the CLR team for an interception infrastructure instead of partial methods...

Chris commented on Why Defer Loading in Entity Framework isn’t going to work

Fri, 29 May 2009 16:26:43 GMT

"t is not just because we think everything should be virtual (it should, but that is not a discussion for now)" mmmmm not sure about that....Im going to have to agree with Anders Hejlsberg on this point [http://www.artima.com/intv/nonvirtual.html](http://www.artima.com/intv/nonvirtual.html)

Tom Pester commented on Why Defer Loading in Entity Framework isn’t going to work

Fri, 29 May 2009 16:06:05 GMT

Thank you very much for the update Stefan