J2EE分层设计是Java企业应用的最基本的设计思想。
从最常规的分层结构来说,系统层次从上到下依次为:
表现层:主要是客户端的展示。
服务层:直接为客户端提供的服务或功能。也是系统所能对外提供的功能。
领域层:系统内的领域活动。
DAO层:数据访问对象,通过领域实体对象来操作数据库。
其中有些指导原则:
1、上层总是依赖其下层,依赖关系不跨层。
2、表现成除外,同一层之间方法不允许相互调用。这是实际开发中一些开发者容易范的错误!如果真是同一层之间存在方法调用,需要注意,这些调用都是一些上层不可见方法,比如一些工具方法等。
3、一切从服务层出发,从系统需要提供的功能进行分析,确定Service接口中的方法。而不是从数据库的表出发,创建DAO,再创Domain,然后Service,这实际上是对系统分层的误解。
4、系统最核心的设计就是将系统中的实体划分为领域模型。在此基础上设计数据的DAO层,并将这些活动暴露给服务层,服务层的实现依赖于领域活动。
5、每个接口的职责范围明确有界。
在我所做的系统中,常常看到一些糟糕的编码:系统设计从表开始,一个表对应一个DAO,一个DAO对应一个domain,一个Domain对应一个Service,实际上Service的接口和DAO的接口基本上完全一样!导致Service的接口方法超多!到了表现层,前台程序员在写Action的时候,Action中反复的调用Service方法,代码不堪入目。
正确的设计应该是,一个领域活动会聚合对应一个或一组DAO,来完成一个领域活动。而一个服务可能包含两个领域活动,比如一个转账的业务,对应两个领域活动。两个帐户的金额分别发生变化,需要操作一组领域活动,而每个活动需要操作很多表(调用多个DAO)。 事务的控制我们可以放到Service层。
目前,越来越多的架构师喜欢领域模型驱动设计,针对系统的领域模型建模,然后上层直接是Service,Service下面就是领域活动层Activity,从而去掉了DAO层,这样做的优点是系统设计思路更清晰,目标更明确。可以避免上面所说的一个表对应一个DAO、Service的情况。
但缺点是当领域活动发生变化的时候,会引起领域活动层代码的变化。并且,当要更换持久化框架或者技术时候,领域活动要重新实现。
但综合考虑起来,这样带来的优点也很多,而实际上更换数据库和持久化框架的情况很少,因此这样的设计也是有其合理性一面的。这样做实际上是将原来的DAO和Domain层合并为一个Activity.但上层的设计思路还是一致的。
其实Service层的设计也很讲究,其中就是要控制Service的数量,从Service层往下,接口数量逐层增加。通常将一个模块的服务都集中到一个Service中来处理。 网管网
每层中的每个接口都应该关注的是自己的那一块,而不是吃着碗里看着锅里,牛槽伸出个狗舌头,最典型的例子就是一个DAO中胡乱操作别的表。这种凌乱的实现只会置项目经理与死地。也会为软件的维护带来很大代价。
笔者曾遇到这样的团队,缺乏对整个项目的整体设计,一个表一个DAO,对应一个Service,系统也不大,三四十张表,但是性能相当地下,经常down机。
最终发现,失败不是开源框架和数据库以及应用服务器和硬件配置的错,根源在于拙劣的设计导致。
希望以后大家在做项目的时候能注意点。
原文出处:http://lavasoft.blog.51cto.com/62575/83974
分享到:
相关推荐
曾任LITEON公司的J2EE技术主管,负责该公司的企业信息平台的架构设计。曾任广州电信、广东龙泉科技等公司的技术培训导师。2007年3月26日的《电脑报》专访人物。现任新东方广州中心软件教学总监,并曾任广东技术师范...
曾任LITEON公司的J2EE技术主管,负责该公司的企业信息平台的架构设计。曾任广州电信、广东龙泉科技等公司的技术培训导师。2007年3月26日的《电脑报》专访人物。现任新东方广州中心软件教学总监,并曾任广东技术师范...
曾任LITEON公司的J2EE技术主管,负责该公司的企业信息平台的架构设计。曾任广州电信、广东龙泉科技等公司的技术培训导师。2007年3月26日的《电脑报》专访人物。现任新东方广州中心软件教学总监,并曾任广东技术师范...
国内知名的高端IT技术作家,已出版《Spring 2.0宝典》、《基于J2EE的Ajax宝典》、《轻量级J2EE企业应用实战》、《Struts 2权威指南》、《Ruby On Rails敏捷开发最佳实践》等著作。 目录: 第0章 学习Java...
第1章 Java应用分层架构及软件模型 1.1 应用程序的分层体系结构 1.1.1 区分物理层和逻辑层 1.1.2 软件层的特征 1.1.3 软件分层的优点 1.1.4 软件分层的缺点 1.1.5 Java应用的持久化层 1.2 软件的模型 ...
第1章 Java应用分层架构及软件模型 1.1 应用程序的分层体系结构 1.1.1 区分物理层和逻辑层 1.1.2 软件层的特征 1.1.3 软件分层的优点 1.1.4 软件分层的缺点 1.1.5 Java应用的持久化层 1.2 软件的模型 ...
第1章 Java应用分层架构及软件模型 1.1 应用程序的分层体系结构 1.1.1 区分物理层和逻辑层 1.1.2 软件层的特征 1.1.3 软件分层的优点 1.1.4 软件分层的缺点 1.1.5 Java应用的持久化层 1.2 软件的模型 ...
第1章 Java应用分层架构及软件模型 1.1 应用程序的分层体系结构 1.1.1 区分物理层和逻辑层 1.1.2 软件层的特征 1.1.3 软件分层的优点 1.1.4 软件分层的缺点 1.1.5 Java应用的持久化层 1.2 软件的模型 ...
DbHelperV2 - Teddy的通用数据库访问组件设计和思考 也论该不该在项目中使用存储过程代替SQL语句 如何使数据库中的表更有弹性,更易于扩展 存储过程——天使还是魔鬼 如何获取MSSQLServer,Oracel,Access中的数据字典...
为什么会获得成功,并告诉你我十分肯定它能帮助你开发J2EE 应用程序。 又是一个框架? 你可能正在想“不过是另一个的框架”。如今有这么多J2EE 框架,并且你可以建立你自 己的框架,为什么你应该读这篇文章...
在 Step1到Step3-Reflection的例子中,我们试图 利用“针对接口编程”以及自己设计的Ioc对系统进行解耦。在Step3到Step5的例子中,我们将利用Spring.net提供的Ioc框架,轻松完 成解耦以及系统改造等工作。 一、类...