【51CTO 精选译文】在本系列文章中,我们将通过一个简单的 Silverlight 3.0 实例向
您展示如何通过使用当前成熟的应用程序设计模式,即“模型—视图—视图模型” 模式,
来实现用户界面层与其相关数据层的分离设计。本文原文讲述内容针对 Silverlight 2.0,
不过据译者观察,Silverlight 2 和 Silverlight 3 在架构方面没有太大变化,此文内容可
以通用。
一、引言
当前,Silverlight 的正式版本为 3.0,基于此技术的应用程序数量正在急剧增长。但
是,到目前为止,Silverlight 3.0 模板所支持的基本结构却意味着用户界面(UI)与其所
需要的任何数据间是紧密集成的关系。虽然这种紧密集成的技术对于学习 Silverlight 本身
来说是有益的,但是,当使用之来开发真实的应用程序时却会为测试、重构和维护等工作带
来巨大的困难。
二、紧耦合设计带来的问题
在设计 Silverlight 应用程序时,我们所关心的核心问题是紧密耦合问题。造成这种紧
密耦合的原因是:开发过程中,我们很容易把应用程序的各个层混合在一起。当一个层中拥
有另一个层中所需要的大量信息时,说明你的应用程序正处于紧密耦合状态。我们不妨来考
虑一个简单的 Silverlight 数据输入应用程序,假定此程序允许你查询某个城市的待售房屋
信息。在一个紧密耦合的应用程序中,您可能会在用户界面中的一个按钮的 Click 事件处理
程序中定义执行搜索的查询操作。于是,当规则改变或搜索语义发生变化时,无论是数据层
还是用户界面层都必须进行相应的更新。
这种情况势必导致代码质量和编码复杂性的问题。每当数据层改变时,你必须进行同步
更新并测试应用程序,以便确保所做的更改没有与发生的变化相违背。当一切都紧密地绑在
一起时,在一个应用程序某一部分中的任何变化都可能会导致在代码的其他部位发生相应的
变化。当你使用 Silverlight 开发简单的程序,例如一个电影播放器或菜单组件,紧密耦合
的应用程序组件不太可能造成大的问题。但是,随着项目尺寸的不断增大,你会感觉到麻烦
越来越多。
另一个问题是单元测试的问题。当一个应用程序是紧密耦合型的,你只能进行应用程序
的功能(或用户界面)测试。同样,这对于一个小项目不是什么问题,但是随着项目规模和
复杂性的不断增长,能够分层测试应用就变得非常重要。请记住,单元测试并不只是确保当
在一个系统中使用它时此单元能够工作,而是需要确保它能够在一个系统中继续不断地使用。
对系统各个局部进行单元测试可以保证,随着系统的变化,在这个过程中会更早期地发现问
题,而不是和仅使用功能测试那样在最后才发现问题。因此,回归测试(例如,针对一个系
统的每一个版本都进行单元测试)就变得至关重要—它可以确保系统中新增加的小变化不至
于造成一系列的错误。