WPF-MVVM(一)

MVVM(Model-View-ViewModel)

first step:

http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

这个一篇介绍MVVM的文章网址。

====

WPF Apps With The Model-View-ViewModel Design Pattern summary:（文章主要内容）

一、MVVM的目的

This approach helps avoid the cognitive chaos mentioned earlier. 

利用这种方式(MVVM)可以避免之前提到的概念的混乱。（之前提到：指的的是在开发复杂系统中各个部分代码的命名，如果没有MVVM每个人都会不同，有了之后大家可以达成共识，或者大家可以有一个可以参考的架构，更加快速、准确的理解开发的程序。）
Instead, you can happily exist in a state of controlled chaos, 

相反，你可以很愉快的和这个控制了的混乱、冲突相处，
which is the natural state of affairs in most professional software development projects! 

这种开发的状态是大多数专业软件开发项目中的自然（或者叫应该的）状态

二、MVVM的进化历程：

The history of MVVM (MVVM模式的历史)
MVP(Model-View-Presenter):（早期的可能叫MVP，下面是对MVP的一个形象解释）
What you see on the screen is the View, （View指的就是你在屏幕上看到的）
the data it displays is the model, （Model指的就是View显示的数据）
and the Presenter hooks the two together. （Presenter将View和Model挂在了一起）

可供参考的文章地址：
(1)In Glenn Block's excellent article "Prism: Patterns for Building Composite Applications with WPF" in the September 2008 issue
    http://msdn.microsoft.com/zh-cn/magazine/cc785479.aspx
（介绍 使用WPF构建组合应用程序的模式）
(2)If you would like to learn more about the Model View Presenter, I suggest you read Jean-Paul Boodhoo's August 2006 Design Patterns column.
    http://msdn.microsoft.com/zh-cn/magazine/cc188690%28en-us%29.aspx
（关于MVP模式介绍）

(3)In 2005, John Gossman, currently one of the WPF and Silverlight Architects at Microsoft, unveiled the Model-View-ViewModel (MVVM) pattern on his blog.
    http://blogs.msdn.com/b/johngossman/archive/2005/10/08/478683.aspx
（关于MVVM的介绍，这个在05年就有了！！！）

(4)Back in 2004, Martin Fowler published an article about a pattern named Presentation Model (PM)
    http://martinfowler.com/eaaDev/PresentationModel.html 

（关于PM的介绍）

we can see some development path of MVVM.（MVVM的一个发展的轨迹）
PM(Martin Fowler)-->may be intial stage MVVM(John Gossman)-->MVP(Jean-Paul Boodhoo)-->may be further discussion of MVVM(Glenn Block)-->current MVVM
2004 -->2005 -->2006 -->2008 --> now

三、MVVM受到WPF开发人员喜爱的原因

Why WPF Developers Love MVVM: （WPF开发人员喜欢MVVM的原因）

The features of WPF that make the MVVM pattern so usable are: （WPF的特性使得MVVM模式非常容易实现）
(1)data binding infrastructure（数据绑定基础结构，也可以说是一种机制吧，其实无论现在讲的MVVM，还是之前看到的MVP都是在讨论一个问题，就是“数据”，“用户界面”，以及“如何组织数据和用户界面”的问题，而WPF这种数据绑定的机制，无形中帮我们做了一步本应该由我们自己做的事，所以说具有实现MVVM模式的天生优势）

(2)data templates  （数据模板，可以通过这种方式将数据很好的表现到用户界面上）
(3)the resource system（资源系统）

介绍WPF数据模板的文章地址
You can learn more about binding and data templates in my July 2008 article,
"Data and WPF: Customize Data Display with Data Binding and WPF."
http://msdn.microsoft.com/zh-cn/magazine/cc700358.aspx

介绍WPF中命令模式支持的文章（暂时这么理解吧）
If you aren't familiar with commanding, I recommend that you read Brian Noyes's comprehensive article,
"Advanced WPF: Understanding Routed Events and Commands in WPF," from the September 2008 issue
http://msdn.microsoft.com/zh-cn/magazine/cc785480.aspx


the pattern(MVVM) is also popular because ViewModel classes are easy to unit test
MVVM 模式很容易进行单元测试，也是它流行起来的另一个原因；

In addition to promoting the creation of automated regression tests.

另外，MVVM模式提升了自动回归测试。（也就是说用MVVM模式，可以很容易的实现自动回归测试）

you can often decide whether something should be in the view or the ViewModel
by imagining that you want to write a unit test to consume the ViewModel.

If you can write unit tests for the ViewModel without creating any UI objects,

you can also completely skin the ViewModel because it has no dependencies on specific visual elements.
在MVVM模式开发中，你可能经常会碰到这样的判断，就是某些东西，是要放到View中呢？还是要放到ViewModel中？

这时，一个好的方法，或者说可行的方法就是你设想你正在编写一个ViewModel的单元测试，如果你能够在没有创建

任何UI的对象的前提下写出了单元测试的代码，可也就可以在ViewModel上面放置任何的皮肤，因为，ViewModel没有

依赖任何可视元素。

（上面这一大段话，其实就是讲我们应该把独立于任何可视化元素的代码放置到ViewModel中）

using MVVM makes it much easier to create a smooth designer/developer workflow.

使用MVVM模式使得创建UI设计师和应用逻辑开发人员的工作流更加容易。（也就是说UI设计和应用逻辑实现可以分离，各司其职，热后通过共同的接口进行合作）

The development team can focus on creating robust ViewModel classes,
and the design team can focus on making user-friendly Views.

这样应用程序开发团队可以集中注意力在创建强壮的ViewModel类，而设计团队也可以集中注意力在创建更加友好的用户界面

(So nice!! Clear responsiblities!! It's the one which I want.)（这里是我自己的感受，嘻嘻！！！）

subtle bugs is ugly。（难以察觉的，精微的 bug是丑陋的，可能是由我们晦涩的程序逻辑产生的，所以我们在开发程序时，尽量采用易于

理解的程序逻辑；而切忌使用那些晦涩，大家不用的逻辑或语法。当然“大家”中不包含顾洛寡闻者~~）