Application Architecture Guide2.0-表现层_app

概述概览: 表现层的组件要实现和展示用户接口，管理用户交互。这一层包括用户输入和显示的控件，用户交互的组件。下面的图表显示表示层如何融入一个通用的应用架构。表现层组件 1 UI组件。UI是用户和应用程序交互的接口，负责呈现和格式化数据，同时获取和验证用户输入数据。 2 用户处理组件。用户处理组件同步和协调用户交互。当系统有复杂的用户接口时，单独的用户处理组件可能会有用处，用分离的组件概览:

表现层的组件要实现和展示用户接口，管理用户交互。这一层包括用户输入和显示的控件，用户交互的组件。下面的图表显示表示层如何融入一个通用的应用架构。

表现层组件

1 UI组件。UI是用户和应用程序交互的接口，负责呈现和格式化数据，同时获取和验证用户输入数据。

2 用户处理组件。用户处理组件同步和协调用户交互。当系统有复杂的用户接口时，单独的用户处理组件可能会有用处，用分离的组件实现通用的用户交互模式，可以使你在多用户接口时重用它们。

方法

当设计表现层时，用下面的步骤帮助组织你的思维:

1. 识别你的客户端类型。根据你的需求，基础结构和部署限制来选择客户端类型。

2. 确定你怎样去呈现数据。选择数据格式并且决定UI的数据呈现方式。

3. 确定数据验证策略。使用数据验证技术过滤不安全的用户输入。

4. 确定业务逻辑策略。减弱业务逻辑对表现层的依赖。

5. 确定与其它层的通信策略。如果你的系统有很多层，如数据访问层及业务逻辑层，确定你的表现层与它们的策略。

设计时考虑的内容:

当设计表现层时，使用下面的原则：

1 选择合适的UI呈现技术。确定你是要实现Rich(Smart)ClIEnt,还是Web ClIEnt,Rich Internet Application(RIA)。

2 实现相关的模式。用已经证明的模式去解决通用的表现层问题。

3设计时专注于不同的方面。使用专门的呈现UI；使用专门的表现层实体获取数据，并将数据提交给视图；使用专门的UI处理组件来响应用户交互。

4 考虑用户体验。审查系统的用户交互设计，根据不同的客户端类型和开发技术来修改原有的用户交互准则。

5 坚持用户驱动设计原则。在设计表现层前，要了解客户。要充分的调查，研究方案的可用性，跟客户访谈来决定最好的表现层设计，以满足客户的需求。

表现层框架

@H_403_101@

类别	通常的问题
Caching	缓存了易变的数据。
	缓存了没有加密的敏感数据。
	选择了不正确的缓存存储方式。
	在WEB开发时没有使用适当的缓存技术。
	假设数据在缓存里一直可用-- 但它有可能过期或被移除。
Composition	没有考虑在运行时使用模式或类库来实现动态布局和视图注入。
	使用依赖类和服务支持的表现层组件来代替支持运行时的依赖注入。
	没有在组件中使用发布/订阅方式来支持事件。
	没有使应用程序象单独的模组一样容易添加。
ExceptionManagement	没有捕获不可处理的异常。
	当异常发生时没有清空资源和状态。
	将敏感的信息展现给终端客户。
	使用异常来实现程序逻辑。
	捕获你处理不了的异常。
	在不需要的地方使用自定义异常。
input	设计的时候凭直觉，或实现了超级复杂的接口。
	设计的不容易理解。
	没有考虑不同的屏幕大小和分辨率。
	没有考虑不同的设备或输入类型，如移动设备，触摸屏等。
Layout	为Web设置不适当的布局。
	实现了过为复杂的布局。
	没有选择合适的布局组件和技术。
	没有坚持可理解性和可用性的准则。
	实现了不合适的工作流接口。
	没有支持本地化和全球化。
Navigation	不一致的导航。
	重复的逻辑处理导航事件。
	使用硬编码导航。
	对于向导式的导航，没有管控状态。
Presentation EntitIEs	定义了不需要的实体。
	在需要的时候没有实现序列化。
RequestProcessing	在长时间的请求中锁住了用户接口。
	混合了处理和呈现逻辑。
	选择了不合适的请求处理模式。
User ExperIEnce	显示了无帮助的错误信息。
	缺少响应。
	过于复杂的用户接口。
	缺少用户个性化。
	缺少用户权力。
	设计了效率低的用户接口。
uicomponents	在不需要的时候创建了用户组件。。
	在MVC模式下没有维护状态。
	选择了不合适的UI组件。
