WPF MVVM循序渐进

简单的三层架构示例和 GLUE代码问题
第一步：最简单的 MVVM 示例 - 把后台代码移到类中
第二步：添加绑定 - 消灭后台代码
第三步：添加执行动作和“INotifyPropertyChanged”接口
第四步：在 ViewModel 中解耦执行动作
第五步：利用 PRISM
WPF MVVM 的视频演示
从我们还是儿童到学习成长为成年人，生命一直都在演变。 对于软件架构， 同样适用这个道理， 从一个基础的架构开始， 随着每个需求和情境在不断演化。
如果你问任何一个 .NET 开发者， 什么是最小的基础架构， 首先浮现的就是"三层架构"。 在这个框架中， 我们把项目分为三个逻辑层次: UI 层， 业务逻辑层和数据访问层， 每一层都负责各自对应的功能。

UI 负责显示功能， 业务逻辑层负责校验， 数据访问层负责 SQL 语句。3层架构有如下的好处：
包容变化: 每一层的变化不会重复跨越到其它层次。
重用性: 增强可重用性， 因为每一层都是分离， 自包容的独立实体MVVM 是三层架构的一个演化。我知道我的经历不够证明这点， 但是我个人对 MVVM 进行了演化和观察。 那我们先从三层基础架构开始， 去理解三层架构存在的问题， 看 MVVM 架构是如何解决这些问题， 然后升级到去创建一个自定义的 MVVM 框架代码。 下面是本文接下来的路线图。

简单的三层架构示例和 GLUE(胶水) 代码问题
首先， 让我们来理解三层架构以及它存在的问题， 然后看 MVVM 如何解决这个问题。
直觉和现实是两种不同的事物。 当你看到三层架构的图， 你首先的直觉是每个功能可能都分布在各自层次。 但是当你实际编写代码时， 有些层次被强迫去做一些它们不应该做的额外的工作(破坏了SOLID 原则)。 如果你对 SOLID 原则还不熟悉可以参考这个视频: SOLID principle video(译者注: SOLID 指 Single responsibility， Open-closed， Liskov substitution， Interface segregation and Dependency inversion， 即单一功能、开闭原则、里氏替换、接口隔离以及依赖反转)。

这部分额外工作就在 UI 与Model之间， 以及 Model 与 Data access 之间。 我们把这类代码称为"GLUE"(胶水， 译者注：由于作者全用大写字母表示， 因此后续延用 GLUE)代码。"GLUE"代码主要有两种逻辑类型。
鄙人浅见薄识， 如果你有更多的"GLUE"类型实例， 请在留言中指出。映射逻辑(绑定逻辑): 每一层通过属性、方法和集合和其它层链接。例如， 一个在 UI 层中名为“txtCustomerName”的 Textbox 控件，将其映射到 customer 类的"CustomerName"属性。
txtCustomerName.text = custobj.CustomerName; // 映射代码
现在谁应该拥有上述绑定逻辑代码，UI 还是 Mo