(n)Hibernate是否适合在层次结构中排列超过200个类的模型层？

Question

我的模型层有一个相当大的类层次结构，即大约有200个类。层次结构的好处/坏处是它们都有相同的基类(我在这里不是在谈论对象类)。基类和叶类之间的最大距离是7，层次结构中任何级别的最大类数都是80。我使用nHibernate从持久化存储中保存/加载数据。

问题: nHibernate生成的查询效率很低。原因是它试图连接查询中并不真正需要的表吗？

有没有人使用(n)Hibernate来实现这样的类层次结构？

请参考NHibernate: Load base class objects only查看我的一个问题的具体示例。

Answer 1

NHibernate不得不求助于这种怪异的查询，因为它不确切地知道哪个表包含所需的数据。例如，对于session.Get<Vehicle>(100)，NHibernate不知道哪个表包含ID为100的车辆的数据，因此它必须将车辆、汽车、卡车和自行车连接在一起。但是使用session.Get<Truck>(100)，NHibernate知道数据只能驻留在Truck表中，因此查询效率会高得多，只有一个连接: Vehicle和Truck。

所以，如果你不能改变你的数据库模式，那么我认为你只有一个选择，那就是在查询时尽可能的具体，总是给NHibernate你需要的实体的确切类型。

如果你可以改变你的模式，那么我认为你应该尝试简化模型类，避免如此大的继承树。NHibernate提供了许多其他选项来将类连接在一起。

另一种选择是使用一对一而不是连接子类，将一个域模型类的信息分离到多个类中，而不强制它们相互继承。我在一个小得多的继承树上遇到了同样的问题( 150个类中大约有20个类共享相同的基类，并使用joined subclass进行映射)。当系列达到20-strong时，如果可能的话，我将停止在层次结构中添加更多的类，并尝试使用一对一。