WPF Line Business Application Architecture

Question

В моей компании (в первый раз) мы разрабатываем довольно большую линейку бизнес-приложений на C# с WPF. Я решил использовать UI-модульный подход, как в Microsoft PRISM, но я почесываю голову о том, как развивать бизнес и уровень данных.

Мне нужно поддерживать как минимум две базы данных: SQL Server для установки клиент/сервер и SQLite для однопользовательских установок, но я хочу быть готовым к другим решениям сохранения db или cloud/rest. И в будущем нам, вероятно, придется разработать веб-версию и версию UniversalApp!

Решение, которое я имею в виду на это:

• WPFClient.MainShell (ехе)

• Другие оболочки длл (самонастройки, динамический модуль загрузки, ...)

• Модуль компании :

  • WPFClient.Companies.UI (ViewModels и просмотров)
  • WPFClient.Companies.BIZ (менеджер OBJS для проверки, вызывает упорству слой, ...)
  • WPFClient.Companies.Data (общие интерфейсы для персистентности)
  • WPFClient.Companies.Entities (объекты распределяются среди щ, Biz и данных слоев)

• Рабочие модуль

  • WPFClient.Workers.UI (ViewModels и представления для модуля управления Workers)
  • ...
  • WPFClient.Workers.Entities (объекты распределяются между Ui, BIZ и данных слоев)
• Другие модули (Исх. Контракты, просмотров, ...)

---

конкретные реализации для сохранения состояния слоя:

• WPFClient.Data.SQLite (бетон живучесть слой, который ссылается на X.Data и X.Entities DLL из один или все модули)
• WPFClient.Data.SQLServer (конкретный уровень сохранения, который ссылается на DLL X.Data и X.Entities одного или всех модулей)
• WPFClient.Data. ????

---

Ссылки между проектами являются:

• ModuleX.UI -> ModuleX.BIZ и ModuleX.Entities
• ModuleX.BIZ -> ModuleX.Entities и ModuleX.Data
• ModuleX.Data -> ModuleX.Entities
• ... Data.SQLIte -> ModuleX.Entities, ModuleX.Data, ModuleY.Объекты, ModuleY.Data, ...

Конечно, конкретные реализации будут разрешены механизмом ServiceLocator.

Я не нашел ни одного примера приложения LOB, написанного следующим образом. Я много читал, тонны статей об единице работы и сущности, CQRS, бла-бла-бла, но все было слишком много теории!

Что случилось с этой архитектурой? Есть ли лучшее решение или пример реального мира?

Просто, чтобы быть яснее: предположим, что мне нужно сохранить работника с его историей работы (или классическим примером порядка с несколькими порядковыми элементами). Если слой biz «знает», он должен сохранять в нескольких хранилищах, это означает, что слой biz знает о механизме персистентности, поэтому он слишком много знает. Но если слой biz просто передает команду (SaveWorkerInfo или SaveOrderInfo) в уровень персистентности, чем уровень многоуровневости, который слишком много знает, а уровень biz только выполняет проверку (я думаю, что это стиль CQRS).

Большое спасибо, я знаю, что это длинный пост для чтения!

Answer 1

Я думаю, что ваш первоначальный проект выглядит хорошо. Взгляните на видеоролик this для вдохновения для того, как организовать структуру вашего приложения. В вашем последнем вопросе вы упоминаете репозитории и т. Д., И я предположил, что у вас есть некоторые сведения о domain driven design. Кажется, вам нужно пересмотреть свой aggregates. Прочитайте this введение в CQRS, и вы узнаете, что команда никогда не достигнет уровня данных в вашем приложении.