应用系统架构设计..docx

应用系统架构设计阅览次数: 今天:0 总浏览:273文章来源: /simonw/archive/2005/04/27/146185.html原文作者: 整理日期: 2008-07-06发表评论字体大小:小中大应用系统架构设计 ?Simonw@2005.4.24 如有转载请注明出处。?我 们在做着表面上看似是对于各种不同应用的开发，其实背后所对应的架构设计都是相对稳定的。在一个好的架构下编程，不仅对于开发人员是一件赏心悦目的事情， 更重要的是软件能够表现出一个健康的姿态；而架构设计的不合理，不仅让开发人员受苦受难，软件本身的生命周期更是受到严重威胁。这里我将针对在微软 dotNet平台上做应用开发系统的一般架构流程设计做一个粗浅的讨论。?总体设计图??表示层表示层由UI（User Interface）和UI控制逻辑组成。lUI（User Interface）UI是客户端的用户界面，负责从用户方接收命令，请求，数据，传递给业务层处理，然后将结果呈现出来。根据客户端的不同我们大体将应用程序分为BS（Browser-Server） 浏览器结构，CS（Client-Server）桌面客户端结构。BS 的优点是无需操心客户端，只需要部署维护好服务器即可。CS的优点在于强大的界面交互表达能力。RIA（Rich Internet Application）是为了融合这两种结构优点的一种技术，它依赖在客户端一次性安装一个通用解释器之后即获得强大的界面交互表达能力和无需部署具体 客户端的方便性。具体的实现技术很多，例如微软的SmartClient， Avalon； Macromedia的Flex；以JS为基础的Bindows；Ajax等等很多。?lUI控制逻辑UI 控制逻辑负责处理UI和业务层之间的数据交互，UI之间状态流程的控制，同时负责简单的数据验证和格式化等功能。具体的说在dotNet事件驱动的编程模 型下，UI控制逻辑被自然的实现在了事件函数中，例如PageLoad事件函数，ButtonClick事件函数。在这些事件函数中，主要任务就是做UI 控件与业务实体的数据交换与业务调用，但面对大量的数据交换工作量与维护量就成了最大的问题。而在复杂应用的系统中，状态与流程的管理是必须要考虑的因 素，它们同样是业务逻辑的一部分，如果不加以封装的直接写在事件函数中将导致业务依赖表示层。下面分别讨论这两个问题。?1.???????? 1.UI与业务实体之间的数据交互此 阶段负责数据交换的业务实体称为DTO（Data Transfer Object），处理输入时我们从UI控件的获得数据填入DTO再向下传播，处理输出时用户发出请求业务层会将数据以DTO的形式返出再赋给UI控件展 现。因此需要一种方式来自动解决这样的来回赋值问题。遗憾的是dotNet下的不少控件虽然支持数据绑定但仍然没有一个现成完整的解决办法。我们可以自己 设计一个Adapter按照某种映射关系来自动处理这样的绑定，这样的映射关系最好是UI控件与DTO属性的事先命名约定，以此种方式的约定作为映射关系 无需增加任何配置文件和配置工作即可实现。?2.???????? 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应用程序。?业务层业务层封装了实际业务逻辑，包含数据验证，事物处理，权限处理等业务相关操作，是整个应用系统的核心。因此设计一个能够真实反映实际需要的业务层是非常必要的，我们将实际业务具体分为业务数据与业务操作两部分。?l业务数据业务数据又是业务逻辑的核心，最终业务数据将以一种固定的格式表现于内存中，在系统的各个层次间传输，充当DTO角色。表达业务数据的方式一般分为两种Table Model和Domain Model。Table Model是将数据库中的表直接映射成为业务数据对象，这样的优点是适合于机器操作，ADO.NET直接提供了这种操作的便利，但对于复杂业务关系的表达 就很不直观。只适合于业务需求与数据表对应关系很