Shao Fan

关于JAVA与软件工程
posts - 31, comments - 71, trackbacks - 0, articles - 4
  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

关于三层架构的一些想法

Posted on 2007-09-08 19:45 shaofan 阅读(5114) 评论(2)  编辑  收藏 所属分类: Java
目前开发人员对系统开发的一个共识是使用三层架构,分为表示层,业务层,和持久层。而这三层之间的依赖关系如何?比较常见的一种看法是

表示层 --> 业务层 --> 持久层

这表明了层与层之间的调用关系,表示层通过调用业务层来完成任务,而业务层则调用持久层。从另一个角度来看,一种依赖关系是

表示层 --> 领域模型(Domain Model) <-- 持久层

表示层和持久层都应该理解(recognize)领域模型。而领域模型则是业务层的一部分。业务层正是系统的价值所在。虽说表示和持久也很重要,在某些系统中可以说是很关键,但是它们的最终目的都是为业务服务,所以业务层应该是系统的核心

基于以上的认识,在系统设计的时应首先分析需求得到领域模型,找出系统中的实体、对象(静态的一面),并明确大致的业务流程(动态的一面)。 而另两层应尽最大努力为业务层服务,且尽量减少业务层受另两层的限制。


各层的职责:

表示层:负责显示信息,及从系统外部得到输入。表示层的设计决定系统界面的可用性,及信息输入和展示的可靠性。表示层只知道如何展示信息,及收集用户输入,并不知道该如何对这些输入进行处理来完成业务。

业务层:完成业务逻辑。业务层设计决定客户价值是否能够得到实现。这是系统的关键。外在的表现是功能性。业务层设计和实现的失误表现在用户端即功能缺失,功能不可靠等。如果需要对业务层的业务规则进行解耦,则可以使用规则引擎如Drools,把业务规则分离出来。但分离后的业务规则仍属于业务层。业务层知道如何对用户输入进行处理,能够应用业务规则完成用户所需的业务,但它不知道数据如何读取和保存。

持久层:负责用户信息的持久化。持久层的失误表现在外即数据处理(储存,展示等)不可靠。持久层完全不知道业务,只专注于数据存储和读取。所谓持久化并不一定是指数据库,任何方式的持久化(通过文件,网络的持久化等)都应由持久层完成。

各层的设计都会直接影响系统性能。

三层的体积大小和复杂度在不同的系统中可能会有很大的不同。比如说GOOGLE的搜索引擎,它的界面很简单,可以想像表示层是比较容易实现的,而它的业务层,关系到处理关键字,分析搜索结果,决定排名等,而持久层则要负责处理超大量的数据。业务层和持久层则相当复杂。而有的系统持久层会很小,比如杀毒软件,媒体播放软件等。业务层小而另两层大的例子暂时还没有想到:)



评论

# re: 关于三层架构的一些想法  回复  更多评论   

2007-09-10 00:08 by 阿牛..,
好文章,收藏!

# re: 关于三层架构的一些想法  回复  更多评论   

2007-09-10 13:45 by 编程、设计是职业更是爱好
这几个层次的划分没有严格准确的定义,适合的才是最好的。

只有注册用户登录后才能发表评论。


网站导航: