1

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

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

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

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

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

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

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

4

2 回答 2

2

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

于 2013-05-01T22:14:06.333 回答
2

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

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

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

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

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

于 2013-05-02T05:13:07.943 回答