DAO与SERVICE层的疑惑

[quote="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等，看了很多相关的帖子，但是好像都没有我想要的答案，请教一下我该如何解决这个问题？[/quote]

[quote="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等，看了很多相关的帖子，但是好像都没有我想要的答案，请教一下我该如何解决这个问题？[/quote]

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:http://cwiki.apache.org/S2WIKI/struts-2-spring-2-jpa-ajax.html.<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>

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

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做具体的业务逻辑。

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的方式我更喜欢，也更适合目前的项目。

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