Spring.NET可以应用于许多场景。核心特性如依赖注入(DI)容器、AOP以及数据访问框架,都可以非常好地应用在任意的.NET应用程序中。它使得你能够创建更简单、更干净的应用程序。为了尽量消除它所带来的副作用,开发人员还可以免费获得功能强大的配置机制。
如果你正在编写一个ASP.NET Web应用程序,你可以考虑将Spring.NET Web框架(Spring.Web)加入其中。因为它是ASP.NET的一个扩展,所以不会改变ASP.NET开发人员的开发方式,同时又为他们提供了一些新的强大功能。例如,它支持web pages与user controls的依赖注入,这本身就具有充分的理由来选择使用它。然而,最重要的是我们增加了双向数据绑定、进程与状态管理,以及经过改善的本地化支持和增强的数据验证框架。最后,Spring.Web还为ASP.NET 1.1开发人员提供了某些只有在ASP.NET 2.0下才能使用的很酷的新特性,例如Master Pages,它不仅改善了ASP.NET 1.1的开发体验,而且还使得从1.1到2.0的迁移变得更加地容易。
Spring.NET Services Framework(Spring.Services)支持开发者接收一个普通的接口/实现对象,然后以远程SAO或者CAO对象、Web服务甚至当作一个服务组件输出。然后,通过为输出的远程服务应用方面(aspects),可以实现安全检查、加密、压缩等超级酷炫的事儿。
Spring.Services的另一个组件是客户端代理生成器,它会提供一个普通的客户端接口以及一个远程终结点(remote endpoint)的URL,从而为上面提及的任何一种服务类型的远程服务创建动态代理。例如,你可以使用WebClientFactory类在运行时动态创建一个Web服务代理。通过这种方式创建一个客户端Web服务代理,比之于在VS.NET中通过使用Web引用创建,优势更为明显。首先,你可以提供一个代理需要实现的接口,并通过该接口从客户端应用程序中访问代理。其次,由于接口为你的Web服务方法定义了所有的参数与返回类型,因而在你真正需要使用现有的数据类型时,不必处理VS.NET生成的伪类型。而这可能是在VS.NET中使用Web引用所带来的最大困扰之一。
最重要的是,你甚至可以创建一个代理,该代理可以通过我们对IIOP.NET的集成,调用Spring或者任意EJB容器中的EJB所管理的远程Java RMI对象。目前,这个版本还有一些与序列化相关的功能没有实现,通过这些功能可以实现真正的客户端位置的透明化,我们希望在下一个版本中增加。
Mark:Spring.NET的数据访问框架(Spring.Data)为‘普通的’ADO.NET提供了许多颇有价值的修饰。其中一个关键组件就是事务管理的抽象,它允许开发者轻松地在不同的事务策略之间切换,例如普通的旧的ADO.NET,EnterpriseServices分布式事务以及新的System.Transaction命名空间。所有的事务策略都可以通过嵌入的特性或者非侵入性的XML配置来完成。我们对于ADO.NET框架的扩展使得 ADO.NET的操作更简单,并且考虑了连接/事务的资源处理——否则在通常情况下,就必须增加开发人员的工作量,即使使用System.Transactions命名空间。
Spring.NET还有几个组件可以脱离于框架单独使用,例如expression language(表达式语言),它可以很好地消除在应用程序中编写与反射相关代码的需要。
当你决定是否在特定应用程序中使用Spring.NET时,切记不要将Spring.NET当作一个“整体不可分割”的框架。当你一起使用它们的时候,它们只是一个框架的集合,能够更大程度地完成协作,但也完全可以彼此独立地单独使用。
这是我在网上学习的一点关于spring.net的一点科普知识