DAO与SERVICE层的疑惑

calmness

浏览: 350623 次
性别:
来自: 珠海

最近访客更多访客>>

monster丶sss

guoyouxi

gogo123150

liuyukui

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

Java

DAO JPA Hibernate Bean SSH

一直以来都是开发EJB的项目，对于SSH的架构仅仅只是处于了解而没实际开发过，最近正在将公司的一个EJB项目重构成一个SSH的架构，在实际开发过程中遇到了一些问题，其中一个就是持久层和业务层之间数据传输的问题。

在原来EJB项目中，都是使用实体BEAN进行数据持久的，而现在换成了DAO负责持久逻辑，一开始的时候业务层和持久层之间数据通信都是直接使用POJO进行，不再需要像以前使用EJB那样将DTO的数据set到实体BEAN上，减少了很多不必要的代码，刚开始的时候觉得挺爽，可是后来发现一个问题，那就是在service层调用DAO持久一个POJO后，POJO将变成PO，DAO持久方法将会返回一个对象，而我目前的做法就是直接返回一个PO到业务层，可是现在发现这种做法存在不恰当的地方，那就是PO在业务层的话，结果就将业务层与持久层相耦合，而DAO层的作用也因此而消弱，但是如果我不是直接返回PO的话，那我又要构造一个VO返回给业务层，那这种做法不是又回到原来EJB的方式上？而且这样我也无法在业务层上获得HIBERNATE很多优化性能功能，例如lazy load等，看了很多相关的帖子，但是好像都没有我想要的答案，请教一下我该如何解决这个问题？

分享到：

JPA，感觉有点鸡肋 | Dao控制事务设想，线程级事务处理

2007-11-30 23:32
浏览 8123
评论(27)
论坛回复 / 浏览 (26 / 17421)
分类:企业架构
查看更多

27 楼 zhendeshiming@ 2008-10-31

The last packet successfully received from the server was55089 milliseconds ago.The last packet sent successfully to the server was 55089 milliseconds ago, which is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem，
谁来告诉我这个是怎么回事？如何解决啊！！！！！！！！！！

26 楼 sbpya 2008-10-13

25 楼 byduke 2008-05-01

没看太理清楚楼主写的东西，主要是写的太密集啦，多换几行看起来就能好点。

如果说你问的是层和层间的对象传递的话，dao层可以以返回值的情况给service，然后service里面可以使用ThreadLocal对象，把得到的东西传递到表现层，其实dao->service貌似也可以这样做，不过好象没啥必要哦

对于楼主说的lazy load的问题，可以使用open session in view的解决方案还是可以的，不过我也听有的人说干脆不关闭session,不过我认为这种方法不是很可取，毕竟等待自然释放不是一个很好的选择

24 楼 jackzhangyunjie 2008-03-30

为什么不把所有的东西用接口去做呢，Java提倡使用接口进行操作。
你可以把你的Services只注入DAO的一个接口对象呀，同时在前台调用的时候只要把Services的接口进行简单的注入就可以进行你想要操作啦。

23 楼 cindy_taozhiang 2008-03-28

sys53 写道

关于DAO SERVICE 一些个人看法
DAO层主要工作访问数据，有这了一层不用关心数据的来源,如果使用HIBERNATE，那么不用关心是直接连数据库，还是从一级缓存还是二级缓存中的数据。
SERVER个人认为是一些业务层的逻辑运算
使用SSH，如果有OPEN SESSION IN VIEW，如果基本是把PO与VO二个概念相对混淆了。特别是VIEW层直接把PO到表现层上去。使用了OPEN SESSION IN VIEW，读数据是根据页面展示所需自动从DAO中获取。对于开发企业业务功能，采用此模式已经足够了。但如果系统是一个超大容量的计算，如运营系统，这样的设计就可能有问题，即分层不清晰而引发各类问题，也不能很好的支持分布式计算。如果表现层就用VO，那么系统可以很好的解藕,因些把OPEN SESSION IN VIEW 去除掉，增加一层DTO，即SERVICE层有DTO的功能，当然这个DTO功能就是因业务需要VO到哪一层的问题，也就是控制对象粒度问题，大部分情况这些都是根据表现层来解定的。如果已有VO不能满足表现层展视的数据，那么在SERVICE层中的DTO就把PO2VO时，把需要的数据给VO。
个人在开发时在struts1时，DTO就要是把PO转成FORM BEAN,但做保存时，把form 转成 vo 通过hiberate session 接口持久成PO。当然当时的项目也主要是普通企业应用。
现在用struts2开发时（webwork），已把form bean概念去掉了，直接把实体bean”作为form bean"这样叫法可能让没有接触过struts2的struts1开发者能够更能理解struts2，因为vo/po都用同一个实体bean，因此通过OPEN SESSION IN VIEW,直接在页面把po数据在页面展示出来。或者把open session in view 不要，把service的po转成vo后在页面展示。

