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的一点科普知识
