问题描述
这就是我要做的.
我有一个通用的 Repository 类 Repository.它具有通常的 Repository 模式方法.
I have a generic Repository class Repository<TKey, TValue>. It has the usual Repository pattern methods.
每个存储库在其构造函数中采用一个 IContext，为存储库提供持久性.
Each Repository takes an IContext<TKey, TValue> in its constructor which provides the persistence for the repository.
我有专门的存储库，这些存储库由通用存储库和针对特定于专用对象的存储库操作量身定制的方法组成.因此，如果我有一个专门用于 Kitten 对象的存储库，它将具有 ClimbTree 方法(可能采用树对象)，但没有 BuryBone(Bone bone) 方法.我说的不好的一点是它在小猫和它的树之间创建了一个需要持久化的关联.void CleanWhiskers() 可能是一个更简单的例子.这让小猫的胡须变得干净.
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.
我开始在存储库中使用稍微难看的方法来创建子对象.因此，Kitten 存储库将有一个方法 CreateFurBall()，它将向 Kitten 的 FurBall 集合添加一个 FurBall 对象，并将一个 Furball 添加到要持久化的 FurBall 存储库中(实际上是同一个对象).
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).
我现在已更改为一个系统，在该系统中我有类似于 ObservableCollection 的东西，它会在添加 POCO 时通知其父存储库.所以我可以创建一个 POCO furball 并将其添加到集合中，然后该集合会自动注册到 furball 存储库中.
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.
首先，我将在上下文中实现 nHibernate，我认为这映射得很好.这是一个非常开放的问题，对于以前走过这条路线的任何人，你能看到什么让你停下来！！"
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!!"
推荐答案
Nelson 是正确的.
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.
当应用程序想要给小猫添加毛球时，毛球应该由小猫通过 Kitten.CreateFurBall() 来完成.我在这里假设毛球归小猫所有，而其他小猫并不常见毛球.如果毛球足够复杂，您可能需要将毛球的创建抽象为小猫持有惰性引用的毛球工厂.
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.
就 Kitten 实体的创建而言，最好通过引用 KittenRepository 中的 KittenFactory 来处理它，该 KittenFactory 接受小猫的 dto 并从中构建小猫.
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.
您演示的最大问题是 Kitten.BuryBone(Bone bone) 方法.小猫不会埋骨头.狗可以.
The biggest problem that you have demonstrated is in the Kitten.BuryBone(Bone bone) method. Kittens don't bury bones. Dogs do.
这篇关于存储库和持久性再次无知的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！