关于重复代码的存在是否合理的判定

根据CRUD，一般我会在DAO里面创建insert,findBy*,update,delete等方法，而在业务逻辑层,我以DAO为根据来划分相应的子程序，但这个时候常常会出现重复的代码。

比如：

我会在一个MultiActionController里面分别定义insert,update,find,delete四个方法，这四个方法是与DAO完全对应的，但insert和update基本上是重复的，唯一的不同就是insert是新生成id，而update时，id是从post数据获得。但我都是insert(Model),update(Model),连model的封装都是一模一样的，完全没有区别。有时後我想是否可以将insert和update合并，然后通过判断post数据是否存在id来决定事添加新数据还是修改已有数据。又或则本身这样的重复是可以接受的呢？

除了上面的情况，实际开发中还会有很多会机会面对这个问题，但感觉如果通过合并来减少重复，那么削除重复代码就会导致方法的粒度较粗，可能在以后的重构或是扩展上面增加难度。


遇到这样的情况，该如何去设计呢？

DAO消除重复代码，参考： GenericHibernateDao

类似的重复代码，可以考虑通过<基类+范形>的形式进行重构

大概看了下，就从文章来看是比较漂亮的解决方法，或许正是我想要的，现在我用的是ibatis，对于每一张表都有一个对应的DAO接口，一个DAO实现以及一个配置文件，若这样，那么增长的就只有配置文件了。

的确削除了代码重复，但不知道这样做有没有什么副作用？有实际项目经验的能否告知一下。

个人不是很喜欢DAO

dao是无奈的产物，有了范型，dao可能会在设计中被弱化，甚至消失。

这一种方法可行；
但像很多公司的系统都运行在jdk1.4上的，不能一下子现在全部的公司都采用了比较新版本的JDK来开发设计

的确，很多的系统只能使用jdk1.4，比较令人遗憾。但通过设计的取舍还是能减少不少代码。很多设计，往往为了几乎不会出现的数据库的移植，而做出很复杂的设计。

可能有点跑题，发现不少人对DAO不是很喜欢，但我在开发的过程中觉得，DAO除了将业务逻辑与底层持久化sql语句分离开，让我更专心于业务逻辑的实现，而且还使持久化代码编写人员与业务逻辑代码编写人员并行开发变得十分轻松，通过泛型可以削除重复代码的话，那么DAO有何不妥呢？或是有更漂亮的方法？

没有觉得Dao是多余的么?

是否是指在有Hibernate等持久层框架的前提下？或是让域对象具有持久化逻辑。

  目前项目中的持久层框架是ibatis，仍然在使用Dao interface+Dao impl这种形式。