Should a Repository be responsible for "flattening" a domain?

Disclaimer: I'm pretty new to DDD and its associated terminology, so if i'm mislabeling any concepts, please correct me.

I'm currently working on a site with a relatively simple domain model (Catalog items, each of which stores a collection of CatalogImage items.)

My repository follows the standard interface of FindbyID(int ID) GetAll() etc...

The prob开发者_开发百科lem arises when trying to find a particular image by its ID; I end up with methods such as FindImagebyID(int CatalogItemID, int ImgID)

As new requirments develop, and the object graph becomes more heavily nested, I could see an explosion of methods such as Find{NestedType}ByID(int catalogItemID,.....,int nestedTypeID)

Should I simply be returning an IEnumerable from the FindAll() method, and using Linq in a higher layer to form these queries? Or will that be a violation of SoC?

It sounds to me like you have a justification for building multiple repositories.

Example

interface CatalogRepository
{
    Catalog FindByID(int ID);
}

interface CatalogImageRepository
{
    CatalogImage FindByID(int ID);
}

This will properly separate out your concerns, since each repository is only responsible for knowing how to deal with that specific entity.

I would filter the model at a layer above the repository, with LINQ if you like. Makes the repository simple. If you are using LINQ to get the data from the database this method works very well, if you are having to use ADO or some other legacy data access layer than it might make it more difficult to make the repository so simple. Linq makes it easy so that you can have the repository return IQueryable and let the next layer add the filtering and the actual retrieval of data does not happen until it is asked for. This makes it possible to have a method on the repository like GetImages() that gets all images, and the next layer adds the filtering for a specific image. If you are using ADO, you are probably not going to want to bring back all images then filter....so could be a trade off.