Spring.NET 1.3: VS.NET Solution Templates, MSTest Support and Spring Integration.NET

Posted by Ryan Slobojan on Feb 11, 2010

Sections

Architecture & Design,

Development,

Enterprise Architecture

Topics

Messaging ,

.NET ,

Enterprise Architecture

Tags

Visual Studio ,

MSMQ ,

Spring.NET ,

Aspect Oriented Programming ,

Tibco ,

Spring ,

Spring JavaConfig ,

MSTest ,

NUnit ,

ActiveMQ ,

ASP.NET ,

ASP.NET MVC ,

ADO.NET ,

AOP ,

Spring Integration

A new version of the Spring.NET framework, version 1.3, was recently released. InfoQ spoke with Mark Pollack, founder and lead of the Spring.NET project, to learn more about this release and what new capabilities it brings, and also to learn more about the new Spring Integration.NET project.

Pollack indicated that there were four main new features in this version:

1. Integration with Microsoft Test Framework - As with the previously-existing NUnit support, Spring.NET can now do dependency injection and transation management for test classes within the Microsoft Test Framework
2. TIBCO EMS Support - Several classes have been added which provide increased productivity and a Plain Old C# Object (POCO) based programming model for TIBCO EMS messaging - this is identical to Spring Java's JMS support, and complements the previously-existing ActiveMQ and MSMQ support
3. Enhanced NVelocity Support - Configuration of the NVelocity engine has been greatly simplified
4. Visual Studio.NET Solution Templates - Support for Spring.NET within Class libraries, ADO.NET application libraries, NHibernate application libraries and Spring-based web applications is now provided for VS.NET 2008 along with ReSharper type completion and template support

Full documentation and a comprehensive changelog are also available. While the Spring 1.3 release is intended to be a drop-in replacement, there are some breaking changes to be aware of for those that interact closely with the internal APIs.

Explaining the VS.NET Solution Templates in more detail, Pollack indicated that each template consisted of several projects, including the "main" business logic project and the testing project. For each of the solutions above, the appropriate boilerplate configuration to get Spring.NET going is provided. The ReSharper templates which are included also ease many common coding and configuration tasks such as bean type completion and adding properties to bean definitions.

Pollack also described how Spring.NET compares to other .NET frameworks:

• More than a Dependency Injection (DI) container - Although Spring.NET is normally compared to other DI containers like Castle, it is really an application framework due to the wide range of APIs that can be used across the application, including data access, web development and integration testing
• ASP.NET framework - The Spring.NET ASP.NET framework is NOT ASP.NET MVC-based, and it provides productivity benefits as a result - searching for an ASP.NET framework is actually the most common way that new users discover DI and Spring.NET
• Message-oriented middleware integration - Integration with Apache ActiveMQ, TIBCO EMS and MSMQ ease the development burden of working with these frameworks by abstracting away low-level thread safety issues and using a POCO-based programming model
• Aspect-Oriented Programming (AOP) - Spring.NET provides an extensive AOP framework which provides concepts such as pointcuts and advice, and also provides ready-to-use advice implementations such as logging, exception translation, parameter validation, caching and automatic retrying of operations
• ADO.NET library - The ADO.NET helper library abstracts away and simplifies working with ADO.NET data sources by eliminating a lot of boilerplate code and providing a Template-based programming model
• Expression language - Spring.NET provides an Expression language which can be used at runtime to query and manipulate an object graph
• Integration testing - Support for integration testing is included, to ease testing of functionality such as data access
• Modularity - Features are separated into different DLLs so that developers can pick and choose which ones they want, and aren't forced to use the entire framework
• Enterprise support - Spring.NET is supported by SpringSource, which was recently acquired by VMWare. Having the support of a large company can sometimes be a factor for a company when making a strategic decision to adopt Spring.NET
• Planned code-based container configuration - Currently Spring.NET only supports XML-based configuration, while Castle supports both XML and a "type-mapping" API style. In the next release of Spring.NET, a code-based configuration style similar to Spring JavaConfig (which was incorporated into Spring 3.0) will be introduced

There is also a large amount of Spring.NET documentation as well as a dozen well-documented sample applications.

When asked about future plans for Spring.NET, Pollack said:

Future plans are to develop Spring.NET 2.0 and also to branch out into other areas based on feedback from our users. There has been great progress on Spring Threading for .NET by Kenneth Xu. These are general threading utilities in the spirit of what is available in Java's 'util.concurrent' package, for example, custom thread pools, PriorityQueues, IFuture<T>, and for something outside the 'util.concurrent' mold, an implementation of .NET 4.0's Parallel class you can use in .NET 2.0. Contributors are also working on .NET versions of Spring Security, and there has been good progress on Spring Integration for .NET by Andreas Dohring.

One of the most important features for us to provide in Spring.NET 2.0 is the option for code based configuration of the DI container. A more general theme is to sync up the core DI container code with the recently released version of Spring Java 3.0. This also means providing an attribute based way to configure DI as well as more use of generics in the Spring APIs, the majority of which are internal to Spring itself. Other areas are ASP.NET MVC integration, at least for DI, and increased ability to monitor and manage operationally Spring.NET based applications. Tooling inside Visual Studio is a common request, for an example of the features you can look to our eclipse plug-in for Spring Java, but we have not yet committed to delivery that functionality. We are also looking at a variety of ways in which we can make it easier to provide interoperability between Spring.NET and Spring Java applications, across a range of distributed technologies such as messaging, web services and REST.

Milestones and release candidates are expected during Q1/Q2 2010, with a final release to follow shortly after that. The similarities between the structure of the Spring.NET and Spring Java codebases make it straightforward (albeit time-consuming) to move over new features and refactorings. An initial release and scope of Spring Integration.NET was also discussed:

The areas we will focus on are the same core areas that the Spring Java project provides, namely providing a programming model to support the well-known Enterprise Integration Patterns, for example Channel, Router, Filter, Splitter, Aggregator, and Transformer. It provides what amounts to an embedded message bus that can be used within a Spring based application and integrates to external systems via adapters. As would be expected with Spring, it provides a POCO based programming model that is essential for producing maintainable and testable code. The adapters that will be provided in an initial release are similar to those in the current Spring Integration 1.0.3 release, such as file, messaging, email, and web services. However, we will also provide more specific .NET adapters such as the Windows Event Log and WCF P2P channels. As we get past a first release, the use of more specific .NET framework features, such as lambda expressions, extension methods, and features available in .NET 4.0 will be added.

To learn more, please see InfoQ's recent interview with Mark Pollack in which Spring.NET 1.3 and 2.0 were discussed in detail.

• Older >