Spring.NET在.NET新時代的尷尬
業界普遍接受的觀點是：開發思想是重要的，相對而言用什么平臺實現是次要的。從這個意義上看Spring.NET（或者說Spring）在構思框架的核心價值的時，著重面向的領域是“依賴注入”和AOP兩個方面，但“分布式調用”以及“基于整個調用棧后動態對象生成”這兩個概念對于Spring而言只是方面（Aspect）而已，但對于開發人員而言他倆確實是天天都要面對的問題。
向上，他不像WCF可以獲得微軟服務器產品家族的支持，更遠遠遜色于類似COM+的待遇，但規模比較大的.NET項目又往往需要集成BizTalk、ISA、SMS、Exchange、SQL Server等一系列產品。如果使用Spring.NET（或者加上NHibernate）也就意味著雖然運行著較高版本的服務器產品只能屈就于有限功能集的使用。另外，在Spring.NET的設計中似乎對于運維能力以及性能指標的采集總是基于日志系統的，但如果什么內容都寫到日志，這本身就是很大的性能損失；尤其在以WMI為標準的.NET企業環境中，Spring.NET在運維能力設計上存在不小的缺陷；
向下，Spring.NET 1.1在試圖彌合其與ASP.NET的差異，不過似乎又慢了一步，因為ASP.NET自己的框架也在隨著.NET 3.5的發布發生變化。與此同時，ADO.NET的異步處理能力、LINQ的動態對象映射能力處處都直指Spring.NET的最佳排檔—— NHibernate，如果準備啟用新.NET 3.5開發的團隊那么就需要做一個選擇，繼續跟著3rd開源的衣缽還是跟著.NET自己的技術走。
在EntLib 4發布前夕，P&P團隊已經在codeplex上公布了相關Unity的計劃及其CTP版本，其他的Application Block也陸續遷移到Unity之上。雖然EntLib只是整個.NET開源的滄海一粟，但其風向標意義明顯，其企業級特性支持可以直接用于.NET Native的WCF，而對對象的管理則全部交給Unity完成，這個組合不僅可以向上貫通微軟一系列服務器產品，也可以與Office System、WMI集成在一起。并且隨著微軟相關技術平臺的升級，WCF和Unity也會逐步更新，而且會與微軟的服務器產品、Office System產品、開發工具以及監控產品結合在一起。對于.NET團隊，尤其是實施較大規模.NET項目（包括產品集成）的團隊而言，這是一個新的選擇。
【編輯推薦】
