views:

59

answers:

2

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 problem 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?

+2  A: 

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.

Joseph
I actually agree with your answer, just wondering if the entity/model is just large?
CSharpAtl
I like the general approach, but how would the CatalogImageRepository's FindByID method know which Catalog item the image is associated with?
Gurdas Nijor
@CSharpAtl I'm not so sure if it's a question of how large the model is. I think it's more of a question of how the OP plans to query the DAL. If it's always going to be queried the same way (i.e. FindById, etc.), then I think he's fine to continue down his path. However, if it starts going down the path of dynamic querying then I think implementing Command Query Separation might be a better way to go, but the entire design would have to be changed in that case.
Joseph
@Gurdas I'm assuming the OP already has that figured out in the DAL because of the fact that his first implementation FindbyID(int ID) was returning a Catalog and inside it was a collection of CatalogImages. There must have already been logic to determine that relationship.
Joseph
A: 

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.

CSharpAtl