嗯. 不错这个思路清晰多了是我明白了不少.

22 楼 sys53 2008-03-09

21 楼 chris_lve 2008-01-02

1949说的好啊,虽然没看懂几句 ;) ,一些系统中的单dao其实很像是PersistanceManager,个人觉得最大的问题是struts1中的 actionForm.POJO才应该是领域中实际的对象

20 楼 coffee9527 2007-12-04

我真的很欣赏你的简单就是美，其实我们使用的任何框架的最终的目的就是为了简化我们的设计，从而提高我们的效率。这个才是最终的目的。至于他的效率，当然也是我们设计的时候应该考虑的必要因素，但是如果hibernate的这个方面你认为不能满足你的要求的话可以考虑其他的技术或者手段。

19 楼 calmness 2007-12-03

我看了下JPA，原来是JAVA的一个持久标准，虽然统一了持久接口，可以透明的使用不同的实现，不过我觉得DAO层仍然是需要的，最起码把持久逻辑的放到业务逻辑中就不应该，DAO并不多于。不过我目前的DAO的hibernate实现可以替换成hibernate的JPA实现。

18 楼 calmness 2007-12-03

fxy1949 写道

Exactly as you did. If put it in EJB language,they are "Session Bean" implementing busines logic, and "Entity Bean" representing data.

这种做法和以前EJB的做法确实没什么太大的区别，说实话，我目前也只适应这种方式，真要叫我完全OO，然后全部充血模型，我头都会大，我觉得那样就太过教条了，而且很容易出现问题，要求太高了，反而我觉得这种facade的方式我更喜欢，也更适合目前的项目。

17 楼 fxy1949 2007-12-03

Exactly as you did. If put it in EJB language,they are "Session Bean" implementing busines logic, and "Entity Bean" representing data.

16 楼 calmness 2007-12-03

fxy1949 写道

calmness 写道

POJO应用于所有的层面会否真的没问题？而且也暴露了领域对象，很容易造成混乱，难道像POJO IN ACTION中那样，加个限制级接口减少暴露？不知道struts2和jsf是怎么处理的，我先去仔细了解下先。特别是JPA，如你所说能完全取代DAO，这个我最感兴趣，不过却不了解，去了解下先。

For me,"domain objects" is a type of POJOs that only has data,almost no business logic. Another type of POJOs contains business logic,for example,"stateless beans" in EJB3 or Java Bean in Spring.

As for "暴露了领域对象，很容易造成混乱",I think "domain objects" should be transparent and shared by all the layers. In contrast,the POJOs that implement the business logic should be confined to its boundary,by adding interface.

JPA is not designed to replace DAO, they are different concept. Put it in another way, using JPA will make the DAO layer seem to be redundant if it is a small system.

那你所谓的another type of POJOS 和 only has data 的POJO是什么关系呢？包含、继承还是一个包含业务逻辑的service实现？我目前的实现就是POJO包含数据以及少部分与持久无关的逻辑即贫血模型，再做一个service做具体的业务逻辑。

15 楼 fxy1949 2007-12-03

calmness 写道

14 楼 calmness 2007-12-03

13 楼 fxy1949 2007-12-03

Sorry for duplicate posts. The editor just drives me mad.

12 楼 fxy1949 2007-12-03