UIProcessComponents	在不需要的时候实现了UI处理组件。
	实现了错误的设计模式。
	在UI处理逻辑中混合了业务逻辑。
	在UI处理逻辑中混合了呈现逻辑。
ValIDation	没有验证所有输入。
	只依靠客户端的输入验证。你必须在服务器端或业务逻辑层验证输入。
	没有正确处理验证错误。
	没有为验证识别合适的业务规则。
	没有记载验证失败记录。

缓存
缓存是提高应用程式性能和UI反应的最佳技术，使用数据缓存可以优化数据查询和避免网络拥塞。缓存开销大的、重复处理的结果可以避免不必要的重复处理。

当设计你的缓存策略时，考虑以下的指导原则
1避免分布式的缓存一致。

2 不要缓存易变的数据。

3不要缓存不加密的敏感数据。

4当使用内存中的缓存时，考虑缓存的数据随时可以使用的格式。例如，缓存特定的对象替换缓存原始的数据库数据。

5区分缓存数据和状态数据。

6 对于在特定时间改变的动态数据使用绝对过期策略。

7对于特定时期不活动的信息使用变动的过期。

8当准备使用基于时间的过滤策略时，要考虑: 选择一个小的时间值时需要更多的网络带宽，若选择一个高的值时，你也许会得到陈旧的数据。

9 当使用内存缓存时考虑使用自动移除。

10当使用硬盘缓存时考虑使用手动移除。

11 不要依赖于缓存中的数据，它也许已经被移除。

12如果你使用持久缓存，请考虑主动加载。如果你知道数据是静态的，或生命周期是可知的或者你的网络不可靠，连接很慢你应该使用主动加载。

13如果你使用内存中的缓存，除非缓存项创建比较昂贵否则避免主动加载。

组合
考虑当表现层如果使用运行时组合的独立的模块，你的程序是否很容易开发或者维护。组合模式提倡动态加载表现层组件，在运行时创建视图。这些模式可以帮助你减少代码和依赖类库，当依赖的组件改变时不需要重新编译和部署。组合模式帮助你实现共享，重用和替换表现层逻辑和视图。

当使用组合策略时，考虑以下的原则:
l 使用动态加载和重复使用视图以简化设计，提高性能和可维护性。

2 利用模式来消除依赖，如依赖注入，支持动态加载和便捷的模块替换。

3 如果你需要支持菜单和命令按钮，考虑使用Command模式。

4 当组合你的UI时考虑使用视图注入模式来替代视图查找模式。

5 组合动态的WEB页面时，考虑使用模式视图模式来提高重用和一致性。对于asp.net，你可以使用Master Page.

6 如果你用动态的模块组件来创建视图，那可以考虑使用组合模式。

异常管理
使用统一的异常管理机制为你的应用程式设计一致的捕获异常方式。对于跨越边界的异常要特别注意，即使跨越可信任的边界。设计时要考虑未处理的异常，使它们不会破坏程式稳定性或暴露敏感信息。

当设计异常处理时，考虑以下的原则:
1 使用对用户友好的错误提示信息。

2 避免在错误页，报错信息，日志，审核文件中暴露敏感数据。

3 对于不能处理的异常使用全局统一的异常处理方式，一个错误页或者错误提示信息。

4 区别系统异常和逻辑错误。对于逻辑错误，提供用户友好的报错信息，允许用户重新 *** 作。对于系统异常，检查它是系统问题还是数据库问题，提供友好的报错信息并且将错误信息存到日志有利于以后问题追踪。

5 只有当没有合适的异常类型或你需要不同于现有的异常时，你可以创建自定义异常。

6避免使用异常来处理程式逻辑。

输入
当你的系统有输入要求的时候，请设计用户输入策略。为了起到最大的可用性，遵循组织定义的规范和基于多年的用户输入研究而指定的工业标准。

当设计你的输入集合策略时，遵循以下原则:
1对于普通的数据收集工作可以使用基于Form的控件。

2 对于办公形式的文档数据收集可以使用基于文档的输入机制。

3对于复杂的数据收集任务或类似工作流的输入方式可以使用基于向导方式的方法。

4 确定你的需求是否需要打印机，话筒或其它基于设备的输入。

5 设计时要考虑本地化。

6考虑易使用性。当设计输入策略时，考虑用户不可能做的地方，例如为盲人做语音输入软件或为视力低的人放大文本和图片。

