.NET分部类与继承 [英] .NET Partial Classes vs. Inheritance

问题描述

好了，所以我们这里的内部实用程序生成的业务模型类从数据库表和视图，类似（但不是完全一模一样）一个ORM。在维护它，它发生，我认为在架构中的数据不太可能会改变一大堆。该功能，但威力。我们可能需要添加额外的功能的道路。我们可能要产生一些的这些功能​​，我们可能想扩展它。

Okay, so we have a utility here in-house that generates business-model classes from our database tables and views, similar to (but not quite exactly like) an ORM. In maintaining it, it occurred to me that the data in the schemas isn't likely going to change a whole lot. The functionality, however, might. We may want to add additional functionality down the road. We may want to generate some of that functionality, and we may want to extend it.

我们正在建设将驻留在类库供其他库和应用程序消耗类。没有大的惊喜出现。但这里的是难倒如何设计生成的类中，我们破坏少code地，当我们重新生成的一类这样的方式。如果，例如，code已被添加到一个属性（重presents在数据库表中的列），我们不想失去的。

The classes we're building will reside in a class library for consumption by other libraries and applications. No big surprise there. But the stumper here is how to design generated classes in such a way that we disrupt as little code as possible when we regenerate a class. If, for example, code has been added to a property (which represents a column in a database table), we don't want to lose that.

所以，也有飞跃想到两种方法：

So, there are two approaches that leap to mind:

经典继承，其中整个事情做在一个单一的，铁板一块级和消费者可以自由地覆盖基本实现。这得到了一种棘手不时，虽然和经常介绍铸造头痛。此外，如果派生类是不小心忘了调用基类的功能，事情可能很快会出现偏差。

Classic inheritance, where the entire thing is done in a single, "monolithic" class and consumers are free to override the base implementation. This gets kind of tricky from time to time, though, and frequently introduces casting headaches. Further, if the derived class isn't careful and forgets to invoke base class functionality, things can quickly go awry.

部分类。在这个方案中，我们单独业务对象成不同的部分：属性（它映射到的列），以及行为。行为甚至可以进一步细分为生成的行为和自定义行为。这种方法的问题，因为你所看到的，是其内在的复杂性。此外，还有的命名问题。

Partial classes. In this scheme, we separate the business object into distinct parts: the properties (which map to columns), and the behaviors. Behaviors could even be broken down further into generated behaviors and custom behaviors. The problem with this approach, as you can see, is its inherent complexity. Further, there's the naming problem.

下面是我的问题要问你人：当你正在处理这样的情况下（如果你曾经有），或者如果你是presented有这样一个场景，你会考虑什么样的解决方案，为什么？

Here's my question for you folks: When you're dealing with a scenario like this (if you ever have), or if you were presented with a scenario like this, what solutions would you consider, and why?

推荐答案

的全部原因部分类都包含在净是为了更容易地利用code生成工具。

The whole reason Partial Classes are included in .Net is to make it easier to utilize code generation tools.

如果您正在生成code，使用部分类。它就是这么简单。为什么你会冒这个险了code可能需要重新生成向下走，你必须做大量的工作与自定义重新更新呢？

If you are generating code, use partial classes. It's really that simple. Why would you take the risk that the code might have to be re-generated down the road and you'd have to do a ton of work to re-update it with customizations?

我不觉得有很多的复杂性，以谐音要么 - 它只是一个类分成了多个文件。生成code在一个文件中，自定义code中的其他。

I don't find there is much complexity to partials either - it's simply one class split over multiple files. Generated code in one file, custom code in the other.

这篇关于.NET分部类与继承的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！