When using SSH(Struts+Spring+Hibernate), data transform and transfer is painful, usually, from ActionForm(Web) --> VO(Service) --> PO(DAO) .... --> <st1:place u1:st="on"><st1:place w:st="on">PO</st1:place></st1:place> --> VO --> ActionForm. As for EJB2, it is very similar that you have to convert ActionForm(or whatever other objects depending on what web layer framework you use) into DTO(Data Transfer Object) and then into Entity Bean.<o:p></o:p><o:p></o:p>
However, that is the cost of layering your application, which makes your system more flexible and loosely coupled.<o:p></o:p><o:p></o:p>
The problem is when using the above architectures, there is too much duplication of classes and its “getter and setter” and too much simple “copy” of code. For system maintenance and extension, it’s a nightmare. <o:p> </o:p>
So I would say your problem is not only about passing data from service layer into DAO layer, but also about transferring data between different layers in system. <o:p></o:p><o:p></o:p>
The solution probably is using POJO and new web frameworks and new Persistence APIs. <o:p> </o:p><o:p></o:p>
If you want to continue to use Struts and Spring, using Struts2+spring+JPA is your choice. If you are going to adopt EJB, using JSF+EJB3 is your choice. The key of both architectures is their using POJO(+Annotation) as the vehicle of data transfer and manipulation.<o:p> </o:p><o:p></o:p>
For example, JSF components can be directly bound to POJO’s field; JPA EntityManager uses POJO+Annotion as Entity Bean to manipulate data in database. Struts2 also discarded the ActionForm and uses POJO as HTML input or output value binding.<o:p></o:p><o:p></o:p>
<o:p></o:p>So put it simple, forget VO,DTO,PO,ActionForm, only use POJO(+Annotation),which is also called “domain objects”, you will find that the system becomes so clean and no any duplication for data transfer at all. <o:p></o:p><o:p></o:p>
<o:p></o:p>Here is a very good example for Strut2+Spring+JPA:<a href='http://cwiki.apache.org/S2WIKI/struts-2-spring-2-jpa-ajax.html'>http://cwiki.apache.org/S2WIKI/struts-2-spring-2-jpa-ajax.html</a>.<o:p> </o:p><o:p></o:p>
Anyway, you may still worry about using one single POJO in every layers; it probably makes the system tightly coupled. But in fact it does not. You have to change the way you regard the “domain objects”(POJO+Annotation), that move between different layers of the system,carring data, being presented, changed, saved into database, etc. These “domain objects” are the blood of the system, and can be used by Web Framework, Business Logic code, Persistence API. These “domain objects” almost only contain data and its getters and setters, or some small logic for conversion of data. They are the only artifacts created, used, changed, transferred by the components in every layers in the system.<o:p></o:p><o:p></o:p>
<o:p></o:p>As for JPA, don’t worry about it at all, it just absorbs all the essence of Hibernate and uses Annotation instead of hbm.xml. If you are familiar with Hibernate, it will not take you long time to master it.<o:p> </o:p><o:p></o:p>
Another issue is DAO layer seems to disappear. Yes, if you use JPA, write another layer of DAO seems to be meaningless. In my point of view, DAO is only useful when you use JDBC or a very big system with multi-layer even in business logic code. If you has already use ORM tool such as Hibernate, JPA, it really doesn’t give much benefit for the system, unless it’s a very big system.<o:p> </o:p><o:p></o:p>
I hope this will give you little help.<o:p></o:p>

11 楼 fxy1949 2007-12-03

calmness 写道

一直以来都是开发EJB的项目，对于SSH的架构仅仅只是处于了解而没实际开发过，最近正在将公司的一个EJB项目重构成一个SSH的架构，在实际开发过程中遇到了一些问题，其中一个就是持久层和业务层之间数据传输的问题。在原来EJB项目中，都是使用实体BEAN进行数据持久的，而现在换成了DAO负责持久逻辑，一开始的时候业务层和持久层之间数据通信都是直接使用POJO进行，不再需要像以前使用EJB那样将DTO的数据set到实体BEAN上，减少了很多不必要的代码，刚开始的时候觉得挺爽，可是后来发现一个问题，那就是在service层调用DAO持久一个POJO后，POJO将变成PO，DAO持久方法将会返回一个对象，而我目前的做法就是直接返回一个PO到业务层，可是现在发现这种做法存在不恰当的地方，那就是PO在业务层的话，结果就将业务层与持久层相耦合，而DAO层的作用也因此而消弱，但是如果我不是直接返回PO的话，那我又要构造一个VO返回给业务层，那这种做法不是又回到原来EJB的方式上？而且这样我也无法在业务层上获得HIBERNATE很多优化性能功能，例如lazy load等，看了很多相关的帖子，但是好像都没有我想要的答案，请教一下我该如何解决这个问题？

