mvvm - Caliburn.Micro、MVVM 和业务层

Question

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

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

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

我的问题是:

1. 上面的分层架构听起来不错吗？
2. 在应用程序 Bootstrap 中，我们是否可以注册所有稍后将使用的服务(如 EventAgreggator (EA)、WindowManager 或额外的安全和验证服务)是否正确)，以及所有相关的虚拟机？这些应该通过构造函数等注入(inject)到 VM 实例中(假设我将使用 SimpleContainer)。因此，从任何经过适当设计和实例化的 VM，我们都可以准备好这些服务以供使用。如果我理解正确，Caliburn 及其 IoC 维护一种全局状态，以便不同的 VM 可以使用和共享它。
3. Navigation:我知道这个话题已经被讨论过很多次了。但只是为了确保我做的是正确的方式:有一个 ShellViewModel 充当动态加载不同 VM(或屏幕)的整个应用程序的主窗口。每个 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

Different from a conventional MVVM-based application, I add a business layer (BL) below the ViewModel (VM) layer

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

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

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

   注册 ViewModels:取决于 IoC 框架。某些框架允许您解析未注册的类型，只要它们不是抽象类型或接口(interface)(即 Unity)即可。不确定 Caliburn，还没有使用过它。如果 IoC 支持，则无需注册。

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

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

4. 支持访问数据库是什么意思？您可以使用它将您的存储库和/或服务注入(inject)您的 ViewModel，除此之外没有太多与数据库相关的内容。