Q&A: Spring.NET Founder Mark Pollack

The latest version of Spring.NET, made generally available in December, is a major upgrade to the original port of the popular Spring Framework, a layered Java/J2EE application-programming model.

Spring.NET 1.1 adds ASP.NET and ADO.NET frameworks; integration with ASP.NET AJAX, NHibernate and NUnit; and more pre-configuration. Like its Java counterpart, Spring.NET is sponsored by SpringSource (formerly Interface21) in San Mateo, Calif., and licensed under Apache 2.0. It brings many of Spring's key concepts to .NET, such as declarative transaction management, but it's more than just a "port" of the Java framework.

"The intention is that the product should stand on its own with value for .NET developers who don't care about Java at all," says Spring.NET founder and project lead Mark Pollack, who is also a Microsoft MVP.

Pollack worked on the Spring Framework for Java project from 1999 to 2003 with creator Rod Johnson. A financial services architect and developer, Pollack co-founded CodeStreet LLC in 2004. He was using .NET and says he wanted to bring some of the same Java programming experiences in Spring to the Microsoft framework. We caught up with him to find out what's new in Spring.NET 1.1 and how the framework can make your enterprise development easier.

What can I do with Spring that I can't do with .NET and related tooling?
What you can do with Spring that you can't out of the box with Microsoft is that it's one level higher with a lot of common idioms, common design practices and design patterns, and you just bundle that up in an easy-to-use way. It has themes that run throughout the framework like dependency injection and aspect-oriented programming, and those two foundational themes are really the biggest bang for the buck.

What is dependency injection?
It's an approach to configuration management that results in having an application that's much easier to test, so it aligns itself very well with doing test-driven development or agile methodologies. Usually when you're doing testing you like to put in safe versions of existing systems. You want to test against a fake version of the mainframe adaptor instead of really talking to the mainframe, and so on. What Spring is bringing to the table is this very simple but powerful flexibility model, so its interfaces and the configuration of which implementation you use are very easy to select.

Likewise with the Aspect-oriented programming (AOP) -- is that primarily used in high-transaction environments?
It sort of dovetails into dependency injection with configuration. If you have some object that's managed by Spring, and configured by Spring, AOP lets you adds the official behavior to it. If you're familiar with things in the .NET Framework in terms of Enterprise Services or COM+, where you can do things like declarative transaction management, you could apply an attribute to a method and, say, make this method transactionable. Spring looks at it -- or in the case of .NET Enterprise Services, the COM container looks at it -- and says, 'we have this method, it has this annotation on it, before I call this method, I'm actually going to start a transaction with the database and when the method exits, I'll admit that there was an exception and I'll roll back.' And so AOP can be applied to interception that way to provide a lot of these enterprise services like transaction, pooling, caching-quite a lot that falls under that umbrella. Usually it's exposed to programmers in a very easy-to-use way: You don't write transactional code, you just declare your intent to the transaction. So that's a big win -- a lot of people really like that feature.

With eight different modules, is it accurate to characterize Spring.NET as multiple frameworks?
The foundational technologies are really dependency injection and AOP, and then, for example, these get applied to ASP.NET by being able to, say, configure your ASP.NET page one way through the ASP.NET framework. And the principle there is there's a lot of boiler plate code that you can write and jump data in and out of, text fields and stuff like that, and [you can] validate it and encapsulate it in a friendly manner.

Similarly, with declarative transaction management, this has a data access abstraction in it. So that if you're using different data access technologies -- maybe you're using ORM, ADO.NET for Entities, or maybe you're just using regular old ADO.NET -- how do you put all three of those technologies together in the same transaction? We provide abstraction that makes that very easy to do. In particular ADO.NET is a very low-level API -- there's a lot that can be done to make people more productive with it.

How similar is Spring.NET 1.1 to the Spring Framework for Java?
The important thing was transferring the ideas over and not necessarily word for word or every feature, and dropping features that were not relevant for the .NET platform. It was really carefully scrutinized. It doesn't look or smell like Java at all. It should be a natural way to be more productive and use best practices in a pre-packaged way.

The Java framework's Model View Controller (MVC) for Web apps, for example, isn't part of Spring.NET. Can you explain that?
Actually, that's an interesting sub-story. Microsoft is releasing an MVC framework as part of ASP.NET 3.5, and so they provide that foundation there. There are also other things that they provide from the Java side that are quite similar, like validation, databinding and configuration. When I spoke to Scott Guthrie about this, he said they're creating the MVC framework in particular to make Web apps more testable and to be integrated with inversion control containers like Spring. This is the biggest sign from Microsoft that things like testability and things like configuration and dependency injection are important values. Unlike the [Microsoft] Patterns and Practices Group, which is off to the side -- and they're doing good things -- it's still not in the core.

About the Author

Kathleen Richards is the editor of and executive editor of Visual Studio Magazine.