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

Question

Я прочитал StackOverflow guidelines и искал design-specific SE site. Если вы чувствуете, что этот вопрос еще слишком длинный или неясный, сообщите мне, и я попробую еще раз.

Я поддерживать N-уровневой линии бизнеса, WinForms приложение с помощью следующего слоя/конструкция:

• [WinForm Применение]
• [MVP на основе представления Layer (САВ, специфически)]
• [Service Layer]
• [Access Layer Data]

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

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

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

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

Answer 1

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

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