开发
其实背后所对应架构设计都是相对稳定
在
个好架构下编程不仅对于开发人员是件赏心悦目事情更重要是软件Software能够表现出个健康姿态；而架构设计不合理不仅让开发人员受苦受难软件Software本身生命周期更是受到严重威胁这里我将针对在微软dotNet平台上做应用开发系统般架构流程设计做个粗浅讨论总体设计图
表示层
表示层由UI(User Interface)和UI控制逻辑组成
UI(User Interface)
UI是客户端
用户界面负责从用户方接收命令请求数据传递给业务层处理然后将结果呈现出来根据客户端区别我们大体将应用
分为BS(Browser-Server) 浏览器结构CS(Client-Server)桌面客户端结构BS
优点是无需操心客户端只需要部署维护好服务器即可CS优点在于强大界面交互表达能力RIA(Rich Internet Application)是为了融合这两种结构优点种技术它依赖在客户端次性安装个通用解释器的后即获得强大界面交互表达能力和无需部署具体客户端方便性具体实现技术很多例如微软SmartClient Avalon； MacromediaFlex；以JS为基础Bindows；Ajax等等很多UI控制逻辑
UI控制逻辑负责处理UI和业务层的间
数据交互UI的间状态流程控制同时负责简单数据验证和格式化等功能具体说在dotNet事件驱动编程模型下UI控制逻辑被自然实现在了事件
中例如PageLoad事件ButtonClick事件在这些事件中主要任务就是做UIControl控件和业务实体数据交换和业务
但面对大量数据交换工作量和维护量就成了最大问题而在复杂应用系统中状态和流程管理是必须要考虑原因它们同样是业务逻辑部分如果不加以封装直接写在事件中将导致业务依赖表示层下面分别讨论这两个问题1. 1.UI和业务实体的间
数据交互此阶段负责数据交换
业务实体称为DTO(Data Transfer Object)处理输入时我们从UIControl控件获得数据填入DTO再向下传播处理输出时用户发出请求业务层会将数据以DTO形式返出再赋给UIControl控件展现因此需要种方式来自动解决这样来回赋值问题遗憾是dotNet下不少Control控件虽然支持数据绑定但仍然没有个现成完整解决办法我们可以自己设计个Adapter按照某种映射关系来自动处理这样绑定这样映射关系最好是UIControl控件和DTO属性事先命名约定以此种方式约定作为映射关系无需增加任何配置文件和配置工作即可实现2. 2.状态和流程
管理既然是业务逻辑
部分就不应该耦合再表示层当中MVC(Model-View-Controller)模式提供了实现这目标思路方法Controller是整个方案核心它是个流程管理器来自UI所有命令和数据经过Controller分发给业务层或其他UI这样我们可以把流程权限等逻辑单独封装例如配置文件中达到最大化业务重用dotNet下MVC方案并不像Java下有那么多选择目前有以下几种选择: 微软
UIPAB它可以处理bscs下流程跳转可以使得相同业务系统有webform和winform区别展现方式 开源
Mavrick.Net它只适用于Asp.Net应用它对流程国际化页面包装xslt页面转换提供了很好支持 开源
Lattis同样只适用于Asp.Net应用 业务层
业务层封装了实际业务逻辑
包含数据验证事物处理权限处理等业务相关操作是整个应用系统核心因此设计个能够真实反映实际需要业务层是非常必要我们将实际业务具体分为业务数据和业务操作两部分业务数据
业务数据又是业务逻辑
核心最终业务数据将以种固定格式表现于内存中在系统各个层次间传输充当DTO角色表达业务数据方式般分为两种Table Model和Do
ModelTable Model是将数据库中
表直接映射成为业务数据对象这样优点是适合于机器操作ADO.NET直接提供了这种操作便利但对于复杂业务关系表达就很不直观只适合于业务需求和数据表对应关系很直接需要快速开发情况通常我们选用Data
或者强类型Data(Strong Typed Data)强类型Data支持编译时类型检查效率上要略高于普通DataData有很多方便特性:无需自己编写维护类支持序列化数据副本保存支持数据集合对Control控件绑定支持效果好微软提供了相应生成工具以及持久方案但缺点也是明显复杂数据表现不直观做为DTO在各个层次间传输尤其是分布式环境庞大体积相对缓慢例子化对于性能造成很大压力Do
Model则是根据实际业务按照现实方式用OO思想建模这样很适合业务复杂系统通常采用自定义数据实体(Custom Data Entity)方式表达自定义数据实体有着良好性能编译时类型检查数据表现方式非常直观符合实际业务操作方式等优点但需要自己定义维护类在分布式环境下需要自己编写序列化思路方法综合各种原因考虑
虽然业务简单对应直接系统我们以Table Model建模开发效率很高但难免保证系统日后不会变复杂因此出于复用性扩展性性能等方面选用Do Model建模为佳业务操作
业务操作负责对业务数据进行各种业务相关
处理例如验证流向整合事物权限等但它不负责有关对数据源操作它和业务数据关系设计有2种方式分离业务数据和业务操作
将业务数据单独封装到只有数据get数据类中这个数据类只充当DTO将业务操作封装到独立service类中和业务数据起充当业务层这样当系统不复杂时候显简单直观而随着系统日益复杂service类会变杂乱而将本身耦合紧密数据和操作分离对于复用也是不利原因具体可参考Martin Fowler 贫血Do Model文但我并不倾向于业务层直接访问数据源 整合业务数据和业务操作
将业务数据和相关业务操作封装在起称为业务实体业务实体作为统业务层为表示层提供服务同时也负责作为DTO在各个层次间传输我倾向于这样完整Do Model设计方式每个业务实体都可以做为个单独组件形式存在对于组件化复用有着莫大好处业务模块间
依赖 各个业务模块的间
依赖有时候会是难以解决问题尤其是些可以重复利用业务组件例如权限管理邮件发送等等管理好这些各种区别业务组件是我们目标IoC容器为我们提供了最完美方案通过它将区别模块注入到系统中我们可以在不知道这个组件存在情况下它但目前只有不成熟Spring.Net个选择我们只有声叹息因此也就不多讨论了 业务数据访问层
业务数据访问层是
个针对具体应用系统专属层它为业务层提供和数据源交互最小操作方式仅仅是业务层需要数据访问接口业务层完全依赖业务数据访问层所提供服务这些服务负责从业务层接收数据或返回业务实体它屏蔽了实际业务数据和机器存储方式差别当然数据层选用抽象解决方案同样可以达到这个效果但业务数据访问层最大特点就是针对具体业务做抽象而抽象数据层访问方案是针对通用做抽象往往业务中针对具体设计生命力会变更强这样我们可以最大限度保持了上层代码复用性当需要更换存储策略如果数据层访问差别太大通过更换数据层无法解决问题时候我们最多只需要更换业务数据访问层而无需改变业务层业务数据访问层由DAO(Data Access Object)层和系统服务层两部分组成
DAO层为每个业务实体提供最基本数据访问服务系统服务层为系统全局提供和业务关系不大通用数据访问服务这两层处于系统中同个层次位置业务层和业务数据访问层关系图
数据层
数据层
宗旨就是为数据源提供个可供外界访问接口我们应该选用种能够提供数据源无关抽象数据访问接口并通过在其下挂接各种区别DataProviador来访问数据源数据层组件这样做便于移植到区别数据源上目前有以下3种数据层方案:1. 1. 封装ADO.Net
这些数据访问组件都是基于ADO.Net
浅封装它优点在于封装层次低所以速度最快我们可以手动组织sql语句用来适应复杂操作以及个性优化等缺点是无法直接处理自定义数据实体方式业务实体对象需要将业务实体中数据属性以参数形式传入传出这样方式虽然最为保险但随着系统规模增大开发效率质量后期维护 2次开发都变成尤为突出问题对开发人员要求会变越来越高另外对于事物操作封装不是很好无法提供声明性事物经常会在业务层出现访问数据层需要这样组件目前应用很广泛例如微软在EnterpriseLibrary中提供DAAB(Data Access Application Block)还有以前DAAB3.1EnterpriseLibrary是个成熟产品包括了数据访问异常日志缓存Cache加密配置,安全等组件做为通用服务非常适合 2. 2. OR-Mapping组件
ORM是最好
数据持久解决方案它优点在于能够以面向对象方式操纵数据因此可以直接处理自定义数据实体业务对象我们根本不用操心sql语句以及底层存储方式这样极大简化代码提高了开发效率对于日后维护扩展都带来极大便利缺点在于屏蔽了底层使得我们无法针对具体数据源做优化而且对于复杂关联sql操作有些力不从心同时性能也差些但辅助以缓存Cache情况会好很多而在dotNet下最大问题就是没有个成熟便宜ORM产品供我们使用全部都是beta版本和商业版本这些版本或多或少都存在些问题以至于真正应用中需要经过仔细考察例如NHibernateGentle.NetXPOGrove.Net等等非常多3. 3. DataMapper(SqlMapper)
SqlMapper为以上两种方式提供了
个折中选择它可以以面向对象方式直接处理自定义数据实体业务对象同时可以根据和数据源和业务实体映射关系执行手写sql语句这样完全使得我们可以针对具体数据源做优化对于复杂操作同样可以胜任目前只有iBatis.Net个产品它是个java移至开源项目已经比较成熟可以在无需编译情况下随意替换DAO 至此
整个架构方案讨论已经完成我们可以看出dotNet下可供选择解决方案是那么有限反看Java世界有那么多成熟可供利用组件框架流口水中...不过dotNet也正在走向成熟我们需要时间等待这个架构设计思路只代表了我个人理解而且也并不是说所有开发都是这么套方案在具体环境中需要做具体调整希望能起到个抛砖引玉作用我邮箱是i-simon AT msn.com由于我经验尚浅有不正确或不足地方欢迎指正讨论另外本文将根据技术最新进展持续更新
最新评论