我要归档的内容：
我尝试了什么：
派生（Gui定义类ExtendedEntity：Service.BaseEntity）
对我来说似乎是最常见也是唯一可行的方法，但是：
从服务中检索数据后将 Service.BaseEntity 转换为 ExtendedEntity 很痛苦。可以通过使用反射基于基本实体实例生成新的 ExtendedEntity 实例来“解决”这个问题，但这不是“正确”的解决方案。
部分类
正是我正在寻找的，除了它不能跨汇编工作。
我非常感谢任何帮助我找到正确且干净的解决方案而没有反射作弊的提示 =)
【问题讨论】：
标签： c# .net entity partial-classes derived
这不是一个直接的答案，但您可能需要多考虑一下您的设计。为什么您的 GUI 需要深入了解数据存储机制？通常，我们会非常努力地确保 UI 和数据访问是松散耦合的，因此我们可以对其中任何一个进行更改，而不必担心破坏已经工作的内容。您要实施的设计可能会在以后导致无法预料的问题。
一种适用于此类事物的常见模式称为存储库模式。本质上，服务程序集（存储库）将包含将数据推入和推出特定数据存储所需的所有知识。数据的“形状”是众所周知的，并在 GUI 和存储库之间共享。服务组件将使 CRUD 操作对 GUI 可用，并且 GUI 将持有对存储库的引用，并调用其上的方法来获取、创建和更新它需要的数据。
这里有一些链接可以开始了解松散耦合、存储库模式和依赖注入的想法。
【讨论】：
可以选择反编译吗？如果是，您可以使用例如PostSharp 或 Mono Cecil 重写有问题的类，并在那里添加你想要的代码。 我很好奇为什么你不想使用像推导这样的标准 OO 方法。这绝对不是黑客攻击。
“最干净”的 OO 解决方案是使用聚合并将 Entity 类封装在对象中，您可以在其中完全控制可以对数据执行的操作以及如何操作或查询数据。当您的聚合类不再需要公开内部实体类时，您就达到了“天堂”，因为您的类足够强大，可以通过正确的抽象支持所有必要的操作。
如果您要扩展的类是密封的，那么您需要认真思考为什么这些类的作者不希望您扩展它们。
Eric Lippert 有一个很好的 post 关于sealed 关键字的用法。
...
现在，我认识到开发人员是非常实际的人，他们只是 想把事情做好。能够扩展任何类很方便， 当然。典型的开发者说“IS-A-SHMIZ-A，我只是想打一个 Froboznicator 类中的混淆器”。该开发人员可以 写一个哈希表将一个映射到另一个，但是你必须 担心什么时候移除物品等等——这不是火箭 科学，但它是工作。
显然这里有一个权衡。权衡是在让 开发人员允许他们处理任何旧对象，从而节省了一点时间 一方面作为一个财产包，并开发一个精心设计的， OOPtacular、功能齐全、健壮、安全、可预测、可测试 在合理的时间内构建框架——而且我会倾向于 严重偏向后者。因为你知道吗？那些一样 如果我们提供的框架，开发人员会痛苦地抱怨 他们放慢了他们的速度，因为它是半生不熟的、脆弱的、不安全的，而且 未经过全面测试！
...
你的， 阿洛伊斯克劳斯
【讨论】：
您可以让您的 GUI 程序集在实体类上定义 extension 方法。使用适当的using 指令，这将意味着消费代码不会知道或关心方法的实际定义位置。
不存在扩展 properties 有点令人烦恼，因此即使是概念上的属性也必须作为方法来实现。
看起来有点像这样：
在服务组装中
public class FooDTO
{
public string Name { get; set; }
}
在 GUI 程序集中
internal static class Extensions
{
// Artificial example!
public static int GetNameLength(this FooDTO foo)
{
return foo.Name.Length;
}
}
// Consuming code
int myFooNameLength = myFooDTO.GetNameLength();
【讨论】：