10 楼 fxy1949 2007-12-03

calmness 写道

一直以来都是开发EJB的项目，对于SSH的架构仅仅只是处于了解而没实际开发过，最近正在将公司的一个EJB项目重构成一个SSH的架构，在实际开发过程中遇到了一些问题，其中一个就是持久层和业务层之间数据传输的问题。在原来EJB项目中，都是使用实体BEAN进行数据持久的，而现在换成了DAO负责持久逻辑，一开始的时候业务层和持久层之间数据通信都是直接使用POJO进行，不再需要像以前使用EJB那样将DTO的数据set到实体BEAN上，减少了很多不必要的代码，刚开始的时候觉得挺爽，可是后来发现一个问题，那就是在service层调用DAO持久一个POJO后，POJO将变成PO，DAO持久方法将会返回一个对象，而我目前的做法就是直接返回一个PO到业务层，可是现在发现这种做法存在不恰当的地方，那就是PO在业务层的话，结果就将业务层与持久层相耦合，而DAO层的作用也因此而消弱，但是如果我不是直接返回PO的话，那我又要构造一个VO返回给业务层，那这种做法不是又回到原来EJB的方式上？而且这样我也无法在业务层上获得HIBERNATE很多优化性能功能，例如lazy load等，看了很多相关的帖子，但是好像都没有我想要的答案，请教一下我该如何解决这个问题？

9 楼 calmness 2007-12-03

coffee9527 写道

我觉得你在这里的说法有一些问题，我个人认为关于hibeinate这个框架，它解决的问题是使程序员摆脱原先的面向的关系的SQL语句的写法，使用java的面向对象的写法，使程序员在写代码的时候更加的方便，但是你却把它用来优化业务逻辑层，是不是与他的设计初衷有些违背。你是不是应该从这些方面考虑一下。

我并不是用hibernate来优化业务逻辑层，只是我在用到hibernate的时候，我必然要考虑性能这方面的因素，hibernate是ORM，但不代表不考虑它的性能，你这种说法有点过于偏激。

So懒写道

按面向对象的思想来说，并不存在你说的“PO在业务层的话，结果就将业务层与持久层相耦合，而DAO层的作用也因此而消弱”。
使用open session inview，把事务从dao层扩大到了业务层，在业务层po虽然可以访问持久层，但这是透明的，并没有对你的业务层代码有什么侵蚀。如果不用hibernate，用其他持久化技术，这个po将会是一个完整的对象。整个业务层接口和代码不会有什么改变。

使用open session in view不是把事务扩大到业务层，而是扩大到了表现层，这中间存在的问题就不多说了，还有从代码上来看确实是没有依赖于hibernate的地方，但是实际上还是依赖了，举个例子，一个update的方法，在业务层直接通过session缓存load到一个对象，然后通过set方法把值改变，因为缓存于session，我们不需要在最后加多一个dao.update(obj);就可以自动保存，这段代码在hibernate行得通，可是如果DAO实现用JDBC或者其他的框架实现呢？我们就要在那些没有这一特性或者有这一特性但是方式不一样的实现上改动业务层的代码，虽然代码上来看是透明的，但是实际还是会有依赖，这种依赖我自己称之为透明依赖，因为透明，也比较难察觉到。

不过这个问题在现在来说也不是什么太大的问题，我还是认为最重要不要太过复杂，能简单就尽量简单明了，层次分明就好。太过于在意反而会导致过度设计，带来不必要的复杂性，简单就是美，呵呵。

8 楼 So懒 2007-12-03

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论