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



 写点什么

业界普遍接受的观点是：开发思想是重要的，相对而言用什么平台实现是次要的。从这个意义上看 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 项目（包括产品集成）的团队而言，这是一个新的选择。