布局
设计你的UI布局以独立于单独的UI组件和UI处理组件。当选择一个布局策略，考虑是一个单独的设计团队来做布局还是开发团队来创建UI。如果设计者来创建UI，选择一个方法不依赖代码或可以使用开发工具来创建UI。

当设计你的布局策略时，考虑一下原则：
1 选择布局方式和设计工具。布局方式包括基于表格，样式表，网格和模板的。

2 时刻考虑用户个性化。

3时刻考虑本地化。

4为你的UI使用统一的布局元素以方便使用和提高便捷。

5设计布局时遵从已建立的工业标准。

6设计Web布局时要方便搜索引擎搜索(SEO Search Engine Optimization)。

导航
设计你的导航策略使用户可以方便的从屏幕或页面上导航，你可以将它独立于表现层UI。确保你的导航链接或导航控件在你的程式中保持一致以减少用户混淆或者隐藏程式复杂性。

当设计导航策略时，考虑以下原则：
l 确定你的屏幕或页面导航策略。例如，工具条，菜单，站点地图和母版页的使用。

2 将导航和处理分开。

3 确定你怎样保存导航状态。

表现层实体
使用表现层实体去储存数据，你可以使用表现层去管理视图。表现层实体不是必要的；当你的数据集过于巨大以及需要单独的UI控件去存储你可以使用它们。

当设计表现层实体，考虑以下原则：
1 确定你是否需要表现层实体。

2如果你使用了数据绑定控件，可以考虑使用DataSet,Array或者Collection作为你的表现层实体格式。

3不要将业务逻辑添加到表现层实体。

4如果你需要执行任何输入数据的验证可以把它添加得到表现层实体中。

请求处理
时刻考虑设计你的请求处理程式，以达到可维护及可测试性。

当设计请求处理方案时，考虑以下原则：

当发出请求时，注意别锁住UI，尤其是长时间运行的请求。

不要混合你的处理和呈现逻辑。

不要在视图中实现请求处理逻辑。

用户体验
容易使用的和不易使用的程序最大的区别就是好的用户体验。进行可用性研究，问卷调查和访谈以理解用户对程式的需求以及期望，设计时要考虑到这些因素。

当设计用户体验时，考虑以下原则：

从用户的角度设计报错信息。

注意UI反应。
对于富客户端程式，避免长时间锁住用户线程。

对于富Internet程式，避免在任何可能的地方同步处理。

当开发Web程式，使用AJAX提高响应，以及减少回发和页面加载。

不要过度设计或设计复杂的接口。为每一个用户提供清晰的系统使用方式。

为用户设计个性化，本地化和可 *** 作性。

赋予用户设计能力。允许用户控制他们与程式的交互以及数据展示方式。

UI组件
UI组件是显示数据和接收数据输入的控件。除非需要特别的展示或数据收集否则不需要创建自定义控件。

当设计UI组件时，考虑以下原则：

在windows应用程式和MOBILE应用程式，在本地存储UI值，用实体或者单独的值。

对于asp.net程式，允许使用VIEWSTATE,SESSION或者全局对象来存储UI的值。

对于asp.net Mobile程式，允许存储状态在用户Session里以减少影响设备。

在用户接口里要利用好数据绑定控件的优势。

使用自定义控件或使用第三方的控件以显示和收集特别的数据。

对于WPF和Silverlight,最好多对用户控件使用数据模板。

对于WPF和Silverlight,管控UI状态时使用表示-模型模式。

验证
设计一个有效的输入和数据验证策略对于系统的安全性至关重要。确定表现层的用户输入验证规则和业务规则。

当设计你的输入数据验证策略时，请遵循以下的原则：

尽量验证所有的客户端输入以提高交互性和减少错误数据导致的错误。

不要只依靠客户端的验证。使用服务器端的验证保证输入的安全性以做出安全相关的决定。

统一你的验证方式以便重用。

约束，拒绝，清理所有输入。

尽可能使用内置的验证控件。

在配置中使用强验证规则。在这种情况下，企业库的验证块可以拿来用。

在Web程序中，考虑使用AJAX来提供实时的验证。

模式映射

@H_403_101@

Area	Relevant Patterns
Caching	Cache Dependency
	Page Cache
Composition	Composite VIEw
	Dependency Injection
	Template VIEw
	transform VIEw
	Two-step VIEw
Exception Management	Exception ShIElding
Navigation	Front Controller
	Page Controller
UIProcessingComponents	Model VIEw Controller (MVC)
	Passive VIEw
	Presentation Model (Model-VIEw-viewmodel)
	Supervisor Controller