Spring.NET在.NET新时代的尴尬

业界普遍接受的观点是：开发思想是重要的，相对而言用什么平台实现是次要的。从这个意义上看Spring.NET（或者说Spring）在构思框架的核心价值的时，着重面向的领域是“依赖注入”和AOP两个方面，但“分布式调用”以及“基于整个调用栈后动态对象生成”这两个概念对于Spring而言只是方面（Aspect）而已，但对于开发人员而言他俩确实是天天都要面对的问题。

Spring.NET继承Java版Spring的衣钵，在一些.NET项目中已经被采用，并且已经被部分企业用作其开发框架的标准组成部分，但对于更大规模或者更小规模的.NET项目而言他处处给人以高不成、低不就的尴尬感觉：

向上，他不像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项目（包括产品集成）的团队而言，这是一个新的选择。