我应该让我的域对象依赖于它们的上下文吗？答案

【问题标题】：Should I make my domain objects dependent on their context?我应该让我的域对象依赖于它们的上下文吗？
【发布时间】：2013-04-27 04:47:53
【问题描述】：

我有一个上下文对象。它是一个复杂的小字符，由 Auth 对象、CurrentNode 对象、Graph 对象和其他一些对象组成。 Context 对象有很多简单的方法，例如isLoggedIn() 和isAdmin()，还有很多更复杂的方法，例如hasPathToNode() 和netPathsToNode()。大多数情况下，这些方法只是代理附加对象。

上下文对象在我的域层中，即。我的应用程序堆栈的底部。它被所有层超类型使用，包括控制器、视图和服务。这似乎工作得很好。

到目前为止，我还不需要使其他域对象依赖于上下文。我的控制器或服务已经能够决定是否应该执行请求的操作。但是，现在我有一个域对象，它特别复杂并且严重依赖于 Context 中封装的逻辑。

我可以继续让这个域对象依赖它的上下文，但我的问题是我应该吗？对象和上下文在同一层，哪个很好。 Context 是一个单例，但可以重置，因此很容易测试。

根据 Martin Fowler 关于服务层模式的 POEAA 讨论，“域逻辑”（与“应用程序逻辑”/“工作流逻辑”相反）的逻辑属于域对象，因此鼓励我继续前进让依赖发生。

我意识到“耦合”通常是需要避免的。然而，在这种情况下，我将用层内耦合代替层间耦合，我认为这本身就是一种改进。最终我会让依赖项可注入，这将进一步减少耦合的缺点。

到目前为止，这与我的方法有相当大的不同，所以我想在我做出改变之前找出你的想法。如果我继续处理这种依赖关系，我可能会重构我迄今为止所做的所有工作，并让其他域对象也依赖于它们的 Context。

【问题讨论】：

如果有代码，问题更容易理解。

标签： design-patterns dependencies

【解决方案1】：

我的观点是这一切都取决于。你必须有一点实用主义，否则“正确”的解决方案可能比紧密耦合的解决方案痛苦 10 倍。您能否提供有关依赖 Context 对象的域对象的更多信息？对 Context 对象的依赖是基本的还是特殊情况？也许 Context 中的功能需要分解到另一个类并与两者共享？也许您可以在 Context 对象上提供一些其他类可以挂钩的事件？在我看来，还没有足够的信息来做出这个决定。没有一种适合所有此类问题的解决方案。

【讨论】：

谢谢大卫，你的实际考虑清单是我开始朝正确方向迈出的全部。
感谢 Kim，很高兴回答任何其他问题。

【解决方案2】：

没有示例代码和实现，很难确定您的域是否应该依赖于上下文。但是，我已经使用具有许多静态方法和上下文（例如配置）的遗留代码完成了这项工作。我还开发了一个类，它处理 WPF 中的所有基本操作（例如菜单栏和主选项卡式面板）。结果，它们都很难重构，并且需要很长时间才能重新部署到另一个应用程序。

如果可用，我建议构造函数在域中注入上下文接口（而不是上下文本身），或者创建直接依赖项。如果难以使用/创建，请部署一个具有默认静态构建器的新层。示例：

public static class DomainContextCreator{
    public static Domain DefaultDomain{
        get{
            IContext context = new Context();
            Domain domain = new Domain(context);
            return domain;
        }
    }
}

另外，你总是可以有一个包装类来处理一些上下文，比如静态属性、静态方法等；并使其可注射和通用。您可以在 codereview here 找到实现示例。

如果您提供代码实现示例，也许会有更好的答案。

【讨论】：