<bean id="viewResolver" class="org.springframework.web.servlet.view.velocity.VelocityViewResolver">
??<property name="cache" value="false" />
??<property name="prefix" value="" />
??<property name="suffix" value=".vm" />
??<property name="contentType" value="text/html;charset=UTF-8" />
?</bean>

這樣就可以解決問題, 沒想到, 還是亂碼,? 看了看Velocity相關的文檔, 于是改了改,

<bean id="velocifyConfig" class="org.springframework.web.servlet.view.velocity.VelocityConfigurer">
??? ?<property name="resourceLoaderPath" value="/WEB-INF/velocity/" />
??? ?<property name="velocityProperties">
??? ??<props>
??? ???<prop key="input.encoding">UTF-8</prop>
??? ???<prop key="output.encoding">UTF-8</prop>
??? ???<prop key="contentType">text/html;charset=UTF-8</prop>
??? ??</props>
??? ?</property>
??? </bean>

?<bean id="viewResolver" class="org.springframework.web.servlet.view.velocity.VelocityViewResolver">
??<property name="cache" value="false" />
??<property name="prefix" value="" />
??<property name="suffix" value=".vm" />
??<property name="contentType" value="text/html;charset=UTF-8" />
?</bean>

在velocityConfig里添加了:

<property name="velocityProperties">
??? ??<props>
??? ???<prop key="input.encoding">UTF-8</prop>
??? ???<prop key="output.encoding">UTF-8</prop>
??? ???<prop key="contentType">text/html;charset=UTF-8</prop>
??? ??</props>
??? ?</property>
以為, 這下, 肯定可以了吧, 應該改的地方都改了, 高高興興的重啟了一下tomcat, 一訪問, faint仍然亂碼, 這下子崩潰了, 于是開始找, 找啊找, 找啊找, 怎么也是找不到, 看了spring的源碼看了velocity的源碼, 怎么也想不通(一晚上都沒睡好啊), 剛剛起來的時候, 沒辦法, UTF-8改成了GBK, ok, 不亂了, 不過, 變成了GBK, 總是感覺不爽, 不管, 反正是不亂了.

2. 開發(fā)的流程問題

?????? IBM developerWorks 上有一篇文章對此做出了一些闡述

1. 自上而下的開發(fā)

2. 自下而上的開發(fā)

3. 往返式的開發(fā)

這三種都有各自的好處 , 自下而上的開發(fā) , 會先編寫接口 , 然后根據(jù)接口來生成相應的 WSDL 文件 , 這種方式被很多工具很好的支持 , 但是 , 如果接口變了 , 那 WSDL 文件也要跟著變 , 那么調(diào)用可能就會發(fā)生錯誤 . 自上而下的開發(fā)會先手工編寫 WSDL, XSD 等文件 , 這對開發(fā)人員的要求無形中有了提交 , 開發(fā)人員必須很清楚的理解 WSDL, 和 XSD, 當然 , 這種要求并不過分 .( 這也是被作者推薦的方式 ) 往返式開發(fā)會先根據(jù)接口生成 WSDL 文件 , 然后在根據(jù) WSDL 文件生成代碼 , 這種方式 , 造成了一些流程上的混亂 , 也增加了一些無謂的流程 , 不建議使用 .

3. 每個服務的粒度問題 , 我認為 , 應該由多個小的服務 , 來組成整個業(yè)務 .

4.RPC 形式 , 還是文檔形式 . RPC 的最大好處是簡單 , 容易理解 , 也是被支持的最好的 , 不過 , 文檔形式更為靈活 , 當然 , 具體的選擇還要看業(yè)務的須求 .

5. 數(shù)據(jù)的驗證 , 這應該是個很重要的問題 , 然而現(xiàn)在的工具似乎并不能很好的解決這個問題 .

?