在通用的j2ee應用分層結構中，經常發現有乙個叫service的分層，那麼這個service層到底是用來做什麼的呢 ？簡單地就字面理解來說， service，即服務，那我們可以叫它為服務層。既然作為服務層，那麼它的職責理應是為其他層提供服務。service層應該提供一些什麼樣的服務呢 ？
事實上，在mvc架構中，service層是處於比較尷尬的一層。因為你不能說它是屬於model層，也不能說它是屬於controller層，嚴格來說，它包含了model層和controller層這兩者的部分職能。為此，我們在開發不同規模以及不同型別的應用時，有時候你會覺得service層更多地偏向controller層，而在另乙個專案中它卻又好像是偏向model層。那麼在實際的專案中，我們該如何來把握service層更偏向於哪一層。下面我就兩種做法作一下簡要介紹。
一，首先，談談更傾向於controller層的做法。在這種情況中，service層事實上應該是要包含大部分business logic（業務邏輯）的，而這些邏輯則是通過介面的方式提供給action層（即controller）層來呼叫。 在action層中，只需要簡單地呼叫service層所提供的服務即可實現絕大部分邏輯，然後再通過vo（view object）將資料傳遞給view層。甚至通過service層拿資料後的組裝工作也可以放到service中去做，這樣做的好處是呼叫者僅僅只需要通過呼叫相應service層的介面即可實現完整的一整套的服務（不需要了解資料是如何組裝的），有點類似**向外界提供api那樣。此外，這樣做的另乙個優點是，當view發生改變時（如表現層技術從struts到jsf技術的變更時），新的constroller層只需要一層簡單地getter和setter方法的呼叫，而無需去理會如何進行資料的組裝。以為是service層傾向於controller層的一種做法，據我所知目前很大部分的公司是採用這種分層作法的。
二，service層傾向於model層的做法。在這類分層體系結構中，service層給人的一種感覺是它是在提供一些基礎性的資料服務。換句話說，它只是把model層原有的資料服務再進行了一定的組裝（僅少量涉及業務邏輯），之後作為介面提供給controller層呼叫。所以，實際上負責主要資料組裝工作(business logic，業務邏輯)的是在controller層，它不過是呼叫了service層提供的一些較為基礎性的資料服務。那麼， 這種做法相比第一種會有什麼好處呢 ？其實，它帶來的好處主要體現在分層架構上更加清晰，每一層都剝離得比較乾淨。從另乙個角度來講，model層、service層、controller層我們都可以較容易地進行剝離，大大地增加了靈活性。
以上為個人的一些觀點，如有不足之處，請不吝指正。
原文出處：
SSH框架中service層的作用
先直接copy乙份過來，慢慢消化。說一下目前的理解 首先，我搞清楚了層次架構的輪廓，spring框架，表示層呼叫控制層，控制層呼叫業務層，業務層呼叫資料訪問層。service層的作用，目前明確的印象是，為了框架，為了解耦，框架必須的一層！具體原理其實並沒有理解，以後要多多回顧思考。從字面的意思上來看...
jfinal在service層呼叫session
getsessionattr string key 和setsessionattr string key,object value 是我們經常用的對session操作 的工具,不過只可以在controller中使用 面對複雜的對session的操作是不可以都在controller中進行的 檢視get...
java中dao層和service層的區別是什麼？
首先解釋面上意思，service是業務層，dao是資料訪問層。呵呵，這個問題我曾經也有過，記得以前剛學程式設計的時候，都是在service裡直接呼叫dao，service裡面就new乙個dao類物件，呼叫，其他有意義的事沒做，也不明白有這個有什麼用，參加工作久了以後就會知道，業務才是工作中的重中之重...