用ssh做了幾個專案，現在總結一下struts action中呼叫spring service的方法，大家有好的實現，請繼續補充：
1.老爸操持型
這種型別，即是在baseaction中提供乙個getbean(string beanname)的父類方法，業務action 在需要serivce時，呼叫父類的getbean()得到object型的service，再cast。
e.g.
**程式**：
2.自已動手型
自己動手 豐衣足食，再加了自從有了ioc，所謂動手也只是衣來後的伸手和飯來後的張口。自己動手型，即是利用spring的ioc，將ioc容器中的service注入到action中，當然action需要提供注入服務有setter.
如果採用這種方式，首先需要讓spring接管struts，然後在spring配置檔案中，配置action的注入屬性。
首先.在struts-config.xml將spring引狼入室。
**程式**：
然後，struts再向spring投懷送抱：
程式**：
聰明的你一下就看出「/useraction 」即是com.stamen.web.useraction在struts中的配置名。
3.朋友幫忙型 朋友多了好辦事，凡事都自己動手總有一天會活活累死，所有action為自己需要的service提供setter，並且在spring中注入，好累啊。小學生都在減負了，我們也來為action減減負吧--提供乙個專門
查詢serivice的servicelocator，負責獲取所有的service，該類為每個service提供專門的獲得方法，如：
程式**：
action要用哪個serivce時，直接通過servicelocator.get***service()就可以獲得了，省去了
「老爸操持型」指定service 名和cast的繁瑣，比在spring中ioc來ioc去也來得省心省力。
下面做乙個自己的分析小結：
1.「老爸操持型」 將servicename分散到**中，到時配置檔案中servicename一改，得牽一毛而動全身->維護性差；且要進行cast轉換，怎乙個繁字了得。
2.「自己動手型」也不好，不但在action中要新增get/set***service**，而且還要在struts和spring的配置檔案中做好群眾的大串連工作，難道我們的配置還不夠多嗎？吃回香豆的，你別又跳出來啊：）
3.「朋友幫忙型」，目前，我認為是比較好的方式，servicelocator象乙個服務周到，工作到位的房產「中介」，我們要租房子 何必滿街跑啊？*** 這個月我又交了3k房租，也不知道李大倫，李金寶之流規矩後，房價能不能降些，我想有個蝸牛的家 已經唱了好幾年了--跑題了，睡覺去了：）
spring cloud ribbon呼叫服務
目錄4 測試 ribbon主要負責負載均衡呼叫，是基於netflix ribbon實現的一套客戶端。主要功能是提供客戶端的軟體負載均衡演算法和服務呼叫。ribbon會自動的幫助你基於某種規則去連這些機器。簡單來說 ribbon 負載均衡 resttemplate nginx是伺服器負載均衡，集中式負...
Spring整合Struts詳解
spring雖然也提供了自已的mvc元件，但一來spring的mvc元件過於繁瑣，二來是struts的使用者眾多，因此，很多專案還是選擇使用spring整合struts框架，而且spring可以無縫的整合strtus框架，二者結合成乙個更實際的j2ee開發平台 使用spring的web應用時，不用手...
Struts與Spring的整合
struts核心是mvc，struts與spring的整合就是把struts的action交給spring去管理，從而達到簡化程式的目的 一 配置spring上下文和監聽 配置spring上下文和監聽有兩種方式 方式一 web.xml web主要配置檔案 而主要用於監聽web的上下文，可用下面 代替...