Question

What I want to archieve:

• Service assembly (project) that holds EntityClasses – pure Data.
• GUI assembly that extends those Entities for its own pourposes – Runtime information for GUI.

What I tried:

• Derivation (Gui defines class ExtendedEntity : Service.BaseEntity)

  seems to be the most common and only practicable way to me, but:

  Converting Service.BaseEntity to ExtendedEntity after retrieving Data from the Service is painful. can ‘workaround’ this by using reflection to generate new ExtendedEntity instances based on base entity instances, but that can’t be the ‘proper’ solution.

• Partial classes

  is exactly what I’m looking for, except the fact, that it does not work cross-assembly.

I’d greatly appreciate any hints helping me to find a proper & clean solution without reflection cheating =)

Answer 1

Is decompilation an option? If yes you can use e.g. PostSharp or Mono Cecil to rewrite the classes in question and add the there the code you want to have them.
I am curios why you do not want to use the standard OO approach like derivation. It is definitely not hacking.

The "cleanest" OO solution is to use aggregation and encapsulate the Entity classes inside objects where you can fully control what you can do with the data and how you want to manipulate or query it. You have reached "heaven" when your aggregation class does not need to expose the internal Entity class anymore because your class is powerful enough to support all necessary operations with the right abstractions.

If the classes you want to extend are sealed then you need to think hard why the writers of these classes did not want you to extend them.

Eric Lippert has a nice post about the usages of the sealed keyword.

…

Now, I recognize that developers are highly practical people who just
want to get stuff done. Being able to extend any class is convenient,
sure. Typical developers say "IS-A-SHMIZ-A, I just want to slap a
Confusticator into the Froboznicator class". That developer could
write up a hash table to map one to the other, but then you have to
worry about when to remove the items, etc, etc, etc — it’s not rocket
science, but it is work.

Obviously there is a tradeoff here. The tradeoff is between letting
developers save a little time by allowing them to treat any old object
as a property bag on the one hand, and developing a well-designed,
OOPtacular, fully-featured, robust, secure, predictable, testable
framework in a reasonable amount of time — and I’m going to lean
heavily towards the latter. Because you know what? Those same
developers are going to complain bitterly if the framework we give
them slows them down because it is half-baked, brittle, insecure, and
not fully tested!

…

Yours,
Alois Kraus