1樓：千葉no墮天聖黑貓
感覺這個結構spring沒用多少，我比較喜歡springMVC+hibernate，這一套更能感受到spring帶來的好處。。
2樓：
這種東西是需要權衡的，常見的方式是Action->Service->DAO，你最早引入乙個單獨的AL層是有點多餘了。就算業務邏輯比較複雜一般也是通過Service調更細粒度的Service就可以解決絕大部分問題。如果你想再精簡的話，我的建議Service保留，可以把DAO去掉，直接在Service裡面呼叫，因為一般來說改Service比改DAO更頻繁。
抽象這事就這樣，你想的多了一開始的工作就多，後面的修改維護就簡單，想的少點進度快點後面的修改維護就麻煩點。
3樓：biggates
嗯，我最近也在考慮這個問題。
市面上常見的 SSH 基本上就是 Struts2 + Hibernate ，之前有幸接管了乙個 SSH 專案，Spring 在其中起到的作用微乎其微。
隨著專案的發展，逐漸又引入了 Spring-Security 和 Spring-Data ，因此逐漸想將專案轉化為以 Spring 為主的專案了。
對於你說的層次太多的問題，我在專案中是這樣處理的：
Service 層處理了事務級的業務邏輯
DAO 層使用乙個基類提供了對 Hibernate Session 的封裝，並另外提供了業務DAO 類封裝了最常用的操作，這樣就不需要每個實體類乙個 DAO 物件。
4樓：kaiba
建議service層保留，作為事務邊界和實現業務，去掉dao；當然，如果都是一些簡單的crud的話，service層也可以去掉，action直接呼叫hibernate
做設計時總是被結構問題所困擾，導致最後的方案很保守，所以到底是該服從於設計，還是服從於結構？
俞百九 作為學生能提出這樣的問題，我覺得你很有潛力成為乙個好的建築師。最近做了乙個專案，上海的事務所做的方案，在方案階段就是考慮了乙個夠酷炫的表皮，完全沒有結構的介入。到了施工圖階段就會發現各種不合理各種不能實現。我作為結構工程師覺得很痛苦，痛苦在於專案一開始就是個怪胎，我還得把怪胎撫養長大。關於這...
20屆設計系，我的設計水平很差嗎，找不到合適的工作
烏拉 嘶，雖說我是個學產品設計的，但是以我的角度來看你的作品的話，額，感覺沒有很成熟，比較類似老師布置的作業的感覺，而且相比我看過的視傳他們做的東西，你做的差點意思。我也幫外面的排過版，別人的宣傳冊呀摺頁呀說實話沒這麼花，商業審美是商業審美，動漫是動漫，把握一下分寸吧。本人學建模和渲染的，這方面不專...
效果圖設計師工作的時候最困擾的問題是什麼？
困擾？困擾就是，乙個專案要做五套方案，每套方案你都要參與，也就是你要對接五個設計師，還沒有專案提成。困擾就是，你明明知道這個設計師水平不夠，審美奇差，還要聽他的，做出來效果不理想，要怪你圖做的不好。你還不能反駁，反駁就是你行你怎麼不做設計師？困擾就是，你不想待在這乙個崗位太久，可就是沒有晉公升空間，...