asp.net mvc 3 - translate this into a generic repository pattern -

i have started translating project generic repository , unit of work pattern. far have been able reverse engineer direct context references in controllers generic repository; however, having trouble following 2 lines of codes:

`context.entry(ticket).collection(i => i.ticketitems).load();             ticket.ticketitems.clear();` 

this controller doing before remove reference between ticket , ticketitem. there many-to-many relation between ticket , ticketitem. 2 lines of code using before remove ticketitems ticket

you have 2 methods in repository interface - 1 navigation references , 1 navigation collections:

public interface irepository<t> {     void loadnavigationreference<treference>(t entity,         expression<func<t, treference>> navigationproperty,         params expression<func<treference, object>>[] includes)         treference : class;      void loadnavigationcollection<telement>(t entity,         expression<func<t, icollection<telement>>> navigationproperty,         params expression<func<telement, object>>[] includes)         telement : class; } 

they supposed support including other nested navigation properties well. implementation be:

public class repository<t> : irepository<t>     t : class {     private readonly mycontext _dbcontext;      public repository(mycontext dbcontext)     {         _dbcontext = dbcontext;     }      public void loadnavigationreference<treference>(t entity,         expression<func<t, treference>> navigationproperty,         params expression<func<treference, object>>[] includes)         treference : class     {         if (includes == null || includes.length == 0)             _dbcontext.entry(entity).reference(navigationproperty).load();         else             _dbcontext.entry(entity).reference(navigationproperty).query()                 .includemultiple(includes).load();     }      public void loadnavigationcollection<telement>(t entity,         expression<func<t, icollection<telement>>> navigationproperty,         params expression<func<telement, object>>[] includes)         telement : class     {         if (includes == null || includes.length == 0)             _dbcontext.entry(entity).collection(navigationproperty).load();         else             _dbcontext.entry(entity).collection(navigationproperty).query()                 .includemultiple(includes).load();     } } 

the includemultiple extension method used above taken ladislav mrnka's answer here.

the example in question this:

repository.loadnavigationcollection(ticket, => i.ticketitems); ticket.ticketitems.clear(); 

where repository of type irepository<ticket>.

if ticketitem had navigation property, ticketitemdetails, eagerly load ticketitems way:

repository.loadnavigationcollection(ticket, => i.ticketitems,     t => t.ticketitemdetails); 

edit

btw critical side note generic repositories: above part of generic repository has 16 methods , have used in stage of project before have stopped extend , abandoned style completely.

the repository had around 5 methods in beginning (like of usual repositories see on internet). impossible work 5 methods without losing lot of entity framework's power. so, needed extend step step, driven actual requirements in project, , never became "complete" before removed project.

the problem is: if show interface ("here have super generic , technology independent data access interface") "aha, using entity framework!". reason every method wrapper around entity framework method , can't hide using other names interface methods. whole interface smells of ef dbcontext/code-first.

now, try implement interface technology entity framework. you'll run same problem had: lots of methods missing leverage power of other technology, or existing methods have wrong parameters or there many methods can't reasonably implement other technology.

i failed , lost fun build in-memory implementation of interface unit testing.

in opinion such generic repository typical example of leaky abstraction real implementation have in mind shines through whole interface.

but if can't abstract usage of entity framework away, building generic repository interface rather pointless.