系统架构师-基础到企业应用架构-表现层

最近也许是由于假期的原因，我发布的文章的速度变慢了，对大家说下抱歉，这个系列的确我很难写，感谢大家对我的支持和关注，的确我在发布后得到大家的支

持和认可，让我有了更多的动力，之前发布的有些内容，可能对各层讲解的内容的广度还不够，当然这和我个人的水平面有关，还请各位多多提出宝贵意见和建议。

从本篇开始，我将会采用更加规范的格式，更严谨的求知态度，更加准确的表达，去将接下来的系列文章写完，并且与群中的很多朋友交流后，他们希望出一个总

的PDF电子书，这样可以方便阅读，的确谢谢各位的支持，我目前将以后每篇写的内容，放一份PDF格式的在群共享中，有需要的朋友可以进行相应的下载，由于本人

的写作水平有限，所以在书写的深度和书写的格式上还有很多的缺点，还希望大家多多指出。

二、开篇

本篇我们将针对系统架构分层中的表现层进行讲述，分析表现层的架构与设计模式，当然我们会结合目前比较流行的表现层模式进行分析讲解，主要是围绕MVC模

式的起源及发展的过程进行讲述，并且分析目前MVC模式在不同UI层中的应用设计，由于本人的水平有限，加之实际的项目中可能应用的理解和经验水平不足，可能在

某些分析的地方不对，还请大家提出。我们之前的写作惯例，我们先来看看本文的主要讲述的内容吧

本文将会以上面的2点为主线展开去讲解表现层的内容。

三、内容提要

1、前言

2、内容提要

3、本文提纲

4、表现层模式

4.1、表现层的职责

4.2、UI层与表现层逻辑

4.2.1、用户界面的职责

4.2.2、表现层中容易产生的误区

4.3、MVC模式的提出及演化

4.3.1、MVC模式

4.3.2、MVP模式

4.3.3、MVC模式与MVP模式的对比和总结

5、结束语

6、系列进度

7、下篇预告

四、表现层模式

4.1、表现层的职责

我们知道任何一个应用程序，如果想要更好的与客户交互，我们一般都是通过提供一个用户界面去完成与用户的交互，当然通过前面我们讲述的，服务层与业务逻

辑层的讲解，其实都是为了更好的为表现层服务的，通常，我们都不是特别的重视表现层，但是其实，表现层同样重要。其实通常我们在关注各个分层的时候，我们对

每个分层的重视程度会不同，可能是由于我们自身的爱好，态度，或者是专业技能所决定的，但是一个好的系统，必然要求我们不管哪个分层都要足够的重视。

我们在做表现层时，通常我们会关注下面几个组件，首先是用户界面。也就是客户能够看到的用户界面简称UI，还有一部分就是与用户行为进行交互的组件，通常

我们叫做表现层逻辑，用户的所有操作都通过表现层逻辑来支持，表现逻辑层将负责其他层与UI层之间的交互。

根据我们前面讲述的各分层的设计我们知道，表现层逻辑将主要与服务层或者业务逻辑层进行交互。具体的关系如下：

通过上图我们知道表现逻辑层的位置，可以说如何组织好用户界面及表现层逻辑同其他层之间的关系，就是决定设计好坏的关键。也可以说表现层逻辑决定了用户

与系统交互。

下面我们来先看看表现层的职责吧

我们一般都把如下职责看作是表现层的职责，是不是你也有相同的看法？

其实，像图中说的验证，格式化，添加样式等这些更应该属于UI层组件，而不应该属于表现层，但

是作为架构师，你必须考虑的更全面，从更高的层次去考虑，比如说下面的几个方面：

只有更好的考虑这些因素，才能决定表现层的架构，我们针对上面的几个方面来

简单的分析一下。

1、UI的无关性：

这里的UI的无关性就是指不依赖UI层的实现技术，不管是上面说的Web还是Winform，还是其他的WPF、WP还是其他的任何UI表现形式。我们知道这样的表现

层设计出来是理想的，我们只是想尽可能的提高可复用性，我们希望的是虽然不同的UI使用的实现技术不同，但是这些UI能够共用表现层逻辑，这时候我们就能做到很

好的复用性。

我们需要知道，这里提出的代码重用只是说是尽可能大的做到表现层逻辑重用，但是有些情况我们没有办法做到，例如Silverlight与WPF，由于他们使用不同的

CLR，所以我们只能说是做到代码重用，我们需要针对他们各自进行单独的编译。

2、可测试性

任何分层都需要能够测试，因为只有测试才能知道功能是否能够很好的满足需求。但是通常来说表现层的测试，相比其他分层要复杂一些，因为表现层需要考虑的

因素很多，所以决定了测试的难度，所以更好的测试性就是我们架构设计的基本要求。

一般来说我们在表现层的处理流程是这样的：

上面的图中大概描述了，我们在表现层中的基本流程，我们来结合图形来说明下：用户界面通过用户

操作，将触发相应的行为事件，这些事件将会被某个特殊的控制器进行处理，控制器通过发送给指定的处理函数，然后将处理函数返回的结果，反馈给用户界面。

通过上面的流程我们知道，我们测试时必须模拟用户的行为，并且如何保证用户的行为事件能够得到正确的处理，这些都是我们必须测试的内容。我们如果将所有

的内容都写在表现层，那么我想可能测试起来不会那么容易，如果说我们的用户界面与表现层逻辑写在一个页面中，可能我们并不容易测试，幸好APS.NET中通过代码

后置的技术，实现设计层与表现层逻辑代码的分离。当然我们在之前就对架构设计的实现提出了一个观点，就是分离功能点，将关注的功能点进行分离，提出更高的抽

象，这样可以达到更好的测试的目的。

3、不依赖数据模型

在服务层、业务逻辑层中我们都提到了数据传输对象，并且把这个对象作为与表现层通信的载体，使用了数据传输对象后，那么我们就可以做到表现层不依赖于我

们的数据模型，但是我们也讲过，数据传输对象为项目带来了更多的类，更多的工程文件，所以这会对我们的开发工作带来额外的工作量。因为不同的表现层需要一个

与之对应的数据传输对象，这些都和前面我们介绍的情况是一致的。因此，我们在项目中是否使用数据传输对象，我们需要根据项目的需要来决定。