service层是服务层，那么service层的接口应该由什么定义呢？
按照我的观点，既然是服务层，那么应该由你提供的服务决定。
假如我的user模块只提供三种服务，用户登录，用户注册，修改密码，那么我的服务层只提供三个接口：
UserService:
->login
->register
->modify
可是UserAction呢，想想UserAction几乎什么都不用做，只要调用service提供的接口就行了，这是不是有点傻瓜。
为了让UserAction显得不那么傻瓜，我打算让UserService不那么”聪明“。
UserService:
->findUser
->saveUser
->modifyUser
修改后的UserService"智商"下降了不少，现在的UserAction已经无法仅仅通过调用UserService提供的接口就能完成用户的登录和注册功能了。比如UserAction的登录方法：
public String login(){
if(userService.findUser(email,password))
[
return SUCCESS;
}else{
return ERROR;
}
}
虽然只是多了点判断逻辑，但起码比直接调用一个接口看着舒服一点。
可是问题似乎又来了，现在的UserService看起来和UserDao越来越像，UserDao本来已经实现的持久化操作，UserService又重新"抄袭"过来，这显得太多余了。所以这个平衡点该怎么把握呢？
现在我来总结一下吧：
首先第一种设计，我们把要直接提供给用户的服务封装到service中，虽然Action因此偷了一下“懒”，但起码有一点值得肯定，任何一个有英语基础的人，看到这个service的接口都知道我们提供了那些服务，换句话说我们的service似乎更像是服务层。
第二种设计虽然可以让Action显得不那么“笨”，但是我们的service却像是一个累赘：一个dao的复制品。而且你无法通过这个service看出它所提供的服务。虽然叫做“service”但却把对服务的封装交给Action，自己只是提供了一些对数据库的CURD。有点逗你玩的感觉。
不过我还是有一种类似于逃避的解决办法：当业务逻辑比较简单的时候，把service层去掉，直接在Action中调用dao接口。但既然service存在，就有存在的理由，一定存在一种均衡之道。
最后说明，我不是在分享经验而是表达自己的疑惑（正如标题所言），我希望大牛们能为我指点迷津。
相关分类