在我的公司（第一次），我们正在使用 WPF 用 C# 开发一个相当大的业务应用程序。我决定采用类似于 Microsoft PRISM 中的 UI 模块化方法，但我对如何开发业务和数据层摸不着头脑。
我需要至少支持两个数据库：用于客户端/服务器安装的 SQL Server 和用于单用户安装的 SQLite，但我希望为其他数据库或云/rest 持久性解决方案做好准备。未来我们可能不得不开发一个网页版和一个 UniversalApp 版！
我正在考虑的解决方案是：
- WPFClient.MainShell (exe)
其他 shell dll（引导，动态模块加载，...）
公司模块：
- WPFClient.Companies.UI（视图模型和视图）
- WPFClient.Companies.BIZ（用于验证的管理器 obj，对持久层的调用，...）
- WPFClient.Companies.Data（持久层的通用接口）
- WPFClient.Companies.Entities（在 ui、biz 和数据层之间共享的实体）
工人模块
- WPFClient.Workers.UI（工人管理模块的视图模型和视图）
- ...
- WPFClient.Workers.Entities（在 ui、biz 和数据层之间共享的实体）
- 其他模块（例如合同、访问等）
持久层的具体实现：
- WPFClient.Data.SQLite（引用一个或所有模块的 X.Data 和 X.Entities dll 的具体持久层）
- WPFClient.Data.SQLServer（引用一个或所有模块的 X.Data 和 X.Entities dll 的具体持久层）
- 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 样式）。
非常感谢，我知道这是一篇很长的文章！