系统架构师谈企业应用架构之表现层

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

简单的分析一下。

1、UI的无关性：

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

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

好的复用性。

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

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

2、可测试性

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

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

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

498)this.width=498;'' onmousewheel = ''javascript:return big(this)'' alt="" src="/uploadfile/201301/12/8A122050380.png" />

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

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

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

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

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

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

3、不依赖数据模型

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

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

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

4、不依赖图形化元素

我们这里的图形化元素是指，开发工具给我们提供的控件和工具集合，我们通过这些图形化元素设计出与用户交互的界面，我们希望我们的表现层能够在不同的控

件上可以以不同的方式表现出来，我们同时希望图形化元素中的任意修改不会影响到表现层逻辑，举个例子，我们平时在博客园中的模板设计，其实就是个很好的例

子，我们选择不同的模板，我们的博客页面就会在皮肤，样式，主题等方面都发生变化，但是并不影响我们的表现层。

4.2、UI层与表现层逻辑

4.2.1、用户界面的职责

我们接下来看看UI层的相关职责，我们知道，我们平时在系统设计过程中，一般架构师不会直接参与到用户的界面的设计中，架构师更侧重系统的可用性和可访问

性。我们认为UI层的主要功能包括下面几项：

498)this.width=498;'' onmousewheel = ''javascript:return big(this)'' alt="" src="/uploadfile/201301/12/74122050779.png" />

下面我们来分别说说吧

1、数据显示

我们都知道UI层是用户使用系统的唯一入口