2

So I've been getting this feeling that I should turn off lazy loading, for two reasons:

  1. queries become non-atomic, so could result in concurrency errors.
  2. me or another programmer could end up causing a huge performance impediment.

Of course, both of these problems can be avoided as long as we're careful, but it seems a bit of an unnecessary risk in projects where performance is somewhat important.

As a side note, I found it weird that 1-* relationship properties become null rather than throwing an exception when you access them with lazy loading off. I want to go back and do everything in single queries, but I'm worried that I might overlook a bug where I'm interpreting a not-yet-loaded 0-* relationship as being null.

Thoughts?

Rei Miyasaka
  • 6,796
  • 5
  • 37
  • 65

1 Answers1

8

Turn off lazy loading if your worried about performance, if you're not, don't.

Personally, we turn off lazy loading, and explicitly allow the inclusion of navigational properties via the interface contract for our repositories, e.g:

ICollection<Person> FindSingle(int personId, string[] includeAssociations);

So we then eager-load the navigational properties ONLY if the calling code specifically asks for it. It's like saying to the code: "Hey, if you want extra information about this T, then ASK for it, otherwise you ain't gettin it!".

As for the 1-*, of course the properties are null. Navigational properties are generally implemented as ICollection<T> on the objects, so if there is nothing there, a collection isn't instantiated.

You could counteract this effect by creating an empty collection, rather than a null one when you execute your queries. However, i prefer a null collection to an instantiated one with 0 items.

RPM1984
  • 69,608
  • 55
  • 212
  • 331
  • That's an awesome idea, passing in the includes as a string[]. Regarding the null references, I actually meant 1-0 relations, that is, a reference to zero or one object. I think those can be ambiguous. Thanks! – Rei Miyasaka Nov 02 '10 at 12:18
  • 1
    No worries. Also, with the includes - you can add a bit of type-safety to the normally hardcoded `.Include` code, by passing an array of `enum` instead of strings. Then create a extension method for that enum which converts the enum to a `.Include` string. This is what we do. So our code looks like: `repository.FindSingle(1, PersonAssociations.Orders)`. Just a bonus tip, free of charge :) – RPM1984 Nov 02 '10 at 20:35
  • Aye, I was thinking that, but I find myself being lazy about it because EF will throw an exception if you give it an incorrect argument anyway. – Rei Miyasaka Nov 02 '10 at 23:46
  • 1
    more of a reason to use enums. if you pass in `repository.FindSingle(1, "Orderz")` (note typo), it will die very late (ef exception). whereas if you have enums, you can avoid this (i throw custom exceptions before i attempt to do any db-work). anyway, it was just a tip. happy ef-ing! :) – RPM1984 Nov 02 '10 at 23:57
  • I've never heard of anyone who preferred a null reference to an empty collection. It seems crazy to me... by using an empty collection, you simplify code a lot by assuming that it can never be null. Every recommendation I've seem and every library uses the empty collection approach because it is much more robust. [Related post](http://stackoverflow.com/questions/1969993/is-it-better-to-return-null-or-empty-collection). – julealgon Feb 11 '15 at 19:39