views:

455

answers:

1

So far as I gathered, LINQ to entities encourages eager loading with Load() or Include(). However, I wonder where should the eager loading take place in a multi-layered application?

Is it correct for the data-access layer (a repository class encapsulating the Entity instance) to have a generic Item GetItem(int id) function, and in business logic layer do

Item item = dbRepository.GetItem(itemId);
if (!item.itemDetails.IsLoaded)
 item.itemDetails.Load()

Or should the repository class have different explicit functions that load different foreign relations, therefore return Item of eager-loaded relations?

Many thanks!

Edit: Example - http://www.asp.net/learn/mvc/tutorial-29-cs.aspx

public Contact GetContact(int id)

This function returns a Contact entity type. However, depends on the business logic needs, we may want to Load() or Include() different foreign relations of the Contact entity. Does this requirement mean we need more overloaded GetContact() methods with parameters indicating which relations to load, or simply do the Load() in business logic?

A: 

For the most part, I don't do either one. Instead, I use LINQ to map my entity types to presentation model types. In this case, you don't have to think about loading at all. For example:

var presentationModel = (from entity in Repository.Entities
                         select new PresentationEntity ()
                         {
                             Prop = entity.Prop,
                             ChildProp = entity.Child.Prop
                         }).First();

Notice that I did not have to think about loading Child. LINQ to entities does this for you when you project onto a different type.

Craig Stuntz
Thanks for your answer. Where should this kind of logic take place? If we do the mapping in the Model layer (I'm assuming MVC) then aren't we muddling Model class with Presentation model, so that the data access layer needs to know the presentation model?
rokeyge
Mapping from repository types to presentation model types (and vice versa) should be in the controller.
Craig Stuntz
That means the linq queries are going to be in the controller as well? (Sorry I'm pretty new to this)
rokeyge
Yes. There is nothing wrong with having LINQ in the controller, so long as you are not re-implementing functionality which should be in the Repository. LINQ is a system for translating lists of one type into lists of another type. That functionality is useful in many places.
Craig Stuntz
Hrmmm, I see what you mean, but we may have different definition of Repository here. What about the example on http://www.asp.net/learn/mvc/tutorial-29-cs.aspx where a Repository pattern is used with MVC framework?
rokeyge
That example uses Repository (same definition), but it does not use a presentation model. Therefore, it isn't really applicable to the question you ask in these comments.
Craig Stuntz
I see. I'm still a bit concerned about exposing database logic in the controller. To map data type to presentation type in controller it seems inevitable. Cheers for your answers!
rokeyge
I agree with you on both points.
Craig Stuntz