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存在，就有存在的理由，一定存在一種均衡之道。最后說明，我不是在分享經驗而是表達自己的疑惑（正如標題所言），我希望大牛們能為我指點迷津。