Repositories and persistence ignorance again

Question

Here's where I'm up to.

I have a generic Repository class Repository<TKey, TValue> . It has the usual Repository pattern methods.

Each Repository takes an IContext<TKey, TValue> in its constructor which provides the persistence for the repository.

I have specialised repositories which are composed of a generic Repository and then methods tailored to repository actions that are specific to the specialised object. So if I had a specialised repository for Kitten objects, It would have methods to ClimbTree (probably taking a tree object) but not a BuryBone(Bone bone) method. The point I'm making badly is It creates an association between the kitten and its tree which needs to be persisted. void CleanWhiskers() might be a simpler example. This sets the Kittens whiskers to clean.

So I'm now thinking of a scheme for related child objects persistence and starting to wonder if I'm already going a bit wrong.

I started with slightly ugly methods on the repository to create child objects. So Kitten repository would have a method CreateFurBall() which would add a FurBall object to the Kitten's FurBall collection AND add a Furball to the FurBall Repository to be persisted (Actually the same object).

I've now changed to a system where I have something akin to an ObservableCollection which notifies its parent repository when a POCO is added. So I can just create a POCO furball and added it to the collection which would then be automatically registered with the furball repository.

First off I'll have nHibernate implemented in the contexts, I think this maps fairly well. This is a really open question, for anyone that's been down this route before, can you see anything that makes you go "STOP!!"

Answer 1

I should have thought that methods such as ClimbTree(), BuryBone(), CreateFurBall() and CleanWhiskers() belong on the domain objects, not on the repositories.

The repository should handle persistence of the aggregate roots - ie let you query for Kittens, Save and Update them. Anything you want to do with the kittens between instantiation and persistence is the prerogative of the Domain.

Answer 2

Nelson is correct.

I think there may be a confusion between the two ways of creating furballs. If a kitten is stored in the database with three furballs, then when it is pulled from the database, the kitten should be injected with his furball-data and the furball collection should be initialized from the furball-data.

When the application wants to add a furball to the kitten, then a furball should be by the kitten via Kitten.CreateFurBall() . I am making the assumption here that a furball is owned by the kitten and the furballs are not common to other kittens. If the furball is sufficently complex, you may need to abstract the creation of the furball to a FurballFactory that the kitten holds a lazy reference to.

As far as the creation of the Kitten entity, it can probably be best handled by having a reference to a KittenFactory in your KittenRepository which accepts the dto for the kitten and builds a kitten from it.

The biggest problem that you have demonstrated is in the Kitten.BuryBone(Bone bone) method. Kittens don't bury bones. Dogs do.

Answer 3

I might be slightly off-topic but I just wanted to put my two cents in about the repository pattern.

The repository pattern is great, especially when you put them all behind interfaces so that they can be swapped out easily. I create a repository for every entity. BrokenGlass is right in that the methods are usually very generic and don't contain much beyond persistence logic. I am usually a little less strict with the type of logic that makes it into a repository. For instance, some people think it is sinful to put paging logic in a repository, but I disagree.

I use Entity Framework and LINQ to SQL quite a bit. In order to page results from these I need the LINQ to operate on IQueryable<entity> so that the paging happens at the database level. I do not like to expose IQueryable outside of my repository. Because what if someday my repository needs to be rewritten and the data storage can no longer utilize IQueryable ? So rather than returning this from my repository:

IQueryable<entity> GetEntities();

...and paging the results in my controller, or elsewhere in my application. I instead do this:

IEnumerable<entity> GetEntities_byPage(int page);

...and I do the paging logic in the repository so that it can be translated into an expression at the data source.

I think your repositories should return some fairly tailored data, instead of just a raw data dump that your controller has to clean up (usually after loading it all into memory first, YECK!).

Answer 4

The way I have used the Repository pattern in the past, is just as a very thin mediator between the persistance provider and the data objects - each repository only contains very generic methods (ie typically Add/Update/Delete).

I think the business logic in your scenario, ie CreateFurBall() should be using the repository, but not be a method exposed by it.