Архитектура бизнес-приложений WPF

Question

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

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

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

• WPFClient.MainShell (exe)

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

• Фирменный модуль:

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

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

  • WPFClient.Workers.UI (модели представления и представления для модуля управления Workers)
  • ...
  • WPFClient.Workers.Entities (объекты, общие для пользовательского интерфейса, бизнеса и слоев данных)
• Другие модули (например, контракты, посещения, ...)

---

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

• WPFClient.Data.SQLite (конкретный уровень персистентности, который ссылается на dll X.Data и X.Entities одного или всех модулей)
• 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.Entities, ModuleY.Data,...

Конечно, конкретные реализации будут решаться с помощью механизма ServiceLocator.

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

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

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

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

Answer 1

Я думаю, что ваш первоначальный проект выглядит хорошо. Посмотрите это видео, чтобы узнать, как организовать структуру вашего приложения. В своем последнем вопросе вы упомянули репозитории и т. Д., И я предположил, что у вас есть кое-какие знания в области доменного дизайна Мне кажется, что вам нужно пересмотреть свои совокупности. Прочтите это введение в CQRS, и вы узнаете, что команда никогда не достигнет уровня данных в вашем приложении.