Home/ Questions/Q 3970050
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-20T04:02:23+00:00

Here’s where I’m up to. I have a generic Repository class Repository<TKey, TValue> .

  • 0

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!!”

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0