0

我知道 Orchard 中使用的底层 ORM 是 NHibernate，它确实支持所谓的ClassMapping可能有助于按照我们想要的方式自定义映射。

但是我不确定 Orchard 如何利用 NHibernate 支持的映射方法。在这种情况下，它似乎总是使用类似于Table Per TypeEF 以及其他一些 ORM 的策略。使用该策略，基类将映射到某个公用表，而派生类将映射到另一个表，该表包含其自己的所有属性（未在基类中声明）。这两个表将具有一对一的关系。

现在我真的想让它使用类似于Table Per Concrete Type将基类和派生类映射到两个不同的表的策略，其中所有属性（包括继承的属性）都映射到列。这 2 个表不会有任何关系，因此仅在一个表中查询列不会意外生成内部 JOIN（针对一对一关系）。

实际上，如果我们只需要对数据进行分区（从 1 个大表到 2 个或更多具有相同架构的小表），这个要求是有意义的。我们不想重新声明或使用某种重复的模型类（具有不同的名称），相反，我们只需要创建一个新的模型类并让它从一个包含所有必要属性的基本模型类继承。

使用这样的当前代码：

public class ARecord {
    //properties ...
}
public class BRecord : ARecord {
    //empty here
}

目前我们不能使用BRecord，因为它被理解为 的另一部分ARecord，自动生成的查询（总是使用 INNER JOIN）会因为某些不存在的表或列名而失败。

我该如何解决这个问题？

4

1 回答 1

1

你不会喜欢它的 ;) 简而言之，答案是根本不做继承。Orchard 是围绕组合的概念精心设计的，在其内容模型中很好地避免了继承。也许 Orchard 的中心思想是将内容的概念作为“内容的原子”的一部分，并将这些基本单元设计为非常简单和可组合的功能块，它们可以很好地完成一件事。

这么多年过去了，这个概念非常好，我还没有看到一个内容模型的例子，其中继承会更加优雅和合适。正如您所发现的，这反映在 Orchard 中定制和使用 nHibernate 的方式上。

因此，您的问题的解决方案可能是以下两种情况之一：

  1. 您正在对内容进行建模，您应该重新考虑您对部件组合的方法。如果您提供有关您的特定场景的更多详细信息（可能是在一个新问题中），我很乐意在这个方向上提供具体帮助。
  2. 您正在对非内容数据进行建模，在这种情况下，您可能需要考虑选择退出 Orchard 特定的 nHibernate 内容专用特性，并做更接近金属的事情。同样，如果您提供有关您的方案的更多细节，我很乐意看一看并提供一些指示。
于 2019-08-23T17:20:55.717 回答