杂七杂八——适用于WPF的设计模式

简介:
小序:
当梦想突然有一天变成现实的时候,我们会有什么样的感觉?惊喜自然是少不了的。惊喜过后呢?剩下的就是要接受现实了——就像小鬼当家里的小家伙。
 
正文:
有朝一日能把软件的UI设计和逻辑设计分开,这是多年来程序开发人员的梦想。如今,这个梦想被XAML+C#实现了,大家都很开心。开心过后,问题来了——Binding与依赖属性再好使、路由事件和命令再灵活,如果不加约束地乱用和过度使用,一样会导致软件架构的不稳固以及招致维护、测试和调试方面的麻烦。
 
那么,怎样才能用好WPF带来的结构上的新特性呢?我们需要做的,不是从头开始创造一个新模式,而是需要把WPF的新特性揉合进现有的、成熟的开发框架中去。下面,让我们开始WPF开发框架的演进之旅!
 
MVC时代
现有的开发框架林林总总,但万变不离其宗,这个“宗”指的就是最为经典的MVC模式。插一句,有一次面试一位候选人,当我问及这个模式的时候,这位兄台干脆地回答到:“MCV!”,于是我就让他“展开”讲讲了:p
 
MVC框架出现的年代比较早,生成软件UI和逻辑用的是同一种语言(比如C++/Java/Delphi),灵活性基本上是局限在对于同一块数据(由Model暴露出来)使用不同的视图(View,也就是UI)展现给用户。
 
MVP时代
随着互联网的发展,程序不再是一个个只能跑在特定操作系统上的代码块,成千上万的用户希望使用相同的程序共享相同的数据。操作系统平台一时半会是统一不起来了,A厂商程序跨到B厂商平台上的那只脚也往往被B厂商穿上一只小鞋。万般无奈下,开发人员只好诉诸于所有操作系统平台的交集——浏览器——赶鸭子上驾般地做起了程序的宿主;HTML也没被放过,本来用于简单呈现页面的标签语言却被CSS、JavaScript、XML等等武装到了牙齿。
 
Anyway,程序可以跑在浏览器里了,需要开发人员重新把程序开发一遍吗?人们发现,无论程序的前端(UI部分)跑在哪里,它的后台逻辑是不会改变的。于是人们开始想:我怎样才能把UI和逻辑解耦并对逻辑层加以复用呢?必需要在设计或者重构的时候考虑上这一点才可以。
 
于是,在MVC的基础上,人们向前推进了一步——MVP模式诞生了(有玩儿文字游戏的嫌疑哦!)。Interface这个词被译成“接口”之后就丢了些原本的意思。如果还把当译成“界面”,那么这个意思就能找回来了——现实世界也是这样,当物体受到接力的时候,凡是有界面的地方就是最容易被撕下来的地方。因此,interface这个词在译成中文时,“接口”传达的是其可以作为公共约束(契约)的一层意思;“界面”则能传达解耦的一层意思。
 
在MVP模式中,为了让UI层能够从逻辑层上“撕”下来,设计师们在UI层与逻辑层之间加了一层interface。无论是UI开发人员还是数据开发人员,都要尊重这个契约、按照它进行设计和开发。这样,理想状态下无论是Web UI还是Window UI就都可以使用同一套数据逻辑了。
 
MVVM时代
现在,WPF来了,它带来了3D、动画、音频视频……这导致了UI的变化将更加细节化、可定制化。同时,在技术层面,WPF也带来了诸如Binding、Dependency Property、Routed Events、Command、DataTemplate、ControlTemplate等新特性。我们怎样才能立足于原有MVP框架、把WPF的新特性揉合进去,以应对客户复杂的需求呢?
 
图说MVP与MVVM
 
MVC模式大都已经非常熟悉了,咱就不说了。让我们看看它的升级版——MVP
 
 
 
从这张图上我们可以看出如下几点:
1. IView这个interface层帮助我们把各类UI与逻辑层解耦
2. IView这层同时也为自动化测试提供了入口(从UI层进入自动化测试,太麻烦了)
3. 传统的、由WinForm/Web Form/MFC等编写的UI是通过事件(本质是Windows 消息)与IView层沟通的。
4. WPF与IView层的沟通,最佳的手段是使用Binding,当然,也可以使用事件
5. Presenter层要实现IView,多态机制可以保证运行时UI层显示恰当的数据。比如Binding,在程序中,你可能看到Binding的Source是某个interface类型的变量——实际上,这个interface变量引用着的对象才是真正的数据源
6. 可有可无的Control……有的话,就当是留个纪念吧,原版的MVP图里是没有Control的,Control被Presenter取代
7. 这里的Presenter有点歧义之虞,就我个人而言,感觉Presenter是UI里的东西。
 
