设计思想二

我在项目中的分层是:Action->POJO/VO->service(接口+实现类)->DAO((接口+实现类)
   Action:接收用户请求、获取用户输入的信息、调用Service、控制页面跳转等
   POJO/VO:POJO是包含set/get方法的值对象，一般是用MyEclipse生成，一般一个表对应一个POJO类，主要供其他业务逻辑存、取表单值。
   Service:获取数据库连接、处理事务、处理数据回滚、调用DAO
   DAO:专职负责与数据库的CRUD操作

   大致流程是:客户提交请求->进入对应的Action->Action调用Service->Service调用对应的DAO中的方法 ->返回操作状态(一般是true/false)->根据操作状态由Action决定跳转到某个页面->显示用户请求结果

Action->POJO/VO->service(接口+实现类)->DAO((接口+实现类)
是目前Java书本中通用的写法。

个人以为并不适用于商业项目的开发。
如：
Action中调用大量Service方法，Service接口变化将是灾难。
一个Action中调用多个Service，在分布式环境下事务无法控制。
架构难以扩展以集成WebService/EJB3等集成分布式技术

aseAction-->代理类-->Service-->DAO
action通过代理来调用Service(的方法),这个Service(的方法)是在配置文件里面配置的,通过反映机制获得,然后在Service里面操作业务,必要时调用DAO.
具体如下:
  1.BaseAction是一个抽象类,它的字类至少有两个方法,一个方法用来处理请求数据,一个用来处理response数据,这两个方法的签名为:
       a)处理请求的方法: public BaseDTO prepareMethodName(){} 方法名任意,通过配置文件配置
       b)处理响应数据方法: public String  processMethodName(BaseDTO);返回值为String型,因为我们用struts2;
  2.BaseAction调用处理请求的方法,获取请求参数BaseDTO,通过代理传递给Service;
  3.Service方法签名为 public BaseDTO serviceMethodName(BaseDTO) throws ServiceException;
  4.Service将响应数据封装成BaseDTO通过代理返回给BaseAction;
  5.BaseAction调用响应请求的方法,最后跳转到其它请求

注:
  这个代理可以是普通的类实现,也可以是EJB实现(这样兼容了分布式)
  DAO定义了自己的标准的接口,独立于任何ORM(只要这个ORM可以提供DAO的接口实现即可)

Action-->代理类-->Service-->DAO
应改为
Action-->BIZ Proxy-->BIZ ACTION-->BO-->DAO

 

 

DAO层当前应该存在，原因如下：
1,必尽还是关系数据库的时代，还有对于数据库访问不同数据库还是有存在差异，用DAO层实现来解决差异，除非ORM足够强大，根本不存在。
2,DAO分担业务层的逻辑（小逻辑），就如domain层实体里不光是setter,getter的原里一样。但这层逻辑业务仅针对DAO对应的domain层相关逻辑，否则建议到service层。
3,service层应该是主要业务逻辑，不关心应用逻是什么，service的逻辑接口应该永远不了，除非业务改变。个人认为我们的业务主逻辑 图都在service层，再配罗dao的小逻辑，（千万不要把hibernate的HQL，或者 相关SQL在这里中写逻辑，初学者误区）。
4,DAO可以认为是大海，有无穷的资源，而service是大海上的船，是dao层上按需所取，船下的海域就是不同dao的小业务逻辑。dao与entity应该是强偶合性的，service以上是松偶合。
5,service不光要dao层，还是分布式，远程访问。就是银行转账的扩展。一般应用都是调用银行接口转账，还有相应的业务关联。转账可能不是一个事务的问题了（当然业务层的设计也可以解决，只是简单举例）