Question

I’ve been using LINQ to SQL for a number of years in an ASP.Net environment. The UI and BLL tiers were separated by a web service, so lazy loading, change tracking, etc were not an option. It was nice in a way because we knew exactly what was going on in the code – we were responsible for persisting changes in the BLL (figuring out if an entity was new/updated), and there were no unexpected surprises due to some lazy-loading going on somewhere.

I’ve now moved jobs and working on a new desktop system (WPF). There are no boundaries, i.e. the UI tier will directly call the BLL (but see caveat at end). I’m looking to use EF5, but I’m a bit overwhelmed by the number of features, options, etc. that EF provides. I’m hoping I can get answer to a few questions…

1. Should lazy loading be used across boundaries? Let’s say I wanted to display a customer and all their orders, would the UI request just the customer from the BLL, then use lazy loading to access its orders? Doing this in the UI doesn’t feel right to me. I’m assuming lazy loading is just something you would use in the BLL.

2. I believe you can turn off lazy loading using DbContext.Configuration.LazyLoadingEnabled, but what if I wanted to use lazy loading in my BLL, but when I return the entity(s) to my UI I don’t want the UI from doing any lazy loading?

3. What about change tracking, self-tracking entities and POCOs? What should I use when? It was never an issue for me when I worked with LINQ to SQL (it was across a web service, and ASP.Net so there was no “state”, therefore change tracking was irrelevant). I feel like I want to deactivate it all (which is what I’m used to), but I’m afraid that I’ll be missing out on some of the EF “goodness”. I think I’m worried about not being in control of persisting data.

4. As I’ve been playing around and retrieving data using EF, I’ve noticed in some of the entity hierarchies that some of the property collections (E.g. customer.Orders) contains “proxy” entities. What are these and when would they be useful?

5. Again I’ve noticed you can turn proxies off via DbContext.Configuration.ProxyCreationEnabled, but the documentation suggests there’s more to it than that, and some kind of relationship with the LazyLoadingEnabled setting?

6. EF “code first” seems to be gaining in popularity. What does it give you? I’m used to designing my database in SSMS, not writing lots of classes, annotations, etc!

A final caveat – although the app’s UI tier is directly calling methods in the BLL, there’s a small chance that in the future we might want to separate them (E.g. via a web service). How would this affect design considerations, and some of the questions that I’ve raised above?

Apologies for bundling a number of questions together. If I can get answers to them all then hopefully this will be useful for others in my situation in the future.

Answer 1

1. In my opinion lazy loading is designed to be used in the UI layer and not in the BLL. It is especially useful in data binding scenarios, for example in a master-details view. If you have a list of customers in your UI and by clicking on a customer the user can display the customer’s orders those orders could be loaded by lazy loading. Since you don’t know in advance which customers the user will click you would be forced otherwise to load all orders of all customers up-front if you don’t want to use lazy loading (or implement your own event-driven child loading mechanism). This would create unnecessary overhead.

   On the other side I can’t see why lazy loading in the BLL would be interesting. Normally you know which data have to loaded to perform a specific business logic. When you know it you can use eager or explicit loading. It’s one or two lines more code to write than just accessing a navigation property and rely on lazy loading but with eager and explicit loading it is clear what your code does and when the database gets accessed.

   Keep in mind of course that lazy loading needs a context that hasn’t been disposed so you must design the BLL in a way that the context lives as long as your UI (or parts of the UI) are used.

2. If you don’t want lazy loading in the UI layer turn it off and use eager and explicit loading in the BLL. You cannot turn off lazy loading once you have loaded entities with lazy loading enabled.

3. Self-tracking entities are deprecated or at least the EF team suggests to not use them anymore in new projects (second reference: http://msdn.microsoft.com/en-us/data/jj613668). They also suggest to not use EntityObject derived entities anymore. So, POCOs are definitely the way to go.

   Change tracking itself is a core feature of EF and available also for POCOs in two different forms: As “snapshot based” change tracking and with change tracking proxies. The default is snapshot based change tracking. Change tracking proxies can be used to improve performance in certain scenarios – especially when thousands of entities are involved and need to be updated in a single context. More about change tracking proxies is here: http://blog.oneunicorn.com/2011/12/05/should-you-use-entity-framework-change-tracking-proxies/

4. EF creates proxies from POCO entities if lazy loading or dynamic change tracking is enabled. They are dynamic objects derived from your entity classes and needed to make lazy loading and dynamic change tracking (= not snapshot based) possible.

5. Setting ProxyCreationEnabled to false disables any proxy creation – for dynamic change tracking and for lazy loading as well. The setting of LazyLoadingEnabled doesn’t matter anymore if proxy creation is off. More details are here: https://stackoverflow.com/a/7112470/270591

6. If you feel more comfortable with a database first approach then use it. It is equally well supported as code-first or model-first and – as an EDMX based approach – has even a few more advanced features that code-first does not have. More details about the different strategies are here: https://stackoverflow.com/a/5446587/270591

…although the app’s UI tier is directly calling methods in the BLL,
there’s a small chance that in the future we might want to separate
them (E.g. via a web service). How would this affect design
considerations, and some of the questions that I’ve raised above?

You would not be able to use lazy loading in the UI layer anymore because you cannot pass a context instance through a web service boundary. Lazy loading will become as useless as it is in web applications where the UI is the (disconnected) remote browser. You will also lose the comfort of change tracking attached entities. Building change sets for disconnected entities and object graphs is more difficult than leveraging change tracking of connected entities. So, this “small chance” will possibly have a deep impact on the whole application design.