Question

[This blog post titled: ‘Passing multiple Include statements into a Repository‘ provides a great overview of how to control the depth of loaded children when hydrating an EF dbContext-based object. A very nice explanation of feeding the repository with Linq expressions.

But the blog leaves hanging a question that would really round out the workflow involved by explaining how thing look in the Controller itself.

If thin controllers are generally agree to be a good thing, and if EF is maturing to the point of mainstream usage, what pattern best mediates between the repository and controller?

George phrases the question better:

This is perfect, but then how does
one write the controller to handle all the different ways an object
and it’s children want to be requested? Is it a matter of creating an
CustomerOrderController and a CustomerOrderLineItemsController?

NOTE: This link is auto-offered by SO and probably addresses the ‘How to execute‘ – I’m still needing an overview of the syntax to be used.

mnymnythx

Answer 1

Have you considered using a generic repository?

The article goes a bit furthur than you’re wanting which might be good, in implementing a unit of work pattern. Your tags include MVC so I do recommend you use this to help keep all of your repos and objects synced up.

Then, in an action in your controller you can choose which properties needed to be included:

 private UnitOfWork _unitOfWork;

        public YourController()
        {
            _unitOfWork = new UnitOfWork();
        }
        //
        // GET: /Market/
        public ActionResult Index()
        {
            return View(_unit.YourRepository.Get(m => m.IsActive, null, "CollectionToLoad1,CollectionToLoad2"));
        }

In this example, I would get every item that has the IsActive bit as true, as well as including CollectionToLoad1 and CollectionToLoad2

If you don’t want to implement a unit of work, you can simple declare the repo in the controller rather than the unit, and make the call directly.