解析调用链反模式

Question

在我的ASP.NET开发中，我开始注意到一些反模式。它困扰着我，因为它看起来像是正确的事情，以保持良好的设计，但同时它闻起来是错误的。

问题是:我们有一个多层的应用程序，最底层是一个类，处理对为我们提供数据的服务的调用。上面是一层可以转换、操作和检查数据的类。上面是ASP.NET页面。

在许多情况下，来自服务层的方法在进入视图之前不需要任何更改，因此模型只是直接通过，如：

public List<IData> GetData(int id, string filter, bool check)
{
    return DataService.GetData(id, filter, check);
}

它不是错误的，也不一定是可怕的，但它创建了一种奇怪的复制/粘贴依赖。我也在研究底层服务，它也大量复制了这种模式，而且整个过程中都有接口。因此，“我需要向GetData添加int someotherID”，因此我将其添加到模型、服务调用者、服务本身和接口中。GetData实际上代表了几个使用相同签名但返回不同信息的方法，这并没有什么帮助。界面对这种重复有一定的帮助，但它仍然随处可见。

这个反模式有名字吗？有没有修复，或者架构的重大改变才是唯一真正的方法？这听起来像是我需要扁平化我的对象模型，但有时数据层正在进行转换，以使其具有价值。我还喜欢将我的代码在“调用外部服务”和“提供页面数据”之间分开。

Answer 1

我建议你使用query object pattern来解决这个问题。基本上，你的服务可以有一个签名，比如：

IEnumerable<IData> GetData(IQuery<IData> query);

在IQuery接口内部，您可以有一个以工作单元为输入的方法，例如事务上下文或类似ISession的内容(如果您使用的是NHibernate )，并返回IData对象列表。

public interface IQuery<T> 
{
 IEnumerable<T> DoQuery(IUnitOfWork unitOfWork);
}

这样，您就可以创建符合您的需求的强类型查询对象，并为您的服务提供一个干净的接口。来自Ayende的This article对这个主题进行了很好的阅读。

Answer 2

在我看来，您需要另一个接口，因此该方法类似于：

public List<IData> GetData(IDataRequest request)

Answer 3

你正在委托给另一个层，这不一定是件坏事。

您可以在此处或其他方法中添加一些其他逻辑，这些逻辑只属于这一层，或者换出将该层委托给另一个实现，因此它肯定可以很好地利用所涉及的层。

你可能有太多的层次，但我不会仅仅从这里看到，更多的是因为看不到其他任何东西。