Aleksandar Seovic is a Founder and Managing Director at Solutions for Human Capital, Inc, a software development and consulting company specializing in enterprise document and content management. He has lead development effort on a number of engagements, using both Java and .NET platforms, for Fortune 500 corporations, mostly in pharmaceutical and financial services industry.
Aleks is a co-lead for Spring.NET, an open source framework for .NET application development, and a lead developer for Web, AOP and Services modules of the framework.
Mark Pollack is a Partner at CodeStreet, LLC, a software and consulting firm in the financial services industry. He has worked extensively as an architect and developer on various front office trading systems that involved a mixture of .NET and Java technologies and emphasized message-based middleware. He obtained a Ph.D. in physics before starting a career in software development.
Mark has been involved with the development of the Spring Framework since 2003 and in 2004 founded its .NET counterpart Spring.NET.
InfoQ: So what IS Spring.NET and why does the .NET community need it?
Aleks: Spring.NET is an open source application framework that greatly simplifies .NET application development, and even makes certain tasks possible that would be very difficult to achieve without it. It is also a "younger brother" of the very popular Java Spring Framework. However, to say that Spring.NET is just a port of Spring would be an injustice. The reality is that it is more of a "spiritual port" of Spring than it is a port of the Spring code base.
When I started using Spring back in 2003, I very quickly realized that it allows me to write Java applications much faster, and it results in a smaller, cleaner and more flexible code base that is significantly easier to test, maintain and extend. Once I got hooked on Dependency Injection and other nice things that Spring has to offer, I found myself looking for a framework that would provide similar features on a .NET platform, but couldn't find any. Around the same time, in early 2004, Mark had a similar "itch to scratch" and he started the Spring.NET project. As soon as I heard about it, I joined the project and we started porting the core Dependency Injection container and AOP framework.
Mark: One thing Aleks and I agreed very early on was that Spring.NET should not be a blind port of Spring's code base. The driving force behind Spring was to create a framework that would reduce complexity in J2EE development and provide a simple, POJO-based programming model which would allow Spring applications to run in any J2EE container. Obviously, the J2EE and .NET platforms are not the same and do not suffer from the same problems, so trying to port Spring feature-by-feature to .NET would be pointless. However, the .NET platform has its shortcomings as well, so we decided the focus of Spring.NET should be to address those shortcomings in such a way that will make the average .NET developer more productive and allow him to write better, smaller and cleaner code. Code that focuses on the business logic instead of infrastructure-related issues.
Aleks: Some of the core Spring features, such as the Dependency Injection container and the AOP framework, are so generally useful and completely platform independent that we simply ported the code pretty much as-is. On the other hand, we realized that ASP.NET out-of-the-box is much more powerful than servlets and JSP in Java, so we decided that porting Spring MVC didn't really make sense. Instead, in the Spring.NET Web Framework we opted for an approach of embracing and of extending ASP.NET.
There were also components such as Spring Remoting, which allow you to take any POJO and export it as a remote object using a number of Java-specific technologies. In cases like that one, we liked the ideas and wanted to apply them to .NET, but because the remoting technologies we were dealing with in .NET were different, we had to implement everything from scratch.
Overall, the goal was not to preserve Spring features and implementation, but to preserve the benefits that made Spring as popular as it is and to offer Spring-style solutions to some of the problems specific to .NET platform.
InfoQ: You mentioned Dependency Injection several times. Can you explain what exactly it is and why should .NET developers care about it?
Aleks: Sure. Dependency Injection is actually a very simple concept. When you look at a typical application, you will see there are many dependencies between objects. Presentation layer objects will depend on service layer objects, which will themselves depend on other service objects and data access objects, etc. Within a running application there are many interdependent objects that are "wired" together.
The naïve way to obtain a dependency is to create it directly by calling its constructor. This works, but it has a number of problems: classes become difficult to test in isolation, it is impossible to change which dependent class to use without modifying the code that created it, etc.
Most of these problems can be solved by using some kind of a configurable Factory, Service Locator or Registry to create or look up an object. This approach, which we could call Dependency Lookup, can work very well if implemented correctly, but it introduces a dependency on the Factory, Service Locator or Registry itself, which is often not desirable. It also requires more work than Dependency Injection.
On the other hand, Dependency Injection implies that an object's dependencies will be "injected" by external means. There is no need for an object to look up anything - it simply declares private fields for its dependencies and allows for them to be provided externally, either via a constructor argument or via a property setter. This makes objects very clean and reusable, and if dependencies are declared in terms of interfaces instead of specific classes, it also makes them very easy to unit test.
If you think about it, there is nothing new about Dependency Injection per se. Whenever you set a Connection property of an IDbCommand instance, or a Menu property of a Form instance, or when you pass a Socket instance as an argument to a NetworkStream constructor, you are manually injecting dependencies. I could find similar examples in older technologies as well, such as VB6 or COM.
However, what made Dependency Injection so popular in the recent years is the rise of lightweight containers such as Spring, Pico and HiveMind in Java, and Spring.NET, Castle, and more recently Microsoft's ObjectBuilder in .NET. These containers allow you to configure object-wiring rules within your application and based on those rules they will create and wire your application's objects together, providing you with automatic dependency injection. The ways in which different containers allow you to specify object-wiring rules are different, but the ultimate goal and the end result are usually the same.
There are other benefits which containers have to offer as well. Because they know about all the objects they are managing, it is very easy to manage objects in a running application. I'm not sure about other containers, but Spring and Spring.NET also offer hooks that allow you to execute custom logic in different states of an object's lifecycle, which is very useful at times.
InfoQ: So what are the advantages Spring.NET has over some of the other frameworks you mentioned?
Aleks: Well, let's compare Spring.NET to ObjectBuilder first, because that's relatively easy. ObjectBuilder is just a lightweight DI container, while Spring.NET has many other features that make it a compelling choice. The DI container is just one of the components, albeit a very important one within Spring.NET.
On the pure DI front, Spring.NET has far more features than ObjectBuilder, and it is not invasive at all. That means your classes can remain completely independent from Spring.NET, even though it is used to configure them. On the other hand, ObjectBuilder is very invasive - it uses attributes to specify which factory class should be used to obtain a particular object, you have to code these factory classes by following pre-defined rules, etc. Overall, it is obvious that ObjectBuilder was written to enable configuration within the Composite UI Application Block, not as a generic and reusable DI container, even though Microsoft's Patterns & Practices group tries to label it as such.
Another big advantage Spring.NET has, is that ObjectBuilder can only be used within .NET 2.0 applications, while Spring.NET can be used within both 1.x and 2.0 applications.
Comparing Spring.NET and Castle is a bit more difficult. Both are fairly broad frameworks that provide a DI container, as well as many other components, such as a web framework, a data access framework, etc. I don't know enough about Castle's DI container to be able to compare it with Spring.NET on a feature-by-feature basis, but I do know they took a somewhat different approach for their web and data access frameworks than we did.
I think it will ultimately depend on the developer's background and specific needs whether he chooses Spring.NET or Castle. From what I've seen so far, developers who have used Ruby On Rails lean towards Castle, while the ones coming from a Java background, especially if they have used Spring before, lean very much towards Spring.NET. I'm not sure which way the average .NET developer will go, but I encourage them to try both and choose the one that works better for them - either way they'll be far better off than without one of the two.
Finally, there is one big advantage I believe the Spring.NET DI container has over both ObjectBuilder and Castle - it is significantly more tested and proven in real-world applications. Because we inherited the DI container implementation from Spring, we have the benefit of all the testing and production use behind it.
InfoQ: Where should I use Spring.NET?
Aleks: There are many areas where Spring.NET is applicable. Core features, such as the Dependency Injection (DI) container, AOP and the data access framework can be used in pretty much any .NET application. They allow you to create simpler, cleaner applications. As a nice side-effect, you acquire powerful configuration mechanism for free.
If you are writing an ASP.NET web application, you should consider adding the Spring.NET Web Framework (Spring.Web) to the mix. Because it is an extension of ASP.NET, it allows ASP.NET developers to do things the way they are used to while giving them some powerful new capabilities. For example, it enables Dependency Injection for web pages and user controls, which by itself is good enough reason to use it. However, on top of that we added bi-directional data binding, process and state management, improved localization support and an enhanced data validation framework. Finally, Spring.Web gives to ASP.NET 1.1 developers equivalents of some of the cool new features that are available in ASP.NET 2.0, such as Master Pages, which not only makes ASP.NET 1.1 development experience better, but it also makes migration from 1.1 to 2.0 a bit simpler.
The Spring.NET Services Framework (Spring.Services) allows you to take a plain interface/implementation combo and export it as a remote SAO or CAO object, web service or even as a Serviced Component. You can then do very cool things to the exported remote service by applying aspects to it that will do things such as security checks, encryption, compression, etc.
Another component of Spring.Services are the client-side proxy generators, which, given a vanilla client-side interface and a remote endpoint URL, will create dynamic proxies to a remote service of any of the above mentioned service types. For example, you can use WebClientFactory class to dynamically create a web service proxy at runtime. There are several benefits when you create a client-side web service proxy this way over creating it using web references in VS.NET. First of all, you can provide an interface that the proxy needs to implement and access the proxy from the client application through that interface. Second, because the interface defines all the parameter and the return types for your web service methods, you don't have to deal with bogus types being generated by VS.NET where you really wanted to use your existing data types. That's probably one of the most annoying things about web references in VS.NET.
On top of that, you can even do things such as create a proxy that calls a remote Java RMI object managed by Spring or an EJB within any EJB container, through our integration with IIOP.NET. There are only a few serialization-related pieces missing to enable true location transparency within the client, which we are hoping to add in the next release.
Mark: Spring.NET's Data Access Framework (Spring.Data) provides lots of added value above ‘plain' ADO.NET. One of the key components is a transaction management abstraction that allows you to easily switch between different transaction strategies, i.e plain old local ADO.NET, EnterpriseServices distributed transactions and the new System.Transaction namespace. All the strategies can be used to perform declarative transaction demarcation either via embedded attributes or non-invasive XML configuration. Our extensions to the ADO.NET framework make most ADO.NET operations a one-liner and take care of the connection/transaction resource handling - which would otherwise still require some extra work on the part of the developer in common scenarios, even with the new System.Transactions namespace.
There are also a couple of components within Spring.NET that can be used independently from the framework itself, such as an expression language, which can pretty much eliminate the need to write reflection-related code within your app.
Probably the most important thing to keep in mind when deciding whether to use Spring.NET or not in a particular application is that Spring.NET is not an "all-or-nothing" type of framework. It is really more of a collection of frameworks that have a great degree of synergy when used together, but can also be used completely independently from one another.
InfoQ: How are people finding Spring's concepts in the .NET community? How is adoption going? How many downloads have you had, other metrics?
Aleks: Feedback from the users has been extremely positive. People who have used Spring in Java are excited to see that they can use the same programming model and get the same benefits when they move to programming .NET applications. Developers who have never used Spring nor have even heard about Spring quickly get hooked on Dependency Injection and the web framework once they see how much simpler and more flexible their code is as a result. Judging by the activity on the forums, these two areas are definitely getting the most attention.
There were many instances of positive feedback when developers giving Spring.NET a try say things like, "I'll never build another app without it" or "I wish I knew about it sooner". It is comments like these that really keep us going and validate the work we've done so far.
Of course, every once in a while we get a question such as, "What do I get with Spring.NET that I don't have in .NET 2.0/ASP.NET/EntLib/...?". We try to answer these questions as honestly and completely as possible and encourage people to try it for themselves - the benefits are fairly easy to see once you start playing with Spring.NET.
As for commercial adoption, we are seeing quite a bit of interest from large companies on Wall Street, as well as from some of the well-known Oil&Gas companies in Europe and the US. Some of these companies are existing Spring users that are looking to cross-train developers. This makes a Spring/Spring.NET combination very interesting due to the fact the programming model is preserved across the platforms. Others are .NET shops looking to simplify their development, period. We've been contacted by a Spring.NET user from a well-known international Oil&Gas company telling us that they are using Spring.NET as a foundation of their enterprise-wide development platform. This really gets us jazzed.
Oracle Consulting is using the Spring.NET data access framework on their projects, and there was some interest both from them and a few other consulting companies for Spring.NET training.
Another area where we are seeing a lot of interest is from software development companies. We've had a number of discussions with various software vendors that are using Spring.NET as the underpinning of their products. Spring.NET helps them to shorten time-to-market and to reduce the amount of code they have to write and maintain.
Mark: As for the metrics, they are easy to get but a bit harder to interpret, so I'm not even going to try. At the moment, we have about 2,000 downloads per month from SourceForge, but the actual number might be higher because for the past 3-4 months we've been telling people to use the latest nightly build instead, which is downloaded directly from our web site. We have close to 800 registered forum users and more than 100 active users, according to our forum software. FishEye shows us the number of lines of code has steadily grown to more than half a million over the past 2 and half years. This happened despite our ongoing vigilant attempts to prune out unnecessary stuff whenever we get a chance. Take this last number with a grain of salt though, because more than 80% of the reported lines of code are unit tests and documentation. Spring.NET is actually fairly light: assembly containing core DI container, expression language, and validation framework, as well as a number of configuration and utility classes is only 440 KB. AOP framework and Web framework binaries are even smaller, at only 96 and 88 KB respectively.
Of course, our numbers pale in comparison to Spring, which has had more than 50,000 downloads since its 2.0 release few weeks ago and is used by most financial institutions and banks in New York and London, as well as many others. However, consider the following facts: Spring has been in production since 2003, there are a number of books about it, and there are even two conferences devoted entirely to it, one in the US and one in Europe. On the other hand, most of the Spring.NET code is still in a pre-release state, with only the core DI container and AOP being officially released in late 2005. Finally, this is the first time that we are talking about Spring.NET in front of a wider audience. Given all that, we consider the numbers to be pretty good. What's more important, based on the feedback we have received so far, we know that we are on the right track and believe that we will see a lot more adoption as .NET developers learn more about Spring.NET and start realizing its benefits on real projects.InfoQ: What's the word from the user base on Spring.NET's successes or failures in real world projects?
Aleks: That kind of information is very hard to come by for an open source project. We are aware of a number of successful projects, both from our own experience and from the feedback on the forums, but people typically don't advertise project failures.
I have no doubt that there are some. After all, most IT projects still fail, which is a sad but undeniable fact. The question, however, is what is the reason for project failure, and from my personal experience and based on the project horror stories I have heard from others, technology itself is usually not the real reason. That said, it is entirely possible that someone tries to use Spring.NET where it shouldn't be used and the project fails, but then again, if I use a hammer to replace a light bulb, who is to blame: the hammer or me?
Spring.NET is just another tool in a toolbox. As long as developers critically evaluate their needs before choosing a toolset to use, there is no reason for a project to fail because of the technology. Unfortunately, developers, especially less experienced ones, tend to use "a new shiny toy" to solve every problem. This is an issue that can only be resolved through education and experience.
InfoQ: What's been going on with Spring.NET recently?
Mark: Our first priority is to get the final 1.1 release out. This release will include an improved DI container and AOP, as well as the official releases of the Web, Services, and the Data Access Framework. Unfortunately, both Aleks and I have been extremely busy professionally over the last several months and couldn't devote nearly as much time as we would've liked to Spring.NET. On the other hand, Bruno Baia and Erich Eichinger, two of the core Spring.NET developers, have jumped in and fixed most of the bugs we left behind and made some very cool improvements in various areas. We might be able to ship a release candidate in the very near future and the final 1.1 release by the end of the calendar year. Bruno and Erich will definitely be the ones to thank for getting the 1.1 release out the door.
Once that is off our plate, we need to make more information about Spring.NET available. We'll be writing articles, speaking at conferences and user group meetings and, not to mention, get back to the book we are writing for Apress that has fallen so far behind that neither of us has the guts to contact our editor.
Then of course, there is always the cool new stuff we plan to add into future releases...
InfoQ: What's being planned in future releases?
Aleks: Quite a lot, it's hard to decide where to start... First of all, there is always a need to improve existing stuff, so we'll work on adding new features to the core DI container, AOP, the web framework and everything else that will be shipped as part of the 1.1 release. As far as new features being considered, we are planning to add a framework for Windows applications that will do for Windows Forms developers what the Spring.NET Web Framework has done for ASP.NET developers. Some work has already been started in that area and there are some pieces that are fully finished. Take, for example, the data validation framework. It is currently being used within the web framework, but it can also be used within Windows applications without any changes, because it is completely presentation agnostic.
Mark: There are also numerous integrations that we have in the pipeline. We already have the following integrations: NHibernate for persistence, Anthem.NET and Atlas for AJAX, IIOP.NET for Java interoperability, and WSE2/WSE3 for web services. There are also proof-of-concept integrations with some of the EntLib blocks such as the caching aspect that allows you to plug in either the ASP.NET Cache or the Caching Application Block as a cache store for the method results. However, there is still a lot of integration work that could be done which would greatly simplify use of various tools and technologies within Spring.NET-based applications.
We are planning to implement integration capabilities with other useful tools such as: Wilson ORM and iBatis.NET for persistence, TIBCO, MSMQ and possibly MQSeries for messaging, full, production-quality integrations with all of the EntLib blocks... There are also some very exciting things happening in the interoperability arena where we are working to literally erase platform boundaries and deliver the possibility to make calls from Spring.NET clients to Spring-managed Java remote services and vice-versa. We want to make this interaction almost as simple as it would be within a single platform. We've also had requests for BizTalk integration, SharePoint support, etc. There is simply too much to mention, but ultimately it will be the users' needs that will decide which products and tools we integrate with and in which order. We have no doubt that some of the integrations will actually come from the users themselves.
Aleks: In addition, there are also many exciting things coming from Microsoft that we will look to leverage and integrate with as soon as they are out. I just realized when I was looking for the FishEye statistics that Bruno committed glue code for WPF to the sandbox. There is also Windows Communication Foundation, which will make our remoting capabilities even more powerful; Workflow Foundation which we can leverage within our web framework for process management. And I could go on, but the point is there are so many exciting things coming out, I have no doubt the next few years will be a lot of fun and hard work for the whole Spring.NET team. Hopefully it will be as much fun and result in significantly less hard work for our users. :-)
InfoQ: If I'm interested in Spring.NET where would I go to get started?
Mark: The best starting point is our web site, www.springframework.net, where you can find the link to download section. We'll try to get Preview 3 or Release Candidate 1 out in the next few weeks, but in the meantime the latest nightly build is your best download option. There are a number of samples in the download package, and we encourage users to review them in order to see how different Spring.NET features are used.
You will also find the links to documentation section, as well as the user forums, which are the best place to look for help.
We hope to see you there soon :-)
References
Spring.NET : http://www.springframework.net/IIOP.NET : http://iiop-net.sourceforge.net/
