用Spring.Services整合 thrift0.9.2生成的wcf中間代碼-複雜的架構帶來簡單的代碼和高可維護性

　　最近一直在看關於thrift的相關文章，涉及到的內容的基本都是表層的。一旦具體要用到實際的項目中的時候就會遇到各類問題了！

好比說：thrift 的服務器端載體的選擇、中間代碼的生成options（async asyncctp wcf 等等）、實現服務器端和客戶端的基礎框架的選擇、和承載各層之間的組合的ioc架構。

其實這些東西，內容仍是蠻多的。可能你們在看了這篇文章對不少必需要對 thrift 的基礎作些普及才能看懂，還有就是windowsservices、wcf、spring.net！

　　這裏，我是用的C# 作服務器和客戶，固然，服務器端公佈出的接口客戶端就不在意你是什麼語言的了。只須要thrift的編譯器生成對應中間代碼而後相應編寫代碼就ok了。

下面是我選擇的代碼結構：

服務器端的載體我選擇了windows services ,編譯器確定是用官方最新的thrift0.9.2(在代碼生成的時候options我選擇了wcf), 至於Thrift 的基礎框架，我選擇的是.net的 Thrift 和Thrift.Server和Thrift.Client (客戶端能夠支持多個服務器端的配置這正式我要找的東西呀)，Ioc框架，其實現成的注入框架比較多，什麼autoface，unity，spring.net等等；其實最終咱們選擇這些依賴注入的目的必定要清楚：（我的觀點） 讓咱們的架構更鬆散、代碼更美觀、代碼量更少、高可複用性、更容易維護。其實不管的的選擇是什麼，目的清楚了你的選擇就一目瞭然了。這裏個人選擇確定就是spring.net了，由於它有對Wcf,webservice,windowsservice,remoting等 的專門支持Spring.Services。另外的緣由就太多了，讓我省去了很多代碼，讓本來臃腫Wcf的代碼變得結構清晰，另外它也統一了全部項目的依賴注入。

其中thrift 的代碼生成命令是：thrift -gen csharp:wcf *.thrift

如今還看不到spring 的內容，應該它的做用是將鬆散的代碼最後組合成一個成品。因此會涉及不少的spring配置。並且最終只會在ServerHost 項目的app.config 中能夠看到。

固然裏面的代碼至關的少，由於spring.services裏面作了整合，且一次封裝，ServerHost 裏面的代碼就不用改了，你 惟一要作的就是如何將各個模塊用配置整合在一塊兒了。

　　從如今的結構視乎看上去很簡單，其實否則，要真正將它們整合在一塊兒要作不少配置和調試工做

下面看看生成的dll文件就知道了：

這還只是dll文件，相信用過spring的都知道。spring在代碼和結構上帶來了福音，可是配置文件的編寫和整個框架的調試和融通倒是一件頭痛的事情。

不過，隨着.net 的開源，對項目架構和可擴展性，分佈式，可維護性要求也在慢慢體現出來。

因此作.net 的同窗們，不要只看到.net的敏捷開發，要看到它有更宏偉的目標(分佈式，雲層存儲，搜索引擎等等)；而要達成這樣的目標，咱們必須重視各類第三方開發的中間件，無論它的原型是java開發的，php開發的，仍是其餘語言開發的。最重要的是它能帶來咱們想要的，它能讓咱們程序不在難以維護，讓系統像一個嬰兒同樣能夠逐步成長，而不是其餘語言所取代，或是各類重複開發。