我们再来看MVVM
 
同样有几点注意:
1. 当我们只关注MVP模式与WPF结合的应用方式时,MVP就变成了MVVM。
2. 借鉴MVP的IView层,养成习惯。原版MVVM图里是没有这层的,但我会在程序里加上这层。
3. View Model听起来比Presenter要贴切得多
4. 我会把一些跟事件、命令相关的东西放在Controler里
 
 
就这些了~~没什么新鲜玩艺儿。




本文转自 水之真谛 51CTO博客,原文链接:http://blog.51cto.com/liutiemeng/121347,如需转载请自行联系原作者
目录
相关文章
|
前端开发 C# 设计模式
“深度剖析WPF开发中的设计模式应用:以MVVM为核心,手把手教你重构代码结构,实现软件工程的最佳实践与高效协作”
【8月更文挑战第31天】设计模式是在软件工程中解决常见问题的成熟方案。在WPF开发中,合理应用如MVC、MVVM及工厂模式等能显著提升代码质量和可维护性。本文通过具体案例,详细解析了这些模式的实际应用,特别是MVVM模式如何通过分离UI逻辑与业务逻辑,实现视图与模型的松耦合,从而优化代码结构并提高开发效率。通过示例代码展示了从模型定义、视图模型管理到视图展示的全过程,帮助读者更好地理解并应用这些模式。
360 0
|
C# 设计模式
WPF封装控件时 检测是否在设计模式中
原文:WPF封装控件时 检测是否在设计模式中 版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/Vblegend_2013/article/details/81984986 ...
760 0
|
C# 设计模式
WPF在在设计模式,使用动态样式
原文:WPF在在设计模式,使用动态样式 1.问题分析 WPF有时候要用到主题样式,比如颜色主题(红色、黄色之类的)通常是key相同,而value不同,比如会这么写: Background="{DynamicResource BackgroundColor}"    主题切换通常在不同的资源文件xaml里面,这时候,如果想在设计时(设计视图)里看看主题,往往得写些临时代码,当编译的时候还得把临时代码删除。
1327 0
|
XML 前端开发 C#
Silverlight/WPF/Windows Phone 开发之MVVM设计模式之入门
1、新建一个WPF、Silverlight或Windows Phone的项目。 2、在项目中新建几个文件夹,Models、Views、ViewModels、Data、Service、Commands。
892 0
|
C# 开发者 Windows
基于Material Design风格开源、易用、强大的WPF UI控件库
基于Material Design风格开源、易用、强大的WPF UI控件库
633 0
浅谈WPF之装饰器实现控件锚点
使用过visio的都知道,在绘制流程图时,当选择或鼠标移动到控件时,都会在控件的四周出现锚点,以便于修改大小,移动位置,或连接线等,那此功能是如何实现的呢?在WPF开发中,想要在控件四周实现锚点,可以通过装饰器来实现,今天通过一个简单的小例子,简述如何在WPF开发中,应用装饰器,仅供学习分享使用,如有不足之处,还请指正。
297 1
|
前端开发 C# 容器
浅谈WPF之控件拖拽与拖动
使用过office的visio软件画图的小伙伴都知道,画图软件分为两部分,左侧图形库,存放各种图标,右侧是一个画布,将左侧图形库的图标控件拖拽到右侧画布,就会生成一个新的控件,并且可以自由拖动。那如何在WPF程序中,实现类似的功能呢?今天就以一个简单的小例子,简述如何在WPF中实现控件的拖拽和拖动,仅供学习分享使用,如有不足之处,还请指正。
375 2
|
开发框架 缓存 前端开发
循序渐进介绍基于CommunityToolkit.Mvvm 和HandyControl的WPF应用端开发(11) -- 下拉列表的数据绑定以及自定义系统字典列表控件
循序渐进介绍基于CommunityToolkit.Mvvm 和HandyControl的WPF应用端开发(11) -- 下拉列表的数据绑定以及自定义系统字典列表控件
|
C# 开发者 Windows
一款基于Fluent设计风格、现代化的WPF UI控件库
一款基于Fluent设计风格、现代化的WPF UI控件库
312 1