Dao和Service设计的一点疑问.

在开发中我是用DAO/SERVICE来处理的,可是在开发过程中出现了一点疑问:在我理解的DAO中,只是简单的操作DB,应该没有与业务逻辑相关的东东;比如一个雇员对象,有唯一的雇员id(emp_id),有唯一身份证号(id_card),假设在系统实现中,两个id都要唯一,也就是在插入的时候不仅检查emp_id唯一,还要检查id_card的唯一.现在的问题是,这个插入检查应该在DAO还是SERVICE,感到很疑惑!
   我的理解:这种检查操作,应该是与业务相关了,应该放在Serice层,但是在DAO的整体操作来看,放在DAO层也不是说不过去. 
   希望有设计经验之士多多指点

可以在数据库里面做啊，emp_id为主键，id_card这个字段加上unique约束就可以了么

既然是业务相关,那就放到service层

也是个好的建议，可是于我讨论的主题关系不大。

放在service层感觉，又好像把dao的一部分功能挪到service。


其实我讨论的是大家对于Service和Dao层比较复杂的时候，而且两者之间又没有那么泾渭分明界限的时候，大家有什么好的经验指教
那个雇员的例子只是一个再简单不过的说明

与业务相关的处理应该放在业务层，那你的例子来说：dao提供的方法应该是获得id_card符合条件的记录集，而在service提供的方法则应该是判断这个集合的个数，从而判断id_card是否唯一。

dao只负责数据库操作，不涉及业务
service负责处理业务

谢谢友好的建议,让我澄清了本来模糊的感觉

如果仔细想一下一个登录程序，那么楼主的问题应该不难解决，一个登录总该包含：成功登录，用户名不存在，密码出错等，这些是写在DAO中还是在Service中呢？答案应该很明显吧。

事实上，很多人写程序没有Service这一层，我觉得不太好理解他们的思路。

看到高手们如此热心指教,现在总结一下:
[list]在Service层,不应该看到任何与DB操作相关的处理,如果有那么,就可能把属于DAO功能抢了过来(最好不要这样,至少会造成移植和优化上的困难).
[/list:u]
[list]在DAO那里处理基本的CRUD以及各种需要查询接口,除此之外,最好少有逻辑的代码,但个人个人感觉这方面需要自己去实践,总结才能处理好DAO,否则很容易把Service的一些东东,拿到DAO中.
[/list:u]

  不当之处,还请多多指教!

按我的理解，这里的Service不是通常意义的Business Layer，而是指的Persistent Layer与View Layer的中间层，DAO实际就算Business Layer，不知道理解的是否正确

受益匪浅，    借这里的人气，问一个appfuse的问题，见附图， thanks

    public void saveObject(Object o); {
        getHibernateTemplate();.saveOrUpdate(o);;
    }
方法的saveObject（AppUser appUser）；和
-----------------------------------------------
    public void saveAppUser(final AppUser appUser); {
        if (log.isDebugEnabled();); {
            log.debug("AppUser's id: " + appUser.getUsername(););;
        }
        
        getHibernateTemplate();.saveOrUpdate(appUser);;
        // necessary to throw a DataIntegrityViolation and catch it in AppUserManager
        getHibernateTemplate();.flush();;
    }

的saveAppUser(final AppUser appUser);???
--------------------------
项目中用的都是 saveAppUser(final AppUser appUser);， 不知道 
saveObject（AppUser appUser）什么情况用 。？