我正在使用 MVVM 模式构建 WPF 应用程序,而 Caliburn.Micro 是促进开发的框架选择。
与传统的基于 MVVM 的应用程序不同,我在 ViewModel (VM) 层下面添加了一个业务层 (BL) 来处理特定业务案例的逻辑。 VM 只剩下数据绑定(bind)和简单的转换/表示逻辑。 BL 下面是一个额外的数据访问层 (DAL),它封装了使用 Entity Framework
构建的数据模型 (DM)。
我对 WPF、MVVM 都很陌生,当然,对 Caliburn
几乎一无所知。我已经阅读了大量关于 Caliburn
用法的问题和答案,现在尝试在我的应用程序中使用我目前学到的知识。
我的问题是:
- 上面的分层架构听起来不错吗?
- 在应用程序 Bootstrap 中,我们是否可以注册所有稍后将使用的服务(如
EventAgreggator
(EA)、WindowManager
或额外的安全和验证服务)是否正确),以及所有相关的虚拟机?这些应该通过构造函数等注入(inject)到 VM 实例中(假设我将使用 SimpleContainer)。因此,从任何经过适当设计和实例化的 VM,我们都可以准备好这些服务以供使用。如果我理解正确,Caliburn
及其IoC
维护一种全局状态,以便不同的 VM 可以使用和共享它。 - Navigation:我知道这个话题已经被讨论过很多次了。但只是为了确保我做的是正确的方式:有一个
ShellViewModel
充当动态加载不同 VM(或屏幕)的整个应用程序的主窗口。每个 VM 都可以继承Screen
或ViewModelBase
或NotifyChangedBase
。当我进入时,比方说,VM A
并想切换到VM B
。我从VM A
内部向ShellViewModel
发送一条消息(使用 EA),说我想更改为 B。ShellViewModel
收到消息并重新加载其CurrentViewModel
属性。维护要加载的 VM 列表的正确数据结构应该是什么?Conductor
或WindowManger
之类的东西如何发挥作用? - 可以/应该
Caliburn
以一种或另一种方式支持对数据库的访问(通过 EF)。或者这种访问应该只对 VM 和/或 BL 公开?
非常感谢!
最佳答案
Different from a conventional MVVM-based application, I add a business layer (BL) below the ViewModel (VM) layer
这是标准情况。 ViewModels 不能/不应该包含被认为是 MVVM 中模型的一部分的业务逻辑(MVVM 中的模型被认为是一个层,而不是一个对象或数据结构)。 ViewModel 仅用于表示逻辑。
是的,只要您的业务(域)层不依赖于 DAL(不引用它的程序集)。存储库接口(interface)应该在业务层中定义,它们的实现在数据访问层中。
是的,Bootstrapper 是您构建对象图(配置 IoC 容器)的地方。
注册 ViewModels:取决于 IoC 框架。某些框架允许您解析未注册的类型,只要它们不是抽象类型或接口(interface)(即 Unity)即可。不确定 Caliburn,还没有使用过它。如果 IoC 支持,则无需注册。
一种可行的方法。不过,我更喜欢导航服务,它更适合将参数传递给尚未实例化的 View 和窗口,而且您始终知道只有一个对象在处理它。
对于消息,可能有 0 个、1 个或多个对象在监听它。由你决定
支持访问数据库是什么意思?您可以使用它将您的存储库和/或服务注入(inject)您的 ViewModel,除此之外没有太多与数据库相关的内容。
关于mvvm - Caliburn.Micro、MVVM 和业务层,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/35558193/