【学习】富客户端应用程序（RCA）分层设计的要点浅析

        好几年以前是偶尔听说过“富客户端”这个词，但后来因为“RIA”这个词出来了，我居然就把RCA给忘记忽略了，真是大意！现在重新来学习一下，也与接下来要做的一个项目接轨。先把架构的图片传上来。

典型的RCA架构一般也划分为三层（与上一篇的Web应用程序类似）：

表现层：UI及表现的逻辑

业务层：业务逻辑、业务工作流以及业务实体

数据层：数据访问及服务代理模块

        而RCA架构一般也是一种常见的“瘦应用程序”，主要由表现层组成，不过要通过特定的服务来远程访问驻留在外部服务器上的业务逻辑（通常是实现远程服务提供的接口）。一个典型的例子就是把窗口上的表单（通常是WinForm或者相似的界面，而非网页表单）提交给服务器去处理。

        另一方面，RCA架构又可以是有着非常复杂的业务逻辑、通常自己处理这些逻辑的应用程序，不过在必要时才与外部服务进行连接存取数据。典型的例子就是excel表格，它是多么的强大。在office2000以前可能主要是自己本地工作，然而2000年以后，随着互联网应用的深入，它也会与外界服务进行通信，比如现在的云存储（微软的live服务等）。

下面来看看在设计方面需要了解的一些事项：

• 业务层

        “轻”富客户端（thin rich client）通常是过特定的服务来远程访问驻留在外部服务器上的业务逻辑（通常是实现远程服务提供的接口）；“重”富客户端（thick rich client）则会把业务层部署在本地与客户端一共存。

        引入外部服务的接口定义，并在其中写代码去实现与外界服务的通信。

        如果业务逻辑不包含敏感信息，那么可以考虑把业务逻辑部署在客户端本地，以便充分发挥出包括UI及应用程序本身的更好的性能；不然，如果包含敏感信息，那就需要把业务逻辑部署到单独的应用层中去。

• 配置管理

        RCA通常需要在被启动时就加载配置信息，有时候也可能是在运行期间。这些配置信息，有可能是网络呀数据库的连接、用户设置、UI的表现规则、或者是一些比较常用的显示与布局设置等。我们需要决定在本地保存一定程序的设置，或在程序启动时从远程服务器中获取。

        决定哪些可配置的信息需要在程序运行期间被改变，比如文件位置、应用程序的设置、日志等。如果有必要的话，还可以设计让这些配置在程序的运行期间动态地被直接反映到程序的逻辑中。

        一般的用户设置可以保存在本地，但全局的设置需要保存在服务器端。

        敏感信息，不管在网络传输时还是保存在本地（包括在内存中）时，都要设计如何被保护。

• 数据访问
• 表现层
• 状态
• 工作流