Question

我想要的是什么：

包含EntityClasses的服务程序集（项目） - 纯数据。
GUI程序集，为其自己的pourposes扩展这些实体 - GUI的运行时信息。

我尝试了什么：

派生（Gui定义类ExtendedEntity：Service.BaseEntity）

对我来说似乎是最常见也是唯一可行的方式，但是：

从服务中检索数据后将Service.BaseEntity转换为ExtendedEntity非常痛苦。可以通过使用反射来基于实体实例生成新的ExtendedEntity实例来解决这个问题，但这不是“正确的”解决方案。
部分课程

正是我正在寻找的，除了它不能交叉组装这一事实。

我非常感谢任何帮助我找到合适的＆amp; amp;的提示。没有反射作弊的清洁溶液=）

Answer 1

这不是一个直接的答案，但您可能想要更多地考虑一下您的设计。为什么您的GUI需要熟悉数据存储的机制？通常我们非常努力地确保UI和数据访问松散耦合，因此我们可以对其中的任何一个进行更改，而不必担心破坏已经工作的内容。您希望实施的设计可能会在以后导致无法预料的问题。

一种适用于此类事物的常见模式称为存储库模式。本质上，服务程序集（存储库）将包含将数据推入和传出特定数据存储所需的所有知识。数据的“形状”是众所周知的，并在GUI和存储库之间共享。服务程序集将使GUI可以使用CRUD操作，GUI将保存对存储库的引用，并调用其上的方法来获取，创建和更新所需的数据。

以下是一些链接，可以了解松散耦合，存储库模式和依赖注入的概念。

Cohesion and coupling

What is dependency injection

What's a good repository pattern tutorial

Answer 2

您可以让GUI程序集在实体类上定义扩展方法。使用适当的using指令，这意味着消费代码不会知道或关心实际定义方法的位置。

轻微的烦恼是不存在扩展属性，因此即使是概念上属性的东西也必须作为方法实现。

看起来有点像这样：

在服务程序集中

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();

Answer 3

反编译是一种选择吗？如果是，您可以使用例如PostSharp或Mono Cecil重写有问题的类，并在那里添加您想要的代码。我很好奇为什么你不想使用像派生这样的标准OO方法。绝对不是黑客攻击。

“最干净”的OO解决方案是使用聚合并将Entity类封装在对象中，您可以完全控制对数据执行的操作以及操作或查询数据的方式。当你的聚合类不再需要公开内部的Entity类时，你已经达到了“天堂”，因为你的类足够强大，可以通过正确的抽象来支持所有必要的操作。

如果要扩展的类是密封的，那么你需要仔细思考为什么这些类的编写者不希望你扩展它们。

Eric Lippert对密封关键字的用法有一个很好的 post 。

...

现在，我认识到开发人员是非常实用的人   想要完成任务。能够扩展任何课程都很方便，   当然。典型的开发人员说“IS-A-SHMIZ-A，我只是想打一个   进入Froboznicator类的Confusticator“。开发人员可以   写一个哈希表来将一个映射到另一个，但是你必须这样做   担心何时删除物品等等 - 它不是火箭   科学，但这是工作。

显然这里有一个权衡。在权衡之间进行权衡   开发人员通过允许他们处理任何旧对象来节省一点时间   作为一个财产袋，并开发精心设计，   功能强大，功能齐全，强大，安全，可预测，可测试   框架在合理的时间内 - 我会倾向于   对后者很重要。因为你知道什么？那些一样   如果我们给出的框架，开发人员会痛苦地抱怨   它们会减慢它们的速度，因为它是半烘烤的，易碎的，不安全的   没有经过充分测试！

...

此致， Alois Kraus

实体类的跨DDL扩展

3 个答案: