使用子类的子类进行棘手的 Fluent Nhibernate 建模
我正在将一个项目从自定义 DAL 移至 Nhibernate，但我遇到了一个棘手的映射场景，我不知道如何解决。本质上，子类的子类没有鉴别器值。
主要子类具有鉴别器值，因此这是微不足道的。当我到达第三层时，问题就出现了。子子类型之间的唯一区别在于哪个表引用它们（在 HasOne 样式映射中）。
任何帮助将不胜感激，谢谢:)
I'm moving a project off of a custom DAL and onto Nhibernate but I've run into a tricky mapping scenario that I don't know how to resolve. Essentially, there are sub classes of a subclass without a discriminator value.
The primary subclass has a discriminator value so that was trivial. The issue arises when I get to the third level. The only difference between the sub-sub types is which table references them (in a HasOne style map).
Any help would be greatly appreciated, thanks :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您希望第三级对象成为同一个表中的记录，我会为第三级类型添加一个鉴别器。它可以是基于父类型的计算属性。使用 FluentNH，我认为它必须对映射器可见（您不能使用普通 NHibernate 必须反思性检查私有成员的技巧）。
如果您想将它们全部放在同一张表中，那就是这样。如果您不太关心架构中的表计数，则根本无法包含鉴别器，和/或第三级类型的架构定义足够不同，以至于映射到单个表将提供“奇怪”结果（例如许多空列或非常通用/非描述性的列名称），然后只需为每个具体子类型创建到不同表的映射。
您还可以对架构进行反规范化。由于它是 HasOne() 关系，因此子类可以使用组件映射包含第三级类的列。如果所有第三级类型都映射到相似的字段，并且您认为这种关系不太可能从 1:1 变为 1:n，那么这可能是正确的选择。
If you want the third-level objects to be records in the same table, I'd add a discriminator to the third-level type. It can be a calculated property based on the parent type. Using FluentNH, I think it does have to be visible to the mapper (you can't use the tricks that vanilla NHibernate has to reflectively examine private members).
That's if you want to have them all in the same table. If you don't care too much about table count in your schema, you simply cannot include a discriminator, and/or the schema definitions of the third-level types are different enough that mapping to a single table would provide "odd" results (like a lot of null columns or very general/nondescriptive column names), then simply create a mapping for each concrete subtype to a different table.
You can also de-normalize the schema. Since it's a HasOne() relationship, the subclass can contain the columns of the third-level class using a Component mapping. If all of the third-level types map to similar fields, and you think it'll be unlikely that this relationship will change from 1:1 to 1:n, this is probably the way to go.