三层结构的问题

最近新进一家公司，做一个后台系统，用的是ssh框架。
系统结构是module，dao，service，web这种结构分的。
我很不解的就是他们一张表对应一个dao，然后service里又是同样的方法只是调用了一下dao什么也没做（相当于把dao层copy了一遍），然后基本每个dao里面做的事都差不多，增删改查分页条件查询之类的。
感觉跟我以前的习惯很不一样，我的做法是写一个通用的dao包含了大多数的常见操作，如果需要扩展可以去继承他。个人觉得也很方便。现在做了一段时间越来越糊涂了，dao层到底该怎么弄，一个实体对象对应一个dao还是写个具有通用性质的dao？求解

解决方案 »

  1.   

    基本上都是一个实体一个dao 重用度高，
    楼主的通用dao是怎么写的  ，自己用sql实现的吗，还是用到什么orm框架（比如hibernate）
      

  2.   


    hibernate写的，现在按照这个公司的模式，想在service里加个方法就得到dao层里加个一样的方法，就在哪里copy来copy去的。
      

  3.   

    为什么想在service里加个方法 就必须到dao层里加个一样的方法？
      

  4.   

    请问下楼主，如果一个项目有100张表，假设一张表只提供增、删、改、查4种方法，那对于你的通用dao里就有400多个方法，这样好么，如果是多人开发呢，，如果有svn代码管理呢？可以同时允许多个开发人员修改你的通用dao文件么。
    再有就是你说的service里和dao里的代码一样。那只能说明你的业务逻辑很简单而已。。不能说明别的什么问题。
      

  5.   

    我觉的你们公司的做法 重用度  和可维护性都要好 
    1.重用度高    service里如果需要调2个以上的dao ，按你的描述现在只调了一个 优势变成的柔势 ，但是一但复杂些就看出优势了。2.可维护性好  比如某个表改了   你只需改相应的dao就可以了，不会影响到service层   也就是你的业务相关代码都不需要改，  3.耦合底  甚至你换个dao ，service层是不需改的当然我说的这些 都是在项目越复杂越管用的，如果一个简单的项目自然就是多余的。
      

  6.   

    service业务层，业务层负责具体的业务逻辑，比如银行转帐，我先要给a公司扣掉100块，再给b公司加上100块，这时就可以在service先调a公司的dao,再调b公司的dao,其间还有手续费等等的dao
      

  7.   

    module里只配置数据库表对象
    dao里对应每一个表单数据库操作
    service业务逻辑处理代码，如这里可以调用多个表的dao以完成你的业务需要
    web这里写你jsp页面的请求action这样开发的好处是，同时可以和多个同时一起开发，以项目模块为一个包，各不干涉，提高开发效率。
      

  8.   

    有400多个方法那还叫通用的么。java泛型 4个方法就搞定了。。况且hibernate在增删改查的时候接受的都是object对象，我只要把参数类型给成object的就可以了，干嘛对每个特定的类写一个？
      

  9.   

    ++
    一个人开发最快的方法是把代码写在JSP里，最方便，最省事。可以全部用JSP，一个JAVA都不用。何谈SSH，说实话，对简单的系统，SSH只会让事情变得更复杂。特别是Spring.
    个人觉得当系统越复杂越能体现SSH或者MVC的价值...小系统参考大系统的结构也不是不可.
      

  10.   


    当然是通用Dao了，一个实体一个dao，这是在锻炼Ctrl+C跟Ctrl+V的能力吧；Service处理不同的业务逻辑，数据库的交互使用一个Dao实现。
      

  11.   


    你没有理解我的意思，数据库的操作往往就是增删改查这几个操作，在使用了hibernate之后这些操作更加简单，比如save我在dao里面写一个save(Object o)这样的方法所有的实体对象都可以存进数据库，如果需要更多的操作可以通过继承来实现总的来说就是将一些通用的方法抽象出来，不同的地方再去进行相应的扩展。
    而且如果真有100张表一张表一个dao光增删改查都要写死人了
      

  12.   

    通用DAO---通用DAO的实现
      |
    实体dao继承通用dao---extends通用DAO的实现，impl对应的dao
      |
    对应service
    .......想了一下不知道这种结构怎么样，因为有些地方确实需要一些不同的操作。。就是把那些常用操作进一步抽象出来
      

  13.   

    其实有插件可以将数据库的表导成Hb,包括XML,jabaBean,还包括增\删\改\查的DAO.这样下来也就通用了.当然不一定实用.
    如果应用只要一个DAO就可以满足了,那当然好.
    甚至可以直接做成像.NET里的datagridview的东西.更不错,本人最近就考虑做一个这种玩意儿,以后小应用里的数据库操作, 就方便了
      

  14.   

    save（object），update（object），insert（object）这3个方法可以抽象出来
    但是查询的话，貌似不好抽象出来，查询条件，查询的object，对于查询的。我想问下lz你是怎么抽象出来的
      

  15.   

    你是认为一个项目都会让你一个人写代码吗？如果有100张表的话，也不是说都要你一个人写增、删、改、查啊。光一个查询就可以写好多语句。你公司的这个开发模式是多人开发的模式。你说的那个意思我了解，但是如果项目稍大，需要同时几个人一起开发。你说的这个继承通用dao就没有什么意义了
    不知道你有没有明白我的意思。
      

  16.   

    LZ 我想问一下  你写个 通用的  dao   然后 server 层  调用这个 dao 来进行数据库操作那么 server 调用的时候 就一定需要传递一个的 控制参数   表名也好  字段也好  XML也好 总之是传进去对于简单的业务逻辑  这无所谓了  反正 server 里也就那么几句   要是逻辑复杂的呢？ server里写了一堆逻辑运算 多个表之的数据 在内存来回的使用  好现在用的 方法也写完了 没有bug 可以正常使用了  我突然要改逻辑了原来是 表A取数据放到表C  现在要 表B放到表C（逻辑很复杂有个几百上千行代码）  你怎么改   去找到所有传递 表A名字的 改成 表B的吗？   过个 半年一年的让你来改 或者交给其他人来改  代码还缺少详细的注释  我想分析代码是个功夫活吧。要是一个DAO对应一个表呢？  你只需要在  得到 dao 的地方修改一下   要是用了 spring的思想就更好了 修改一下 对应实现分层结构 不是说能让我开发多么的省事 恰恰多了很多调用的步骤 我刚开始写代码的时候也觉得 只要调来调去的麻烦不麻烦啊，逻辑往哪一写就用呗    但是当你做过这样的工作之后你就知道 分层的好了 就是 项目已经进入生产阶段  现在突然来个需求变更  而项目的设计和实现跟你一点关系没有 现在要你来修改  给你个源代码  并且代码层次混乱 逻辑复杂 缺少必要的注释 这时候你就会知道看这样的代码是多么的爽了
      

  17.   

    多人开发通用的dao为什么没有意义？
    如果没有额外的逻辑附加当然可以通用一个，就算有额外的附加继承扩展就可以了！为什么非要和人数来扯上关系？
      

  18.   

    通用DAO的方法是可取的，对数据库的操作无非就是增删改查。每个表对应一个DAO，这些DAO做的工作都是基本一样的，没有必要。
    增删改这些大家似乎没太大的意见，就是查询的时候，条件不同，结果不同等等，这个就麻烦一点，其实也有办法解决，就是把SQL
    都放到配置文件中，再写一个解析SQL的类即可（听起来比较麻烦，对一个大型项目来说还是值得的）。
      

  19.   

    看项目的大小来定吧!不过我强烈建议各自用各自的DAO!这是很必要的!
      

  20.   

        那只能说明是你在滥用ddd而已（不要反感，我说的是实话，哈哈），推荐你多学习ddd。 可以去jdon.com去去， 这方面是个不错的网站。当然我也是有同样的遗憾，正在学习中祝楼主天天向上!