Caliburn.Micro，MVVM和业务层

Question

我正在使用MVVM模式构建WPF应用程序，选择了Caliburn.Micro框架来提高开发效率。

与传统的基于MVVM的应用程序不同，我在ViewModel (VM)层下添加了业务层(BL)以处理特定业务情况的逻辑。 VM仅剩下数据绑定和简单的转换/呈现逻辑。在BL下面是一个额外的Data Access层(DAL)，该层封装了由Entity Framework构建的Data model(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接收消息并重新加载其CurrentViewModel属性。 应如何管理要加载的VM列表的合适数据结构？Conductor或WindowManger之类的东西如何进入场景?
4. Caliburn能否以某种方式支持对数据库的访问（通过EF）。 或者这种访问只应向VM和/或BL公开？

非常感谢！

- tab87vn

Answer 1

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

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

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

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

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

3. 这是一种可能的方法。我更喜欢导航服务，因为它对于向尚未实例化的视图和窗口传递参数更有效，并且您始终知道有一个对象正在处理它。

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

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

- Tseng