层(layer)这个概念在计算机领域是非常了不得
个概念
计算机本身就体现了种层概念:系统
层、设备驱动层、操作系统层、CPU指令集每个层都负责自己职责网络同样也是层概念
最著名OSI 7层协议层到了软件Software领域也
样好用为什么呢？我们看看使用层技术有什么好处:● 你使用层
但是不需要去了解层实现细节● 可以使用另
种技术来改变基础层而不会影响上面层应用● 可以减少区别层的间
依赖● 容易制定出层标准
● 底下
层可以用来建立顶上层多项服务 当然层也有弱点:● 层不可能封装所有
功能旦有功能变动势必要波及所有层● 效率降低
当然
层最难个问题还是各个层都有些什么以及要承担何种责任典型
3层结构3层结构估计大家都很熟悉了
就是表示(presentation)层, 领域(do
)层, 以及基础架构(infrastructure)层表示层逻辑主要处理用户和软件Software
交互现在最流行莫过于视窗图形界面(wimp)和基于html界面了表示层主要职责就是为用户提供信息以及把用户指令翻译传送给业务层和基础架构层 基础架构层逻辑包括处理和其他系统通信代表系统执行任务例如数据库系统交互和其他应用系统交互等大多数信息系统这个层最大逻辑就是存储持久数据还有
个就是领域层逻辑有时也被叫做业务逻辑它包括输入和存储数据计算验证表示层来数据根据表示层指令指派个基础架构层逻辑领域逻辑中
人们总是搞不清楚什么事领域逻辑什么是其它逻辑例如个销售系统中有这样个逻辑:如果本月销售量比上个月增长10％就要用红色标记要实现这个功能你可能会把逻辑放在表示层中比较两个月数字如果超出10％就标记为红色这样做
你就把领域逻辑放到了表示层中了要分离这两个层你应该现在领域层中提供个思路方法用来比较销售数字增长这个思路方法比较两个月数字并返回boolean类型表示层则简单该思路方法如果返回true则标记为红色例子
层技术不存在说永恒
窍门技巧如何使用都要看具体情况才能够决定下面我就列出了 3个例子:例子1:
个电子商务系统要求能够同时处理大量用户请求用户范围遍及全球而且数字还在不断增长但是领域逻辑很简单无非是订单处理以及和库存系统连接部分这就要求我们1、表示层要友好能够适应最广泛用户因此采用html技术；2、支持分布式处理以胜任同时几千访问；3、考虑未来升级例子2:
个租借系统系统用户少多但是领域逻辑很复杂这就要求我们制作个领域逻辑非常复杂系统另外还要给他们用户提供个方便输入界面这样wimp是个不错选择例子3:简单
系统非常简单用户少、逻辑少但是也不是没有问题简单意味着要快速交付并且还要充分考虑日后升级
需求在不断增加的中何时分层
这样
3个例子就要求我们不能够概而论解决问题而是应该针对问题具体情况制定具体解决思路方法这 3个例子比较典型第 2个例子中
可能需要严格分成 3个层次而且可能还要加上另外中介(mediating)层例3则不需要如果你要做仅是查看数据那仅需要几个server页面来放置所有逻辑就可以了我
般会把表示层和领域层/基础架构层分开除非领域层/基础架构层非常简单而我又可以使用工具来轻易绑定这些层这种两层架构最好例子就是在VB、PB环境中很容易就可以构建出个基于SQL数据库windows界面系统这样表示层和基础架构层非常致但是旦验证和计算变得复杂起来这种方式就存在先天缺陷了很多时候
领域层和基础架构层看起来非常类似这时候其实是可以把它们放在起可是当领域层业务逻辑和基础架构层组织方式开始区别时候你就需要分开 2者更多
层模式3层
架构是最为通用尤其是对IS系统其它架构也有但是并不适用于任何情况第
种是Brown model [Brown et al]它有 5个层:表示层(Presentation)控制/中介层(Controller/Mediator)领域层(Do), 数据映射层(Data Mapping), 和数据源层(Data Source)它其实就是在 3层架构种增加了两个中间层控制/中介层位于表示层和领域层的间数据映射层位于领域层和基础架构层的间表示层和领域层
中介层我们通常称的为表示-领域中介层是个常用分层思路方法通常针对些非可视Control控件例如为特定表示层组织信息格式在区别窗口间导航处理交易边界提供Serverfacade接口(具体实现原理见设计模式)最大危险就是些领域逻辑被放到这个层里影响到其它表示层我常常发现把行为分配给表示层是有好处
这可以简化问题但表示层模型会比较复杂所以把这些行为放到非可视化对象中并提取出个表示-领域中介层还是值得Brown ISA
表示层 表示层
控制/中介层 表示-领域中介层
领域层 领域层
数据映射层 数据库交互模式中
Database Mapper数据源层 基础架构层
领域层和基础架构层的间
中介层属于本书中提到Database Mapper模式是 3种领域层到数据连接办法的和表示-领域中介层眼有时候有用但不是所有时候都有用还有
个好分层架构是J2EE架构这方面讨论可以见『J2EE核心模式』书他分层是客户层(Client)表示层(Presentation)业务层(Business )整合层(Integration)资源层(Resource)差别如下图:J2EE核心 ISA
客户层 运行在客户机上
表示层表示层 运行在服务器上
表示层业务层 领域层
整合层 基础架构层
资源层 基础架构层通信
外部数据微软
DNA架构定义了 3个层:表示层(presentation)业务层(business)和数据存储层(data access)这和我架构相似但是在数据传递方式上还有很大区别在微软DNA中各层操作都基于数据存储层传出SQL查询结果集这样话实际上是增加了表示层和业务层同数据存储层的间耦合度 DNA记录集在层的间动作类似于Data Transfer ObjectPart 2 组织领域逻辑
要组织基于层
系统首要是如何组织领域逻辑领域逻辑组织有好几种模式但其中最重要莫过于两种思路方法:Transation Script和Do Model选定了其中种其它都容易决定不过这两者的间并没有条明显分界线所以如何选取也是门大学问般来说我们认为领域逻辑比较复杂系统可以采用Do ModelTransation Script就是对表示层用户输入
处理
包括验证和计算存储其它系统操作把数据回传给表示层用户个动作表示个这个可以是script也可以是transation也可以是几个子在例子1中检验在购物车中增加本书显示递送状态都可以是个Transation ScriptDo
Model是要建立对应领域名词模型例如例1中书、购物车等检验、计算等处理都放到领域模型中Transation Script属于结构性思维
Do Model属于OO思维Do Model比较难使用旦习惯你能够组织更复杂逻辑你思想会更OO到时候即使是小系统你也会自然使用Do Model了但如何抉择呢？如果逻辑复杂
那肯定用Do Model:如果只需要存取数据库那Transation Script会好些但是需求是在不断进化你很难保证以后需求还会如此简单如果你团队(Team)不善于使用Do Model那你需要权衡下投入产出比另外即使是Transation Script也可以做到把逻辑和基础架构分开你可以使用Gateway对例2
毫无疑问要使用Do Model对例1就需要权衡了而对于例3你很难说它将来会不会像例2那样你现在可以使用Transation Script但未来你可能要使用Do Model所以说架构决策是至关紧要除了这两种模式
还有其它中庸模式Use Case Controller就是处于两者的间只有和单个用例相关业务逻辑才放到对象中所以大致上他们还是在使用Transation Script而Do Model只是Database Gateway组集合而已我不太用这种模式Table Module是另
个中庸模式很多GUI环境依托于SQL查询返回结果你可以建立内存中对象来把GUI和数据库分开来为每个表写个模块因此每行都需要关键字变量来识别每个例子Table Module适用于很多
组件构建于个通用关系型数据库的上而且领域逻辑不太复杂情况Microsoft COM 环境以及它带ADO.NET.NET环境都适合使用这种模式而对于Java就不太适用了领域逻辑
个问题是领域对象非常臃肿对象行为太多了类也就太大了它必须是个超集这就要考虑哪些行为是通用哪些不是可以由其它类来处理可能是Use Case Controller也可能是表示层还有
个问题复制他会导致复杂和不致这比臃肿危害更大所以宁可臃肿也不要复制等到臃肿为害时再处理它吧选择
个地方运行领域逻辑我们
精力集中在逻辑层上领域逻辑要么运行在Client上要么运行在Server上比较简单
做法是全部集中在Server上这样你需要使用html前端以及web server这样做好处是升级和维护都非常简单你也不用考虑桌面平台和Server同步问题也不用考虑桌面平台其它软件Software兼容问题运行在Client适合于要求快速反应和没有联网
情况在Server端逻辑用户个再小请求也需要信息从Client到Server绕圈反应速度必然慢再说网络覆盖程度也不是说达到了100％对于各个层来说
又是如何样呢？基础架构层:
般都是在Server啦不过有时候也会把数据复制到合适高性能桌面机但这是就要考虑同步问题了表示层在何处运行取决于用户界面
设计个Windows界面只能在Client运行而个Web界面就是在Server运行也有特别例子在桌面机上运行web server例如X Server但这种情况少多在例1中
没有更多选择了只能选在Server端因此你每个bit都会绕个大圈子为了提高效率尽量使用些纯html脚本人们选用Windows界面
原因主要就是需要执行些非常复杂任务需要个合适应用而web GUI则无法胜任这就是例2做法不过人们应该会渐渐适应web GUI而web GUI功能也会越来越强大剩下
是领域逻辑你可以全部放在Server也可以全部放在Client或是两边都放如果是在Client端
你可以考虑全部逻辑都放在Client端这样至少保证所有逻辑都在个地方而把web server移至Client是可以解决没有联网问题但对反应时间不会有多大帮助你还是可以把逻辑和表示层分离开来当然你需要额外升级和维护工作在Client和Server端都具有逻辑并不是
个好处理办法但是对于那些仅有些领域逻辑情况是适用有个小窍门把那些和系统其它部分没有联系逻辑封装起来 领域逻辑接口你
Server上有些领域逻辑要和Client通信你应该有什么样接口呢？要么是个http接口要么是个OO接口http接口适用于web browser
就是说你要选择个html表示层最近新技术就是web service通过基于http、特别是XML进行通信XML有几个好处:通信量大结构好仅需次回路这样远程开销就小了同时XML还是个标准支持平台异构XML又是基于文本能够通过防火墙虽然XML有那么多
好处不过个OO接口还是有它价值hhtp接口不明显不容易看清楚数据是如何处理而OO接口思路方法带有变量和名字容易看出处理过程当然它无法通过防火墙但可以提供安全和事务的类控制最好
还是取 2者所长OO接口在下http接口在上但这样做就会使得实现机制非常复杂Part 3 组织web Server
很多使用html方式
人并不能真正理解这种方式优点我们有各种各样好用工具但是却搞到让难以维护在web server上组织
方式大致可以分为两种:脚本和server page脚本方式就是
个用
和思路方法来处理http例如CGI脚本和java servlet它和普通并没有什么两样它从web页面上获得html 
形态数据有时候还要做些表达式匹配这正是perl能够成为CGI脚本常用语言原因而java servelet则是把这种分析留给员但它允许员通过关键字接口来访问信息这样就会少些表达式判断这种格式web server输出是另种html 称为response可以通过流数据来操作糟糕
是流数据是非常麻烦因此就导致了server page产生例如PHPASPJSPserver page
方式适合回应(response)处理比较简单情况例如“显示歌曲明细”但是你决策取决于输入时候就会比较杂乱例如“通俗和摇滚显示格式区别”脚步擅长于处理用户交互
server page擅长于处理格式化回应信息所以很自然就会采用脚本处理请求交互使用server page处理回应格式化这其实就是著名MVC(Model View Controller)模式中view/controller处理
web server端MVC工作流程示意图应用Model View Controller模式首要
点就是模型要和web服务完全分离开来使用Transaction Script或Do Model模式来封装处理流程接下来
我们就把剩余模式归入两类模式中:属于Controller模式以及属于View模式View模式
View这边有 3种模式:Transform View
Template View和Two Step ViewTransform View和Template View处理只有步将领域数据转换为htmlTwo Step View要经过两步处理第步把领域数据转换为逻辑表示形式第 2步把逻辑表示转换为html两步处理
好处是可以将逻辑集中于处如果只有步变化发生时你就需要修改每个屏幕但这需要你有个很好逻辑屏幕结构如果个web应用有很多前端用户时两步处理就特别好用例如航空订票系统使用区别第 2步处理就可以获得区别逻辑屏幕使用单步思路方法有两个可选
模式:Template ViewTransform ViewTemplate View其时就是把代码嵌入到html页面中就像现在server page技术如ASPPHPJSP这种模式灵活强大但显得杂乱无章如果你能够把逻辑逻辑在页面结构的外进行很好组织这种模式还是有它优点Transform View使用翻译方式
例如XSLT如果你领域数据是用XML处理那这种模式就特别好用Controller模式
Controller有两种模式
般我们会根据动作来决定项控制动作可能是个按钮或链接所这种模式就是Action Controller模式Front Controller更进
步它把http请求处理和处理逻辑分离开来般是只有个web handle来处理所有请求你所有http请求处理都由个对象来负责你改变动作结构影响就会降到最小
最新评论