.NET Partial Classes vs. Inheritance [closed]

Question

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.

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.

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?

Answer 1

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

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?

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.

Answer 2

I would go partial classes path. Just because it fits more natural for dividing 1 object in many parts. Even Linq2Sql uses partials. Fight with complexity with patterns and proper conventions. And it's easier to perform 'partial update' (if generated code is well structured) on partial classes.

If you aren't doing any code generating - go class inheritance way (actually, you would be forced to, cause partials won't work across different assemblies).

Answer 3

This is exactly the problem that partial classes exist to resolve. I think you may be breaking them down a little too far for practical purposes though. My gut reaction without knowing the finer details of your application would be to use a partial class file for all the generated code of a class, and a second file for all the code created by hand. Come up with a naming convention for generated partial classes and stick with it.

Answer 4

If you have a type that is to be serialized (to xml) and want to add some functionality, you have to use partial class and not inheritance. Thanks ///M

Answer 5

You say:

similar to (but not quite exactly like) an ORM

I would draw up some forecats figures around maintenance costs for the current solution (which I'm guessing is significant) then select an ORM, write a proof of concept solution and draw up comparative figures for maintaining that. I'm not sure what this custom package costs in the way of maintenance, rampup and developer buy in but I for one would not go anywhere near a "custom" product such as this. The knowledge is not transferable, the risk of error is high (always the case with code generation) and you are bound to the intracacies of the underlying database.