我是否应该使域对象依赖于它们的上下文？

Question

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

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

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

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

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

我意识到“耦合”在一般情况下是要避免的。然而，在这种情况下，我将用层内耦合取代层间耦合，我认为这本身就是一种改进。最终，我将使依赖项具有注入性，这将进一步减少耦合的缺点。

到目前为止，这与我的方法有相当大的不同，所以在我做出改变之前，我想了解你的想法。如果我继续使用这个依赖项，我可能会重构我迄今为止所做的所有工作，并让其他域对象也依赖于它们的上下文。

Answer 1

我的看法是，这一切都取决于。你必须有一点实用主义，否则“正确”的解决方案可能比紧密耦合的解决方案痛苦10倍。您能提供更多关于依赖上下文对象的域对象的信息吗？对上下文对象的依赖是基本的还是特例？也许上下文中的特性需要被分解到另一个类中，并与两者共享？也许您可以在上下文对象上提供其他类可以链接到的一些事件？在我看来，还没有足够的信息来打这个电话。对于这类问题，没有一刀切的解决办法。

Answer 2

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

如果可用，我建议构造函数在域注入上下文接口(而不是上下文本身)，要么创建直接依赖关系。如果很难使用/创建，那么部署一个具有默认静态构建器的新层。示例：

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

此外，您可以始终有一个包装类来处理某些上下文，例如静态属性、静态方法等，并使其具有可注入性和通用性。您可以在codereview here中找到实现的示例。

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