.NET部分类与继承

Question

好的，我们内部有一个实用工具，可以从我们的数据库表和视图中生成业务模型类，类似于（但不完全像）ORM。在维护它时，我发现模式中的数据可能不会发生很大的变化。但是，功能可能会。我们可能希望在未来添加其他功能。我们可能想要生成一些功能，我们可能想要扩展它。

我们正在构建的类将驻留在类库中，供其他库和应用程序使用。那里没什么大惊喜。但这里的难点是如何设计生成的类，以便在重新生成类时尽可能少地破坏代码。例如，如果代码已添加到属性（表示数据库表中的列），我们不希望丢失它。

因此，有两种方法可以想到：

经典继承，其中整个事情在一个“单片”类中完成，消费者可以自由地覆盖基础实现。然而，这有时会变得棘手，并经常引入铸造头痛。此外，如果派生类不小心并忘记调用基类功能，事情很快就会出错。

部分课程。在此方案中，我们将业务对象分成不同的部分：属性（映射到列）和行为。行为甚至可以进一步细分为生成的行为和自定义行为。正如您所看到的，这种方法的问题在于其固有的复杂性。此外，还有命名问题。

以下是我的问题：当你处理这样的场景时（如果你曾经有过），或者如果你看到这样的场景，你会考虑哪些解决方案，为什么？

Answer 1

部分类包含在.Net中的全部原因是为了更容易地利用代码生成工具。

如果要生成代码，请使用分部类。这真的很简单。为什么你要承担代码可能需要重新生成的风险，你需要做大量的工作来重新更新它？

我发现部分内容并不复杂 - 它只是一个分为多个文件的类。在一个文件中生成代码，在另一个文件中生成自定义代码。

Answer 2

我会去偏节路径。仅仅因为它在很多部分中分割1个对象更自然。甚至Linq2Sql也使用了partials。通过模式和适当的约定来应对复杂性。并且在部分类上执行“部分更新”（如果生成的代码结构良好）更容易。

如果你没有做任何代码生成 - 去类继承方式（实际上，你会被迫，导致部分不能在不同的程序集中工作）。

Answer 3

这正是要解决的部分类存在的问题。我认为你可能会因为实际目的而将它们分解得太远。在不知道应用程序的细节的情况下，我的直觉反应是对所有生成的类代码使用部分类文件，为手工创建的所有代码使用第二个文件。为生成的部分类提出命名约定并坚持使用它。

Answer 4

如果你有一个要序列化的类型（到xml）并想要添加一些功能，你必须使用部分类而不是继承。 谢谢/// M

Answer 5

你说：

  

类似于（但不完全相同）ORM

我会根据当前解决方案的维护成本制定一些预测数据（我猜这很重要）然后选择ORM，编写概念验证解决方案并绘制比较数据以保持这一点。我不确定这个定制软件包在维护，增加和开发人员购买方面的成本是多少，但是对于一个“定制”产品，我不会去任何地方。知识是不可转移的，错误的风险很高（代码生成总是这样），并且您必然会遇到底层数据库的内部。