service層是服務(wù)層，那么service層的接口應(yīng)該由什么定義呢？按照我的觀點，既然是服務(wù)層，那么應(yīng)該由你提供的服務(wù)決定。假如我的user模塊只提供三種服務(wù)，用戶登錄，用戶注冊，修改密碼，那么我的服務(wù)層只提供三個接口：UserService:????->login????->register????->modify可是UserAction呢，想想UserAction幾乎什么都不用做，只要調(diào)用service提供的接口就行了，這是不是有點傻瓜。為了讓UserAction顯得不那么傻瓜，我打算讓UserService不那么”聰明“。UserService:????->findUser????->saveUser????->modifyUser修改后的UserService"智商"下降了不少，現(xiàn)在的UserAction已經(jīng)無法僅僅通過調(diào)用UserService提供的接口就能完成用戶的登錄和注冊功能了。比如UserAction的登錄方法：public String login(){????if(userService.findUser(email,password))????[????????return SUCCESS; ?? ????}else{????????return ERROR;????}}雖然只是多了點判斷邏輯，但起碼比直接調(diào)用一個接口看著舒服一點?？墒菃栴}似乎又來了，現(xiàn)在的UserService看起來和UserDao越來越像，UserDao本來已經(jīng)實現(xiàn)的持久化操作，UserService又重新"抄襲"過來，這顯得太多余了。所以這個平衡點該怎么把握呢？現(xiàn)在我來總結(jié)一下吧：首先第一種設(shè)計，我們把要直接提供給用戶的服務(wù)封裝到service中，雖然Action因此偷了一下“懶”，但起碼有一點值得肯定，任何一個有英語基礎(chǔ)的人，看到這個service的接口都知道我們提供了那些服務(wù)，換句話說我們的service似乎更像是服務(wù)層。第二種設(shè)計雖然可以讓Action顯得不那么“笨”，但是我們的service卻像是一個累贅：一個dao的復(fù)制品。而且你無法通過這個service看出它所提供的服務(wù)。雖然叫做“service”但卻把對服務(wù)的封裝交給Action，自己只是提供了一些對數(shù)據(jù)庫的CURD。有點逗你玩的感覺。不過我還是有一種類似于逃避的解決辦法：當業(yè)務(wù)邏輯比較簡單的時候，把service層去掉，直接在Action中調(diào)用dao接口。但既然service存在，就有存在的理由，一定存在一種均衡之道。最后說明，我不是在分享經(jīng)驗而是表達自己的疑惑（正如標題所言），我希望大牛們能為我指點迷津。