Как мой уровень DAO может взаимодействовать с уровнем представления?

Question

Я прочитал руководящие принципы Stackru и искал сайт SE для конкретного дизайна. Если вы считаете, что этот вопрос все еще слишком длинный или неясный, пожалуйста, дайте мне знать, и я попробую еще раз.

Я поддерживаю N-уровневое бизнес-приложение winforms со следующим уровнем / дизайном:

• [Приложение WinForm]
• [Уровень представления на основе MVP (в частности, CAB)]
• [Уровень сервиса]
• [Уровень доступа к данным]

Приложение интегрируется с различными ERP/ бизнес-системами, которые обрабатываются на уровне DAO путем использования специфических реализаций интерфейсов DAO ERP/ бизнес-систем, например:

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/ бизнес-приложения интегрированы. На сервисном уровне я могу получить запрос к "RecognizeDelayedRevenue", получить мою ссылку на мой конкретный объект DAO и спросить его, поддерживает ли он операцию (последняя часть является новой). Если он возвращает отрицательное значение, то теперь у меня есть проблема с дизайном, состоящая в том, чтобы представить пользователю диалог, включая предварительную обработку представляемых им данных с использованием методов, принадлежащих объектам DAO.

Мой вопрос: с точки зрения дизайна, который является большим грехом:

1. Сервисный уровень пытается создавать и показывать диалоги win32, в основном разделяя бизнес-логику и представление
2. Объект DAO принимает (то есть утверждает, что поддерживает) запрос и вместо того, чтобы выполнять его в интегрированной системе, он каким-то образом представляет диалог для пользователя.
3. Доведите интегрированные знания системы до уровня докладчика и обработайте исключение там.

Конечно, если у вас есть идея, о которой я не упомянул, это было бы очень интересно!:)

Answer 1

Я бы пошел с #3, но я бы использовал интерфейс ролей для поддержания уровня абстракции. Затем я бы запросил уровень представления презентации на наличие этого интерфейса, когда он должен решить, использовать ли дополнительную функцию:

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