WPF企业内训全程实录(中)

📅 2026/7/5 2:29:41
WPF企业内训全程实录(中)
. WPF开发模式提到WPF开发模式这里通常所说的是Presentation模式其他层的模式不在此列大家可能会立马想到MVC/MVP/MVVM模式1MVC模型视图控制器Model View Controller)2MVP模型视图表现类Model-View-Presenter3MVVM模型视图视图模型Model-View-ViewModel的确时下流行的就这三种常见的Presentation模式这三种模式又衍生了很多变种从根本上说这些模式是为了解决如下的几个问题1逻辑与UI紧密耦合更换UI上的显示往往需要更改很多逻辑代码正所谓“牵一发而动全身”。2应用程序状态的维护主要包括状态 (State) 逻辑 (Logic) 同步 (Synchronization)耦合太紧。3不能使不同的UI共享相同的逻辑复用问题。4要测试用户界面效果你需要做复杂的UI测试。5团队协作不能充分发挥因为耦合太紧的关系。6维护比较困难这也是由于耦合紧密且没有完整的单元测试。之前的C/SWinForm和B/SASP.NET/ASP.NET MVC我们已经习惯了MVC和MVP模式现在针对WPF和Silverlight的具体特征——它带来了3D、动画、音频、视频……这导致了UI的变化将更加细节化和可定制化。同时在技术层面上WPF和 Silverlight也带来了诸如Binding、 Dependency Property、Routed Events、Command、Attached Behavior依赖属性体系间接实现、DataTemplate、ControlTemplate等新特性。我们怎样才能立足于原有的技术框架并把WPF/Silverlight的新特性揉合进去以应对客户日益复杂且多变的需求呢那么MVVM模式就是一个不错的选择详见如下框架图图1在MVVM模式中你需要一个为View量身定制的model那么这个model实际上就是上图ViewModel。ViewModel包含所有UI所需要的接口、属性和命令这样只需要通过Binding使他们进行关联就可以使二者之间达到松散耦合所以这样一来UI就可以由UI专业人员用Design和Blend来实现当然很多效果还是需要用传统的制图软件所以我们都称这种想法叫理想状态代码人员也可以专心写他的逻辑和业务代码所以这样分工和协作变得更轻松、更愉快了。更漂亮的是View完全可以由Unit/Automatic Test所取代所以单元测试也变得相对简单。这对于我们的开发人员和测试人员无疑是一个很好的解脱同时也提高了系统的可测性、稳定性和维护性。数据绑定系统同时也提供了标准化的方式传输到视图的错误验证和输入验证但是个人觉得不是很好用所以我们在实际的项目当中会写一套自己的验证框架。讲到这里我们这里不得不引入下面这幅图我觉得它能阐述一些比较重要问题图2注此图引用自Robert McCarter的MVVM一文上面的这幅图表达了几个概念1Domain Model 始终是应用程序的核心必须投入大量精力按照面向对象的分析和设计 (OOAD) 最佳做法进行设计同时按照OOP进行开发。2Model、View 和 ViewModel 层之间实施严格的分离也强调了它们之间是一种松散耦合的关系。3每一层或者每一个模块都有自己完整的单元测试这样即提高了代码质量同时也增强了稳定性和可维护性。4不要为了MVVM而MVVM不要强调UI端不产生一句后台代码而把所有代码都扔进ViewModel因为有的操作如果不参与逻辑流程放在UI端处理会更好这也符合UI和逻辑隔离的最终原则。当然使用这个模式的时候我们还要注意很多细节这个是我们必须面对的比如我们怎么实现View和ViewModel关联、View和ViewModel如何通信、ViewModel与ViewModel如何交互、ViewModel和Model之间的弱关联、怎样用 Attached Behavior实现特定命令操作、怎样弹出UI、怎样实现导航、Validation的自定义设置、异步调用、延迟加载、性能优化、与传统技术的交互等等问题。八. WPF团队协作前面我们讲了WPF的开发模式针对不同的开发模式团队协作也会有一些具体的改变不管是MVC、MVP还是MVVM无疑都强调的是Presentation所以我们的域模型和底层操作都不会有所变化或者严格一点的说是只能影响到服务层/域模型之上的操作如果不考虑多系统分布式、ESB及SOA体系就可以分成以下六种角色专业美工人员整个系统的基调与样式、页面布局图、页面效果图、页面的样式与颜色、常用按钮图标、常用图标图片等等。XAML人员StyleTemplateTriggerResource用XAML代码书写另外强调和美工及ViewModel人员的交互与合作。ViewModel 主要封装领域模型暴露的接口然后提供给View所以这里强调UI和领域模型的一个适配作用。领域模型核心应用程序的核心必须投入大量精力按照面向对象的分析和设计 (OOAD) 最佳做法进行设计同时按照OOP进行开发。框架常用功能开发人员这里就包括MVVM框架的开发、维护以及扩展同时还包括数据底层访问、日志、异常、常用功能等。数据库开发和管理人员数据库库表的建立及维护、数据库脚本的创建及维护、数据库优化以及日常的数据操作问题。当然在开发中这六种角色也并不是完全分离的可以根据具体需求进行调整同时也可以根据项目的功能划分模块总之选择项目最合适的协作方式就行。