我的DAO层如何与表示层交互？

Question

我读了StackOverflow guidelines并找了design-specific SE site。如果您觉得这个问题仍然太长或不清楚，请告诉我，我会再试一次。

我维持一个N层业务线，使用以下层/设计赢得应用程序：

• [WinForm Application]
• [基于MVP的表示层（CAB， 特异性）]
• [服务层]
• [数据访问层]

该应用程序集成了不同的ERP /业务系统，这些系统通过使用DAO接口的ERP /业务系统特定实现在DAO层处理，例如：

public sealed class QBTransactionAssemblyBuildDAO : QBDAO, ITransactionAssemblyBuildDAO
public sealed class SAPTransactionAssemblyBuildDAO : SAPDABase, ITransactionAssemblyBuildDAO

例如，一个业务部门可能会使用与QuickBooks集成的应用程序。这将在app.config中配置，并且工厂方法将在运行时创建适当的QB * DAO实现。同样，另一个部门可以使用它与SAP集成，配置文件将支持这一点，工厂将生成SAP * DAO实现。然后，服务可以使用DAO，同时不了解底层集成系统。

这一切都很有效，事实上，由于我不得不增加额外的集成系统和记录支持，设计已经带来了好处。当我遇到集成应用程序的API不支持所有其他系统都可以支持的任务时，这一切都发生了变化。我现在处于需要支持异常流程而不是更新数据的情况下，比如SAP，我需要向用户提供一个对话框，其中包含用于手动转录的数据（确定，复制和粘贴）进入SAP应用程序用户界面。

如果我遵守我的图层和对象分离指南，我第一次分支应用程序流的机会就在服务层，因为该层知道哪些ERP /业务应用程序是集成的。在服务层，我可以收到对＃34; RecognizeDelayedRevenue＆＃34;的请求，获取我对具体DAO对象的引用并询问它是否支持该操作（后一部分是新的）。如果它返回负数，我现在面临向用户呈现对话框的设计挑战，包括使用属于DAO对象的方法预处理它呈现的数据。

我的问题：从设计的角度来看，这是更大的罪恶：

1. 服务层尝试创建和显示win32对话框，基本上打破了业务逻辑和表示的分离
2. DAO对象接受（即声称支持）请求，而不是针对它的集成系统执行，它以某种方式向用户显示一个对话框
3. 将集成的系统知识降低到演示者级别并在那里处理异常。

当然，如果你有一个我没有提到过的想法，那也会非常有趣！ ：）

Answer 1

我选择＃3，但我使用role interface来保持抽象级别。然后，当我必须决定是否使用其他功能时，我会对该界面的存在进行表示层查询：

if (myImpl is IAdditionalFeatureAware)
{
    // ...
}