WPF业务线应用程序架构

Question

在我的公司（第一次）我们正在使用WPF在C＃中开发一个相当大的业务应用程序。我决定采用类似于微软PRISM的UI模块化方法，但我对如何开发业务和数据层感到头疼。

我需要支持至少两个数据库：用于客户端/服务器安装的SQL Server和用于单用户安装的SQLite，但我想为其他数据库或云/休息持久性解决方案做好准备。在未来，我们可能不得不开发Web版本和UniversalApp版本！

我正在考虑的解决方案是：

• WPFClient.MainShell（exe）

• 其他shell dll（自举，动态模块加载，......）

• 公司模块：

  • WPFClient.Companies.UI（viewmodels and views）
  • WPFClient.Companies.BIZ（经理objs验证，调用持久层，...）
  • WPFClient.Companies.Data（持久层的通用接口）
  • WPFClient.Companies.Entities（在ui，biz和数据层之间共享的实体）

• 工人模块

  • WPFClient.Workers.UI（工作人员管理模块的视图模型和视图）
  • ...
  • WPFClient.Workers.Entities（ui，biz和data层共享的实体）
• 其他模块（例如合同，访问，......）

持久层的具体实现：

• WPFClient.Data.SQLite（引用一个或所有模块的X.Data和X.Entities dll的具体持久层）
• WPFClient.Data.SQLServer（引用一个或所有模块的X.Data和X.Entities dll的具体持久层）
• WPFClient.Data。????

项目之间的参考是：

• ModuleX.UI - ＆gt; ModuleX.BIZ和ModuleX.Entities
• ModuleX.BIZ - ＆gt; ModuleX.Entities和ModuleX.Data
• ModuleX.Data - ＆gt; ModuleX.Entities
• ... Data.SQLIte - ＆gt; ModuleX.Entities，ModuleX.Data，ModuleY.Entities，ModuleY.Data，...

当然，具体实现将通过ServiceLocator机制解决。

我没有找到任何像这样写的LOB应用程序的例子。我读了很多，关于工作单位和实体框架的文章很多，CQRS，等等等等，但是理论太过分了！

这种架构有什么问题？是否有更好的解决方案或现实世界的例子？

为了更清楚：假设我必须用他的工作历史（或具有多个命令项的经典示例顺序）保存工人。如果商业层“知道”它必须保存在多个存储库中，这意味着商业层知道持久性机制，因此它知道太多。但是如果biz层只是将命令（SaveWorkerInfo或SaveOrderInfo）传递给持久层而不是知道太多的持久层而且biz层只执行验证（我认为这是CQRS样式）。

非常感谢，我知道这是一篇很长的帖子！

Answer 1

我认为你的初稿看起来不错。请查看this视频，了解如何组织应用程序的结构。在你的上一个问题中，你提到了存储库等，我认为你对domain driven design有一些了解。我似乎需要重新考虑你的aggregates。阅读this CQRS简介，您将知道该命令永远不会到达您应用程序中的数据层。