我同意LZ观点,是有点乱,一层负责一件事情,没必要让dao去解析HttpServletRequest之类的东西,还是分工明确一点方便以后修改和重构,写代码还是应该考虑以后的同事的感受的

解决方案 »

  1.   


    dao这块之前我一直是用一个中间层来封装后再调用,比如加个service层,然后在action中调用service,如果dao中传入formbean,那么明显hibernate的事务提交要放到dao,而如果一个业务有多条记录同时成功侧提交,那么就会发现dao臃肿混乱,其实这个传formbean可以看做一个偷懒的办法,让我难以接受的是传入request,我看他们代码传request主要是为日志及操作提示,难以习惯,当然也有人说只要能实现功能就行了,
      

  2.   

    支持一楼的,如果说要很清晰的来分析各层的用途,那么service也应该是一种业务逻辑层,主要用来进行一些逻辑处理,而formbean中会有很多的规则验证,而如果这些验证可能还会返回给客户端,这样的话,formbean更多的是为了得到数据,进行数据的处理,而并没有太多的业务逻辑.那么好了,再换句话说,如果说把formbean提交给service层去进行处理,那么这样的话,验证,事务都处于同一层,会不会显的service层很臃肿?而且在捕捉一些异常的时候也会变的困难.
      

  3.   


    恩,我的想法是这样的,service层是一个连接dao与action的中间层,
    formbean是与页面绑一起的,是属于表示层的,所以在action与service中调用,而pojo是持久层的,在dao与service中调用,2个类型会有区别需要转换,于是formbean与pojo的转换在service这个中间层中完成,我更倾向与dao只是简单的功能单一的操作,含业务的侧在service中,由service调用n个dao处理事物,如果formbean跑到dao中,也就是说页面与数据库层混淆在一起,有悖与分层开发的思想,
    而formbean你也说了只是一个传数据的载体,用它基本就是用get方法,而验证这过程侧是在validate方法中,可以说这个验证连action都没进更别说service了,action仅仅是servlet的封装传送数据而已,只须调用各个负责业务的service,业务本是复杂的东东,胖点属于正常把,
      

  4.   

    Request是跟容易相关的,这样DAO层就以来于容器了,这是不符合MVC的
    Formbean这个还有待商榷,如果Formbean设计的跟数据库Model一样的话,这样做也有一定的理由,不过这种可能性太小了。
      

  5.   

    孤陋寡闻,没怎么见过dao中有request这个参数