Spring.NET v/s Castle Project


Both frameworks provide IoC and AOP capabilities, a Web Application Framework and further complementary capabilities.
Spring makes heavy use of XML configuration files, whereas Castle also provides an API allowing to programmatically configure the Container.

Inversion of Control Container
The Spring.Core library provides Dependency Injection functionality. Most of the libraries in the Spring.NET distribution depend upon and extend the functionality provided by this core library. The basic concept here is provided by the IObjectFactory interface that provides a factory pattern removing the need for programmatic singletons and numerous service locator stubs, allowing you to decouple the configuration and specification of dependencies from your actual program logic. An extension to the IObjectFactory, the IApplicationContext is also located here and adds more enterprise-centric features such as text localization using resource files, event-propagation, and resource-loading.
The WindsorContainer aggregates the MicroKernel providing a simpler interface and a set of important features that relies on MicroKernel extension points. The MicroKernel concern is to offer an extensible inversion of control container core. The Windsor concern is to offer a fa~cade to the kernel and deal with external configuration, proxies and automatic component/facilities install. These are not MicroKernel's concern, and we want to keep both code bases as small and simple as possible.

Aspect Oriented Programming
The Spring.Aop library provides Aspect Oriented Programming (AOP) support to your business objects. The Spring.Aop library complements the IoC container in the Spring.Core library to provide a foundation for building enterprise applications and applying services to business objects declaratively.
Aspect# is an AOP (Aspect Oriented Programming) framework for the CLI (.Net and Mono). It relies on DynamicProxy and offers a built-in language to declare and configure aspects, and is compliant with AopAlliance.

Web Framework
This is probably the feature where the frameworks differ most.
MonoRail (MR) uses the Front Controller pattern to serve web requests. A HttpHandler maps requests with a special extension (default: .rails) to controllers which in turn render the contents using a predefined view template.
Actually MR doesn't even rely on ASP.NET as view engine but integrates NVelocity as view engine. Although MR offers lots of features for Web Applications.
More detailed information can be here MonoRail at Castle []

Spring Web Framework
The Spring Web Framework (SW), relies on ASP.NET's Page Controller implementation to serve requests.
Here too, a HttpHandler is used to handle calls to *.aspx requests. The page is being "preprocessed" so the IoC Container can inject dependencies to the pages or even controls.
To be able to make use of further features, aspx pages or controls have to inherit from Springs extended base classes.
Master Pages
Very similar approach as ASP.NET 2.0 Master Pages.
Bidirectional Data binding
Automatic mapping from the model to the controls and vice versa. At the time of this writing, the mapping is being defined using attributes but will soon change to use methods for allowing more flexibility.
Automatic Localization
Push and Pull Localization. Whereas "Push" is probably more interesting, allowing to automatically fill predefined controls (e.g. Label) with localized strings.
Result Mapping
Page flow can be externalized using configuration files. When using Server.Transfer (internally) arbitrary objects can be transferred between pages using HttpContext.
Web Services Support
Spring allows to expose plain C# classes as webservices and brings full support for IoC with Web Services
More information can be found here Web Framework Reference []
NHibernate Integration
Spring.Net provides support to NHibernate. In addition, it provides HibernateTemplates and other classes to simplify the use of NHibernate. Transaction Management is able to manage ADO.NET and NHibernate data access objects under one single local transaction or global transaction if you wish.
Castle: NHibernate facility
Castle offers NHibernate integration, providing session and transaction management for NHibernate.

Additional Components/Services

Automatic Transaction Management, Perform automatic transaction management for your classes through interception
Batch Registration, Registers components based on configuration instructions Cache, Allows cache for your components
EnterpriseLibrary, Provides integration with MS' Enterprise Library Configuration package
EventWiring, Allow subscribers to connect to events exposed by publishers
FactorySupport, Allow your application to use external factories
Logging, Provides logging abilities for your components
RemotingFacility, Configures and provide access to remote components in a transparent fashion.
Startable, Implements the startable semantic for components
TypedFactory, Given a factory interface, automatic implement it delegating creation to the container