浅谈MVVM数据绑定的耦合性.docVIP

浅谈MVVM数据绑定的耦合性 　　【摘 要】复杂软件需要清晰合理的架构设计，否则会给前期开发和后期维护带来极大的困难。各类框架的应运而生，重要目的之一就是降低软件的耦合度以获得良好的性能。本文围绕近年来流行度较高的MVVM架构，简单介绍了其原理和特点，针对MVVM数据绑定的耦合性，分别例举逐一属性绑定、对象绑定和集合绑定，并针对不同的绑定配置方式分析了耦合性。 　　【关键词】MVVM 数据绑定 耦合 　　对软件来说，最基本、最核心的内容是数据，所有代码层次的划分都是围绕数据设计的。业务逻辑层是为了实现对数据的增删改查，各类界面技术是为了更好地呈现数据。随着软件复杂度的提高，要想降低数据层、业务逻辑层及界面层的耦合度，就需要良好的架构设计。ORM等框架实现了业务逻辑层和数据层之间的解耦合，另有一批框架用来解决业务逻辑层和视图之间的耦合问题，MVVM就是其中之一。 　　1 认识MVVM 　　Model-View-ViewModel（MVVM，模型-视图-视图模型）是一种架构模式，如图1所示。MVVM的目标是将几乎所有程序代码从视图中移除（更加彻底的代码后置）。交互设计师只需专注于使用XAML（视图）表达用户体验需求，并创建视图和视图模型的绑定；而模型和视图模型则由程序员进行开发和维护。 　　MVVM的视图具有独立性，其中的控件能够管理部分用户输入并且自行反应。用户输入经过视图底层系统的处理和分发，多以事件的形式被后台用户程序所感知。视图模型包含概念模型而不是数据模型，所有业务逻辑和其它操作都是在模型和视图模型里完成的。 　　长久以来，在非MVVM架构中直接编写代码存在两个问题。一，View中有些控件的数据类型和Model中的属性类型不同。例如性别，Model中通常设置为bool类型；而View中呈现的是“男”、“女”这样的字符串，这就需要额外的代码进行转换。而转换代码如果放在View中会增大软件的耦合度（View上不应出现逻辑代码）；放在Model中，会导致Model臃肿庞大。二、事件驱动开发中的复用问题。Winform开发中的事件驱动因其易于理解和实现而被广泛接受，问题就是多种同类事件并存，后期维护繁重，且代码复用性相对较差。 　　Model和View中间的辅助角色――ViewModel较好地解决了上述两个问题。它帮助View和Model之间进行数据转换，并保证数据类型适当。同时它也将View的多种命令绑定到Model中相同的处理方法上，使得这些命令中绑定的方法可以被其他View复用。与同类架构模式（MVP、MVC）相比，MVVM架构唯一不同的特点是它采用双向绑定，即View中的变动会自动反映在ViewModel中，反之亦然。 　　2 MVVM的数据绑定 　　MVVM的一个主要特征是，通过Binding机制由ViewModel指示View如何作变更；用户与ViewModel的交互通过Command来实现，这时只需View指导ViewModel即可，而ViewModel不必关心View如何展示和展示什么，它只需提供属性（要绑定的数据和Command）并实现INotifyPropertyChanged。少了一个方向的依赖，代码自然更简洁清晰。 　　View中的控件存在一个属性“DataContext”，负责为控件指定数据源头。DataContext属性给控件指定一个后台模型，就是该控件的数据来源。ViewModel就是这个后台模型，给View中的控件提供用于显示的数据。而ViewModel提供的数据应该来自于背后的Model。所以，三者的关系是根据View中显示的数据是何种Model，来定义ViewModel。 　　Model中的某个类要成为真正的数据源，需要实现以下两个步骤。 　　（2）让该类实现INotifyPropertyChanged接口。实现该接口的目的是当数据源的属性值改变后通知Binding（使其知道源数据变了并进行联动协同），以便Binding把数据传输给目标。实际上，这个动作本质上还是运用了事件机制，只是掩盖在底层，不用程序员去写代码。 　　这里面蕴含了“数据驱动界面”的模型。在这里，Names属性值是数据源，文本框tb1用来显示数据，Names属性值驱动文本框tb1的Text进行改变；人为改变文本框tb1的Text属性值，也会被送回到person对象的Names属性上去。这里的Text属性也叫“依赖式属性”，就是它本身没有值，它的值“依赖”在其它对象的属性值上，通过Binding进行传递和转换。这样做的好处是，随便给Binding指定一个数据源，只要这个数据源有名为“Names”的属性，Binding就会自动提取它的值并传输给Text。 　　3 绑定的耦合性分析 　　不同配