在我的应用程序中,我正在使用我的工具正在管理的软件的 API。我有包含 16 个类的 DAL,其中 3 个是单例。我在.cs
文件中有一些逻辑并且XAML
偏离了方向。
我的问题是,我看到很多用 WPF 编写的应用程序应该使用 MVVM 的评论,这将使代码更具可用性和可读性,我可以将我的代码转换为 MVVM 吗?MVVM 的实际含义是什么(不是维基百科或手动定义)?
我也使用 SQL 查询并阅读了一篇关于 EF(实体框架)的论文,MVVM 和 EF 可以在同一个项目中共存吗?
在我的应用程序中,我正在使用我的工具正在管理的软件的 API。我有包含 16 个类的 DAL,其中 3 个是单例。我在.cs
文件中有一些逻辑并且XAML
偏离了方向。
我的问题是,我看到很多用 WPF 编写的应用程序应该使用 MVVM 的评论,这将使代码更具可用性和可读性,我可以将我的代码转换为 MVVM 吗?MVVM 的实际含义是什么(不是维基百科或手动定义)?
我也使用 SQL 查询并阅读了一篇关于 EF(实体框架)的论文,MVVM 和 EF 可以在同一个项目中共存吗?
MVVM 的实际含义是:UI 不是 Data。数据就是数据,用户界面就是用户界面。
这意味着您不应该以程序逻辑(通常称为业务逻辑)紧密耦合或依赖于 UI 组件状态的方式开发应用程序,而应使其依赖于数据项的状态(无论是模型,或视图模型)。
例如,在其他框架(如 winforms)中,如果您有一个包含文本框和按钮的屏幕,您通常会为按钮添加一个单击事件处理程序,然后从文本框中读取文本。在 MVVM 中,TextBox 的 Text 属性应该绑定到 ViewModel 中的字符串属性,按钮也应该绑定到 ViewModel 中的 Command。
这允许对 UI(即 ViewModel)进行抽象,因此,正如我之前所说,您的应用程序逻辑可以不依赖于 UI,而是依赖于它的抽象。
这允许 UI 和逻辑的大量可扩展性,并且还允许 UI 行为的几个方面的可测试性,因为大部分 UI 行为是在 ViewModel 中定义的。
MVVM 还有其他方面,但主要的实现是。
编辑:
为了答案的完整性,我将添加一个具体的例子:
1 - 非 MVVM WPF:
XAML:
<StackPanel>
<TextBox x:Name="txtLastName"/>
<Button Content="Click Me" Click="Button_Click"/>
</StackPanel>
后面的代码:
private void Button_Click(object sender, EventArgs e)
{
//Assuming this is the code behind the window that contains the above XAML.
var lastname = this.txtLastName.Text;
//Here you do some actions with the data obtained from the textbox
}
2 - MVVM WPF:
XAML:
<StackPanel>
<StackPanel.DataContext>
<my:MyViewModel/>
</StackPanel.DataContext>
<TextBox Text="{Binding LastName}"/>
<Button Content="Click Me" Command="{Binding MyCommand}"/>
</StackPanel>
视图模型:
public class MyViewModel
{
public string LastName { get; set; }
public Command MyCommand { get; set; }
public MyViewModel()
{
// The command receives an action on the constructor,
// which is the action to execute when the command is invoked.
MyCommand = new Command(ExecuteMyCommand);
}
private void ExecuteMyCommand()
{
//Only for illustration purposes, not really needed.
var lastname = this.LastName;
//Here you do some actions with the data obtained from the textbox
}
}
正如您在上面的示例中看到的,ViewModel 根本不包含对 View 的引用。因此,视图可以是任何东西,只要{Bindings}
它们保持在适当的位置。
神奇地使它们一起工作的DataContext
粘合剂是 WPF UI 元素的属性,它是所有绑定都将被解析的对象。
还有其他事情,例如 ViewModel 中的属性更改通知以启用双向绑定,但这超出了此答案的范围。
还要记住,MVVM 是一种设计模式,而 WPF 是一种框架。MVVM 目前也被应用于其他技术(目前有很多关于 MVVM 用于 web 的讨论,包括 JavaScript 和类似的东西)
我建议您阅读其他答案中提到的书籍以及本教程以了解更多特定于 WPF 的方面。
我的问题是,我看到很多用 WPF 编写的应用程序应该使用 MVVM 的评论,这将使代码更具可用性和可读性,我可以将我的代码转换为 MVVM 吗?
没有要求您需要使用 MVVM 模式 - 没有。您需要考虑您正在构建的应用程序的复杂性和开发组的技能组合。一般来说,如果它是一个小型或小型/中型应用程序,那么 MVVM可能会过度设计。如果团队的技能/才能不适合单独的演示模式,那么 MVVM 可能不是一个好的决定。
如果操作正确,那么 MVVM 将为您提供您所读到的各种好处。相反,如果它做错了,那么它可能是一个开发和维护的噩梦——绝对不是更具可读性和可用性。从个人经验来看,我认为编写糟糕的代码隐藏应用程序比编写糟糕的基于 MVVM 的应用程序更容易。
当然,您可以将当前应用程序重写为 MVVM 模式。只需删除您的代码隐藏并将其放入您的视图模型、帮助程序类、存储库类、商务逻辑类等。不要陷入将所有内容都放入视图模型的陷阱,创建一个 MVVM 美化代码-在后面。
我还使用 SQL 查询,并阅读了一篇关于 EF(实体框架)的论文,MVVM 和 EF 可以一起留在同一个项目中吗?
当然,他们可以。请记住,EF 是一种数据访问技术,而 MVVM 是一种设计模式。您可能会在您提到的 DAL 类中使用 EF。
最后一个想法,如果你决定走 MVVM 路线,那么你应该考虑使用一个促进它的框架,比如Prism
. 哦,准备好接受相当多的学习和挫折。
我肯定会使用Unity 之类的框架研究DependencyInjection。
您的 Singleton 类可以注册到 DependencyInjection 容器并注入到其他类(例如 ViewModels)的构造函数中。其他需要定期实例化并注入类的 DAL 类也可以。
DependencyInjection 是开发大型企业软件应用程序时最重要的单一设计模式,适用于客户端和服务器代码。MVVM 是一个很好的模式,但不会解决与依赖耦合相关的整体应用程序复杂性问题。
这些是我特定于 MVVM 的
1) 增加视图的“混合性”(使用 Expression Blend 设计视图的能力)。这使得有幸拥有设计师和程序员的团队能够分离职责......每个人都可以独立工作。
2)“无视”视图逻辑。视图与在它们后面运行的代码无关,从而使相同的视图逻辑能够在多个视图中重复使用,或者使视图易于重组或替换。区分“行为”和“风格”之间的关注点。
3)没有重复的代码来更新视图。在代码隐藏中,您会看到到处都是对“myLabel.Text = newValue”的调用。使用 MVVM,您可以确保仅通过设置底层属性及其所有视图副作用来适当地更新视图。
4)可测试性。由于您的逻辑与您的视图完全无关(没有“myLabel.Text”引用),因此单元测试变得容易。您可以在不涉及视图的情况下测试 ViewModel 的行为。这也启用了视图行为的测试驱动开发,这使用代码隐藏几乎是不可能的。
就它们所解决的问题而言,其他两种模式实际上是不同的。您可以将 MVVM 与 MVP 和 MVC 一起使用(大多数优秀的示例都可以做到这一点)。
事实上,在我看来,MVP(带有被动视图,而不是监督控制器)实际上只是 MVVM 的一种变体。