Caliburn.Micro、MVVM 和业务层

Question

我正在使用 MVVM 模式构建 WPF 应用程序，而 Caliburn.Micro 是促进开发的框架选择。

与传统的基于 MVVM 的应用程序不同，我在 ViewModel (VM) 层下方添加了一个业务层 (BL) 来处理特定业务案例的逻辑。 VM 留下了数据绑定和简单的转换/表示逻辑。 BL 下方是一个额外的数据访问层 (DAL)，它封装了下面使用 Entity Framework 构建的数据模型 (DM)。

我对 WPF、MVVM 都很陌生，当然，我对 Caliburn 几乎一无所知。我已经阅读了大量关于 Caliburn 用法的问题和答案，现在尝试在我的应用程序中使用我迄今为止所学的知识。

我的问题是：

1. 上面的分层架构听起来还可以吗？
2. 在应用程序引导程序中，我们可以注册所有稍后将使用的服务（如EventAgreggator (EA)、WindowManager 或额外的安全和验证服务）以及所有相关的 VM，这是否正确？这些应该通过构造函数注入到 VM 实例中（假设我将使用 SimpleContainer）。因此，从任何经过适当设计和实例化的 VM 中，我们都可以准备好使用这些服务。如果我理解正确的话，Caliburn 和它的IoC 保持一种全局状态，以便不同的虚拟机可以使用和共享它。
3. 导航：我知道这个话题已经讨论过很多次了。但只是为了确保我做对了：会有一个ShellViewModel 作为整个应用程序的主窗口，动态加载不同的虚拟机（或屏幕）。每个 VM 可以继承 Screen 或 ViewModelBase 或 NotifyChangedBase。当我进入时，假设VM A 并想切换到VM B。我会从VM A 内部向ShellViewModel 发送一条消息（使用EA），说我想更改为B。ShellViewModel 接收消息并重新加载其CurrentViewModel 属性。维护要加载的 VM 列表的适当数据结构应该是什么？ Conductor 或 WindowManger 这样的东西怎么会进来？
4. 可以/应该Caliburn 以一种或另一种方式支持对数据库的访问（通过 EF）。或者此访问权限应仅向 VM 和/或 BL 公开？

非常感谢！

Answer 1

与传统的基于 MVVM 的应用程序不同，我在 ViewModel (VM) 层下方添加了一个业务层 (BL)

这是标准情况。 ViewModel 不能/不应该包含被认为是 MVVM 中模型的一部分的业务逻辑（MVVM 中的模型被认为是一个层，而不是对象或数据结构）。 ViewModel 仅用于表示逻辑。

1. 是的，只要您的业务（域）层不依赖于 DAL（不引用它的程序集）。存储库接口应该在业务层中定义，它们的实现在数据访问层中。

2. 是的，Bootstrapper 是您构建对象图的地方（配置 IoC 容器）。

   注册 ViewModel：取决于 IoC 框架。一些框架允许您解析未注册的类型，只要它们不是抽象或接口（即 Unity）。不确定Caliburn，没用过。如果 IoC 支持，则无需注册。

3. 一种可能的方法。不过，我更喜欢导航服务，它更适合将参数传递给尚未实例化的视图和窗口，并且您始终知道只有一个对象在处理它。

   对于消息，可能有 0、1 或许多对象在监听它。由你决定

4. 您对数据库的支持访问是什么意思？您可以使用它将您的存储库和/或服务注入到您的 ViewModel 中，除了它没有太多与数据库相关的东西。