Question

我使用的其他ORM，例如Torque，Propel或Doctrine，为每个实体生成2个类：例如， BaseCustomer 和 Customer 。客户继承自 BaseCustomer ，您可以覆盖方法或添加自己的方法。

但实体框架会生成部分类。您可以添加方法，但不能覆盖它们（构造函数或访问器方法）。

为什么？

我想代码生成器更容易处理部分类，并且它会阻止开发人员搞乱更改跟踪代码，但是......

这不是EF的缺点，因为它限制了开发人员的自由吗？

Answer 1

EF的默认代码生成是原样。您无法修改直接行为。您只能在部分类中添加自己的行为。构造函数没有问题，因为我知道EF不会为实体创建构造函数 - 它使用默认构造函数。

在EF 4中，整体变化很大。您可以关闭默认实体生成器并使用T4模板。 T4模板只是另一个脚本文件，您可以修改并添加所需的任何更改。

如果你想更好地解释为什么这样做你应该问ADO.NET团队，但一般来说，部分类是处理整个.NET框架中生成的代码的常用方法，因此他们可能保持一致性。

Answer 2

继承通常被滥用，实际上限制的不仅仅是部分类。作为设计原则，类应该对扩展开放，而部分类比继承类更好。

对于覆盖自动化实体属性/方法，您始终可以使用new关键字（如果您使用的是C＃）：

public MyCustomer : Customerbase {
    public new string FirstName { ... }
}

但是，任何继承自MyCustomer的类都会默认返回FirstName的{{1}}。

Answer 3

我无法想到在EF中覆盖方法或属性的特别好的理由。如果您不希望存在特定属性并希望提供自己的属性，请不要将其包含在实体模型中。我承认构造函数有点令人担忧，不过你可以使用工厂方法来解决它所需的问题。

我认为所有的设计决策都有权衡 - 我已经与Propel合作，并且在此背景下也喜欢它的模型。不过，EF确实很适合.NET范例，并且我发现部分类“足够好”，可以在需要时扩展实体。