Caliburn.Micro、MVVM和业务层

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

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

实体框架构建的数据模型（DM）

我对WPF和MVVM都是新手，当然，我对Caliburn几乎一无所知。我已经阅读了大量有关Caliburn

用法的问题和答案，现在我正在尝试在我的应用程序中使用我所学到的知识

我的问题是：

上面的分层架构听起来可以吗

在应用程序引导程序中，我们可以注册以后将要使用的所有服务（如

eventagregator

（EA）、

WindowManager

或额外的安全和验证服务）以及所有相关的虚拟机，这对吗？这些应该通过构造函数注入到VM实例中（假设我将使用SimpleContainer）。因此，通过正确设计和实例化的任何VM，我们都可以准备好使用这些服务。如果我理解正确，

Caliburn

及其

IoC

保持一种全局状态，以便不同的虚拟机可以使用和共享它

导航：我知道这个话题已经讨论过很多次了。但为了确保我的做法正确：将有一个

ShellViewModel

作为整个应用程序的主窗口，动态加载不同的VM（或屏幕）。每个VM可以继承

屏幕

或

视图模型库

或

通知变更数据库

。当我在的时候，比如说，

vma

并想切换到

vmb

。我会从

vma

内部向

ShellViewModel

发送一条消息（使用EA），表示我想更改为B。

ShellViewModel

接收消息并重新加载其

CurrentViewModel

属性。要维护要加载的VM列表，正确的数据结构应该是什么？像

Conductor

或

WindowManger

这样的东西是怎么进来的

可以/应该以某种方式支持对数据库的访问（通过EF）。或者该访问应该仅对VM和/或BL公开

非常感谢

与传统的基于MVVM的应用程序不同，我在ViewModel（VM）层下面添加了业务层（BL）

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

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

是的，引导程序是构建对象图（配置IoC容器）的地方

注册ViewModels：取决于IoC框架。一些框架允许您解析未注册的类型，只要它们不是抽象或接口（即Unity）。卡利本不太清楚，没用过。如果国际奥委会支持，你不需要注册

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

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

对数据库的支持访问意味着什么？您可以使用它将您的存储库和/或服务注入到您的ViewModels中，不同的是它没有太多与DB相关的东西