Usage of generic IRepository

In the datalayer of nopcommerce, a generic IRepository<T> class is used. While this usage of a generic IRepository class reduces the amount of code, I am wondering if this is the best way to go, because this way you lose much control and flexibility. This has also to do with the usage of an IDbContext, I am wondering why that abstraction layer is needed, why can't the IRepository directly talk to NopObjectContext? This way in the repository, we cannot use many of the functionalities of the entity framework, for example calling the function context.Entry(T).IsLoaded is not possible. And say I want to use the .include extension method to always fill navigation properties.

Further, this usage implies lazy loading; so for example if I fetch a customer in the customercontroller with _customerservice, and then in the controller do something like customer.Profile (I have added a Profile table for my app), this means that a database call is fired from the controller, and that seems not entirely correct to me. I want to know what others think about this, is lazyloading appropriate in a layered app, or should the repository just give us all the data we need, so we know for sure the controllers will never fire database calls?

In this light, I am considering to create custom repositories for some classes (customer for example) that would have access to NopObjectContext and thus all the functionality of the entity framework and to ensure that the repo always returns all the data that is needed. Please let me know your thoughts about this.

.Include can be used.  I believe it is part of System.Data.Entity.

I agree that lazy loading is a little overused in nop.  Although it takes a little extra work with upgrades I have removed the virtual property from many navigation properties which disables lazy loading for that object.  I have done some unscientific testing and found it to speed things up a bit.

t

ok, .include may be used; but most of the entity framework functionality can't be accessed, because of the IDbContext abstraction. I really wonder what is the reason for that.

By the way: because of the generic nature of IRepository, an IQueryable is passed to the service layer and database calls are fired from the service layer.

All of the DB calls are made within the Service layer for Nop.  They return collections (normally List) for data using DTOs, which is classic layered service.  I can't quite imagine how turning off lazy loading could help.  If anything, it would hurt more than help I think.  That was quite evident back during the Entity Framework 3.0 days.

Myself, I like the layered structure that Nop has.  I think how they have the separation of the Web layer from the Service layer are right on.  It makes for much more efficient unit testing at the very least.

I also like the layered structure, it is very clean.

But passing up the IQueryable to the service layer imho does not quite adhere to a layered design, because database calls are fired from the service layer. But in an approach without a generic repository there would be more repositoryclasses, so it's about balance I think. In my opinion, that would much more adhere to a layered design.

My other question is why the repositories may not be aware of NopContext, thus why NopContext is hidden behind an IDbContext abstraction layer.