8

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

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

因此，有两种方法跃入脑海：

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

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

这是我给你们的问题：当您处理这样的场景时（如果有的话），或者如果您遇到这样的场景，您会考虑哪些解决方案，为什么？

4

5 回答 5

13

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

如果您正在生成代码，请使用部分类。真的就是这么简单。您为什么要冒着可能不得不在路上重新生成代码的风险，并且您必须做大量的工作才能通过自定义重新更新它？

我也没有发现 partials 有太多复杂性——它只是一个类拆分多个文件。生成代码在一个文件中，自定义代码在另一个文件中。

于 2009-06-26T18:01:52.510 回答
4

我会走部分课程路径。只是因为它更适合将 1 个对象分成许多部分。甚至 Linq2Sql 也使用局部变量。使用模式和适当的约定来应对复杂性。并且在部分类上执行“部分更新”（如果生成的代码结构良好）更容易。

如果您不进行任何代码生成 - 采用类继承方式（实际上，您将被迫这样做，因为部分代码无法跨不同的程序集工作）。

于 2009-06-26T18:01:08.423 回答
3

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

于 2009-06-26T18:01:32.417 回答
0

你说：

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

我会围绕当前解决方案的维护成本（我猜这很重要）绘制一些预测数据，然后选择一个 ORM，编写概念验证解决方案并绘制比较数据来维护它。我不确定这个定制包在维护、升级和开发人员购买方面的成本是多少，但我不会去任何接近这样的“定制”产品的地方。知识是不可转移的，出错的风险很高（代码生成总是如此），并且你被绑定到底层数据库的内部。

于 2012-07-02T23:45:06.640 回答
0

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

于 2010-08-12T12:42:33.993 回答