NET 应用架构指导 V2 学习笔记（十） 表现层的主要技术及设计步骤
2010-05-30 14:55 Virus-BeautyCode 阅读(2276) 评论(4) 编辑 收藏 举报主要的技术及常用的模式。
移动应用
- 在设计移动应用的时候可以参考下面的原则：
如果你想要构建一个基于windows的完全在线、偶尔在线、离线的应用，可以考虑使用windows compact framework。 - 如果你想构建一个支持各种移动设备，或者是需要WAP协议，compact HTML的联网应用，可以考虑使用ASP.NET 。
富客户端应用
在设计富客户端应用的时候可以参看下面的原则：
- 如果你想要构建富媒体和图像化的应用，可以考虑使用WPF。
- 如果你想要构建一个需要从web服务器下载，然后运行在windows客户端的应用，考虑使用XAML Browser应用（XBAP）。
- 如果你要构建的应用是以文件为基础，或者是使用报表，可以考虑设计一个Windows office business application(OBA)。
- 如果你想使用大量的第三方控件，和快速开发工具，考虑使用windows forms。如果你决定使用windows forms，考虑使用模式和实践小组的Smart Client Software Factory。
- 如果你想构建一个WPF应用，可以参考下面的原则
- 对于Composite应用，可以考虑模式和实践小组的Composite Client Application Guideline。
- 考虑使用表现层模型（Model-View-ViewMoel）模式，MVVM是MVC的变种，为现代的UI开发专门设计的模式，View是设计者的职责，而不是一个类开发者的职责。你可以通过在用户控件上实现DataTemplates来给与设计者更多的控制。考虑在View和Prosenter或者是ViewModel进行通信的时候，使用WFP的Command。
富internet应用
构建富internet应用可以参考下面的原则：
- 如果你构建一个以浏览器为基础，支持跨平台的联网应用，支持富媒体，有丰富表现能力的应用，考虑使用silverlight。
- 如果你决定使用silverlight构建应用，参考下面的原则：
- 考虑使用前面WPF中讲述的MVVM模式。
- 参考模式与实践小组的Composite Client Application Guideline。
Web应用
构建web应用可以参考下面的原则：
如果你要构建一个通过浏览器或者是特殊的应用代理才可以访问的应用，考虑使用ASP.NET。
如果你决定使用ASP.NET构建应用，可以参考下面的原则：
- 考虑使用master pages简化开发，提供一致的UI表现。
- 增加交互性和后端线程处理，减少页面的重新加载，考虑使用在ASP.NET页面中使用ajax。
- 如果你想要增加富媒体和交互性，考虑在asp.net中使用silverlight控件。
- 如果你想要在应用中提升可测试性，或者在用户界面和业务逻辑之间实现一个更加清晰的分离，考虑使用asp.net mvc框架。这个框架支持MVC为基础的web应用开发。
性能考虑
如果要提高表现层的性能，可以参考下面的原则：
- 小心地设计表现层，以便在提供所需功能的基础上，同时是一个交付丰富的、快速响应的用户体验。例如：确保你的表现层可以灵敏的验证用户的输入内容，而不需要跨层才可以验证。这就需要在表现层实现业务逻辑层的验证规则，也可以通过使用元数据或者是共享组件。
- 表现层和业务逻辑层或者是服务层的交互应该是异步的。这可以避免可能存在的高延迟或者是网络连接的间歇性，可能会影响应用的可用性和响应性。
- 考虑在表现层缓存要显示给用户的数据。例如：你可以在股票软件中缓存历史信息用来显示。
- 在通常情况下，避免维护session数据，避免为每个用户缓存数据，除非用户数量有限，或者是数据的量较小。但是，如果用户只是存活一会儿，为每个用户短暂的缓存数据可能会是一个适当的技巧。
- 对于查询数据，总是使用分页。不要在查询中返回不限量的数据，使用适当的分页数据来显示。只在绝对需要的时候，使用客户端分页。
- 在ASP.NET中，小心使用试图状态ViewState，因为会在每一数据访问中增加数据量，会降低应用的性能。
表现层的设计步骤
下面的步骤是设计表现层的建议。这个方法确保你考虑到了在开发和架构的时候遇到的，全部的相关因素。
1 确定你的客户端类型。选择一个可以满足需求的，保持现有组织的基础架构和部署环境限制的客户端类型。例如，如果你的用户都装备有移动设备，都会连接网络，这时候移动客户端可能是最好的选择。
2 选择表现层技术。确定你的UI和表现层的功能，选择满足需求的UI技术，适合你选择的客户端类型。这时候，如果选择的技术不合适，你可能需要重新考虑你选择的客户端类型。
3 设计用户界面。如果你想要你的UI模块化，需要从表现层分离关注。考虑分离的表现模式，例如Presentation Model、MVC、MVP。
4 决定你的数据验证策略。使用数据验证保护你的系统，避免不受信任的输入。同时，为异常管理和日志选择合适的策略。
5 决定你的业务逻辑策略。将业务逻辑层从你的表现层代码中解耦。将会提高应用的可维护性，使得在修改业务逻辑的时候不影响表现层。你选择的技术依赖于应用的复杂性，可以参考下面的方法：
- UI验证。简单应用的验证就是对于输入的验证，你可能需要在UI组件中实现业务逻辑。但是，要小心不要将业务逻辑代码混在UI的数据验证中。
- 业务处理组件。如果业务较复杂，例如要支持事务，在UI的验证之外需要扩展业务逻辑，考虑将业务逻辑放在独立的组件。
- 领域模型。对于复杂的企业级应用，业务逻辑会被多个应用共享，考虑将业务逻辑分离到独立的逻辑层。这样允许你将业务逻辑部署在独立的物理层，提高伸缩性，而且支持其他应用的重用。
- 规则引擎。在应用中一定要支持复杂的验证，处理规则编排，领域逻辑，考虑将业务逻辑放在规则引擎中，例如微软的BizTalk Server。
6 确定和其它层的通信策略。如果你的应用包括多个层，例如数据访问层和业务逻辑层，确定一个表现层和其它层通信的策略。如果你由一个独立的业务层，你的表现层将和业务层进行通信。如果没有，你的表现层将和数据访问层直接通信，在访问其他层的时候参考下面的标准：
- 直接的方法调用。如果通信的逻辑层部署在同一个物理层，你可以使用直接的方法调用。
- web service。如果你想要共享数据访问或者是业务逻辑操作，如果逻辑层和数据访问层部署在不同的物理层，或者解耦他们是重要的，采用web service进行通信。考虑WCF，如果通信发生在内容，使用TCP协议；如果你的业务逻辑和数据访问被internet消费，使用HTTP协议。如果运行需要长时间，考虑使用异步的消息查询。
相关的设计模式
下面列出表现层关键的模式，用目录来划分开。
| 目录 | 相关模式 |
| 缓存 |
|
|
Composition and layout |
|
| 异常管理 |
|
| navigation |
|
| user experiences |
|
