.Net企业级应用架构设计之表现层设计

综述

如果没有用户界面，哪个程序都不能运行。哪怕是中间层代码堪称完美，用户也无法使用到。很多架构师不太重视表现层，仅将表现层作为业务层和数据访问层完成后的一个细节处理。但实际上，用户界面、业务逻辑和数据访问代码在任何一个系统中都是同等重要的。你的态度、偏好和自身的专业技能决定了你为每个层制定的“优先级”，也导致了你对各个层的关注顺序。

实际的开发中，表现层经常是系统中最后开发的一部分，且非常依赖于VS等开发工具所提供的功能。表现层很大一部分工作可以由功能强大的高级工具完成，不过这些强大工具的出现可能会让架构师和开发者不太重视表现层的良好设计。表现层的实现可以非常简单，也可以非常复杂。因此在开始时使用快速应用程序开发（RAD）工具、向导、小工具直接和数据库绑定，但是同时你要对你现在的做法有清醒的认识。若表现层逐渐变得复杂起来，即变成一个图形化的表现层加上很多应用程序的逻辑，那么就应该使用规范和模式来进行整理，就像在业务层和数据访问层的做法一样。

表现层由两个主要组件组成：用户界面和表现层逻辑。用户界面给用户提供了实用程序的接口，程序的所有行为都是通过用户界面中的图形化元素或者文本元素暴露给用户。这些元素用来提供信息、建议下一步操作并通过键盘和鼠标等输入设备捕获用户活动。用户在用户界面上进行的任何操作都将成为表现层的另一个组件，即表现层逻辑的输入。表现层逻辑是指所有用来处理将要显示的数据的逻辑，加上将用户输入转换为后台系统的命令的逻辑。换句话说，表现层逻辑将负责中间层和UI之间数据流的交互。

表现层职责

如果若让软件工程师列出表现层的指责，那么你一定会听到如下的描述：验证、格式化、添加样式、和可用性等。不过可用性更像是一个属性而不是职责，且诸如验证、添加样式和格式化的特性更应该属于UI组件，而不是表现层。

作为设计表现层的架构师，你应该站的更高一些，至少在最初时应该这样。表现层的职责应该从更高的角度考虑，即不依赖于物理UI、较高可测试性和不依赖与数据模型。

不依赖于图形化元素：图形化元素组成了应用程序的用户界面，用户将看到这些组件并进行交互，借此将命令和信息传递给后台系统。但是表现层必须保证图形化用户界面的任意修改都不会影响到数据流和表现层逻辑。只要变化属于纯粹的图形化修改，那么表现层都必须支持以透明的方式对待。现实的例子就是微博、博客、CMS等能切换主题样式和布局的用户界面系统。

不依赖于UI技术：表现层必须不依赖UI技术和平台，这个需求更难实现，且有时候无法做到完全不依赖，或许应该说尽量不依赖UI技术。一个很常见的需求是系统需要支持很多表现层，例如：Web、移动设备、Wi