软件开发的家园,编程爱好者的天地.

现在是:北京时间 2016/4/14 上午11:50:51 星期四

设为首页  |  加入收藏  |  网站地图

应用系统架构设计
发布于:第八基地 来源:互联网 作者:天堂路上 时间:2011-10-12 点击:231
      我们在做着表面上看似是对于各种不同应用的开发,其实背后所对应的架构设计都是相对稳定的。在一个好的架构下编程,不仅对于开发人员是一件赏心悦目的事情,更重要的是软件能够表现出一个健康的姿态;而架构设计的不合理,不仅让开发人员受苦受难,软件本身的生命周期更是受到严重威胁。这里我将针对在微软dotNet平台上做应用开发的系统架构设计做一个粗浅的讨论。

 

总体设计图

 

 

表示层

表示层由UI(UserInterface)和UI控制逻辑组成。

UI(UserInterface)

      UI是客户端的用户界面,负责从用户方接收命令,请求,数据,传递给业务层处理,然后将结果呈现出来。根据客户端的不同我们大体将应用程序分为BS(Browser-Server)浏览器结构,CS(Client-Server)桌面客户端结构。

      BS的优点是无需操心客户端,只需要部署维护好服务器即可。CS的优点在于强大的界面交互表达能力。RIA(RichInternetApplication)是为了融合这两种结构优点的一种技术,它依赖在客户端一次性安装一个通用解释器之后即获得强大的界面交互表达能力和无需部署具体客户端的方便性。具体的实现技术很多,例如微软的SmartClient,Avalon;Macromedia的Flex;以JS为基础的Bindows;Ajax等等很多。 

UI控制逻辑

      UI控制逻辑负责处理UI和业务层之间的数据交互,UI之间状态流程的控制,同时负责简单的数据验证和格式化等功能。具体的说在dotNet事件驱动的编程模型下,UI控制逻辑被自然的实现在了事件函数中,例如PageLoad事件函数,ButtonClick事件函数。在这些事件函数中,主要任务就是做UI控件与业务实体的数据交换与业务调用,但面对大量的数据交换工作量与维护量就成了最大的问题。而在复杂应用的系统中,状态与流程的管理是必须要考虑的因素,它包含了界面与业务两方面。如果不加以封装的直接写在事件函数中将导致业务依赖表示层。下面分别讨论这两个问题。 

1.UI与业务实体之间的数据交互

      此阶段负责数据交换的业务实体我把它称为DTO(DataTransferObject),但需要说明的是这里的DTO并不是只包含数据的业务对象,它仍然包含必要的方法是完整的业务实体。处理输入时我们从UI控件的获得数据填入DTO再向下传播,处理输出时用户发出请求业务层会将数据以DTO的形式返出再赋给UI控件展现。因此需要一种方式来自动解决这样的来回赋值问题。Java下Structs的Formbean对此问题提供了一定支持,而遗憾的是dotNet下的不少控件虽然支持数据绑定但仍然没有一个现成完整的解决办法。一种比较简单的方式是自己设计一个Adapter按照某种映射关系来自动处理这样的绑定,这样的映射关系最好是UI控件与DTO属性的事先命名约定,以此种方式的约定作为映射关系无需增加任何配置文件和配置工作即可实现。例如你的一个输入人名的Textbox命名为txtUserName,而我的业务实体属性命名为UserName,这样就可以通过字符串的查找来找到对应。 

2.状态与流程的管理

      复杂业务方面的状态与流程可以通过一些工作流引擎来解决,微软最近独立发布了自己的工作流引擎有兴趣的朋友可以去看看。一般更多的情况是需要解决界面上状态与流程的管理。耦合再表示层中是不可取的办法。MVC(Model-View-Controller)模式提供了实现这一目标的方法。Controller是整个方案的核心,它是一个流程管理器,来自UI所有的命令与数据经过Controller分发给业务层或其他UI,这样我们可以把流程,权限等逻辑单独封装,例如配置文件中,达到最大化的业务重用。dotNet下MVC的方案并不像Java下有那么多选择,目前有以下几种选择:

微软的UIPAB,它可以处理bs,cs下的流程跳转,可以使得相同的业务系统有webform和winform不同的展现方式。

开源的Mavrick.Net,它只适用于Asp.Net应用程序,它对流程,国际化,页面包装,xslt页面转换提供了很好的支持。

开源的Lattis,功能比较单一,同样只适用于Asp.Net应用程序。

 

业务层

      业务层封装了实际业务逻辑,包含数据验证,事物处理,权限处理等业务相关操作,是整个应用系统的核心。因此设计一个能够真实反映实际需要的业务层是非常必要的,我们将实际业务具体分为业务数据与业务操作两部分。 

业务数据

      业务数据又是业务逻辑的核心,最终业务数据将以一种固定的格式表现于内存中,在系统的各个层次间传输,充当DTO角色。表达业务数据的方式一般分为两种TableModel和DomainModel。

      TableModel是将数据库中的表直接映射成为业务数据对象,这样的优点是适合于机器操作,ADO.NET直接提供了这种操作的便利,但对于复杂业务关系的表达就很不直观。只适合于业务需求与数据表对应关系很直接的需要快速开发的情况。通常我们选用Dataset或者强类型Dataset(StrongTypedDataset),强类型Dataset支持编译时的类型检查,效率上要略高于普通Dataset。Dataset有很多方便的特性:无需自己编写维护类,支持序列化,数据副本保存,支持数据集合,对控件绑定支持效果好,微软提供了相应的生成工具以及持久方案。但缺点也是明显,复杂数据表现不直观,做为DTO在各个层次间传输,尤其是分布式环境,庞大的体积,相对缓慢的实例化对于性能造成很大压力。

      DomainModel则是根据实际业务按照现实方式用OO思想建模,这样很适合业务复杂的系统。通常采用自定义数据实体(CustomDataEntity)方式表达。自定义数据实体,有着良好的性能,编译时的类型检查,数据表现方式非常直观符合实际业务的操作方式等优点,但需要自己定义维护类,在分布式环境下需要自己编写序列化方法。

对我有帮助
(0)
0%
对我没帮助
(0)
0%
返回顶部
在线反馈
在线反馈