Q:

Extending (alternative to) the repository desing pattern?

I am working on a project in ASP.NET MVC. I want to create an abstraction layer between the data access layer and the business logic layer of an application. I have been working with Repository and Unit of work. To review, in this pattern a general repository and a number of specific repositories is being created. The problem I have faced in this project is that I need method of some specific repository in another repository. For example, I have a Product and Subproduct repository. I want to use Subproduct methods inside Product methods instead of rewriting LINQ Queries for Subproduct every time. Is there any way to extend the functionaltiy of repository design pattern, or I have to use another design pattern?
public class ProductSubcategoryRepository : Repository<ProductSubcategory>, IProductSubcategoryRepository
{
    public ProductSubcategoryRepository(DbContext context) : base(context)
    {
    }

    public IEnumerable<ProductSubcategory> CheckSomeCondition()
    {
        // LINQ to check some condition based on product subcategory
    }
}

public class ProductCategoryRepository : Repository<ProductCategory>, IProductCategoryRepository
{
    public ProductCategoryRepository(DbContext context) : base(context)
    {

    }

    public IEnumerable<ProductCategory> GetProductCategoriesBeforeDate()
    {
        // Repeated LINQ to check some condition based on product subcategory 
        // (I am looking for a way to call the same method of ProductSubCategory calss)

        // LINQ To return List of product category if the previous query is true
    }
}

A:

You already said in your question that you have Business Logic Layer in place. That is the best place to manage this stuff.
So, you do not call one repository in other. Instead, you call two repositories in one method from BLL to achieve the target. Hopefully, your UoW is exposed to BLL. That way, under same scope of UoW, you execute both the actions.
This is not only limited to Getting the records. This can be further extended to Get-Modify-Update or whatever.
I am not sure what your CheckSomeCondition does. It it is just a Predicate then that is fine. If it is part of some business logic, better way is to shift it to BLL as I stated above.

