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维护一种全局状态，以便不同的VM可以使用和共享它。
3. 导航：我知道这个话题已经讨论过很多次了。但只是为了确保我采取正确的方式：ShellViewModel充当整个应用程序的主窗口，动态加载不同的VM（或屏幕）。每个VM都可以继承Screen或ViewModelBase或NotifyChangedBase。当我进入时，让我们说VM A，并希望切换到VM B。我从VM A内部发送消息（使用EA）到ShellViewModel，说我想要更改为B. ShellViewModel收到消息并重新加载{{1}属性。什么是适当的数据结构来维护要加载的VM列表？ CurrentViewModel或Conductor之类的内容如何进入这个地方？
4. 可以/应该WindowManger以某种方式支持对数据库的访问（通过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，除了没有太多与数据库相关的东西。