This is Floyd Marinescu and Charles Torre of Channel 9 at the JAOO Conference with Mark Pollack founder and co-leader to Spring.Net. Mark can you tell us a little bit about yourself and how you came to be doing Spring.Net?

Sure. I originally was doing Java development in the late 90s and early 2000 and then found myself doing .Net development. During the time I was doing Java development I came across the Spring framework, which was a very popular framework for doing dependency injections and declarative transaction management for Java, and the itch I had to scratch was I wanted to program the same way in .Net, the same programming model I found very productive in Java on the .Net platform. Once you start to think about it, does it make sense to have this in .Net the more I look the more I realized it was a good idea, and asked permission from the team to go ahead and not make a fork but start a total new code base from the ground up with all that .Net-isms so it would be very natural to .Net developers.

What does Spring .Net offer .Net developers?

It offers basically three main areas of functionality: one is an inversion control container to perform dependency injection this is an aids to creating loosely coupled of applications; flexible in terms of being able to plug in different implementations and also promoting practice of test driven development. The second major feature is Aspect Oriented Programming, which allows you to modularize certain functionalities and then sprinkle it across the code base, such as login and transaction management. There is also an important feature which goes by name portable service abstraction, where you can take a class and export it as a .NET remoting service or export it as a WCF service or export it as a COM+ component. Lastly there is a collection of helper libraries that basically tame complexities that are incidental to doing development. And these are in ASP.Net and ADO.NET. So if you can take an approach where you use dependency injection non-invasively, you have ties to the framework that supplies to ASP.NET pages as well as regular classes, but then you can inherit for example from Spring's page base class and get features like bi-directional data binding and validation, that is kind of stuff people do over and over again, and it is boilerplate code that gets encapsulated in ASP.Net framework.

Let's talk about the problem that you are solving. That was solved in Java and then you took it and transcribed it or transferred it over to .Net, dependency injections.

Dependency injection is basically a technique to configure your application. So generally speaking there are points in your application architecture for example where you would like to have some variability, so for example between your service layer and your presentation layer, those two are typical layers, your service layer might call into a data access layer. And that boundary should be well defined, so you can accommodate change in the future, maybe you change your data access layer, maybe you change your presentation layer. And so if in your code base you just explicitly refer to a particular implementation, changing your layer date becomes very hard. And the other more realistic aspect I think that is important to short term is promoting test driven development. You might have a need maybe a year from now to change let's say your data access layer but right now you might want to actually provide a stub or mark implementation of that to test your service layer in isolation. It's like your immediate point of variability is doing testing and having Spring to basically make it very easy to swap in and out different implementations is the core goal and the way it achieves that is with a sort of "a mother of all object factory" and it is very flexible, very configurable. The object factory is a central artifact that one could have written yourself. But if you really take it to the level it needs to perform this in a sophisticated way, you end up writing what essentially is a container that looks very far from the object factory you'll find let's say in the design patterns book.

Excellent. Did you rely on generics?

The implementation right now doesn't have generics in the part of the API that deals with the management. So when you actually use the API you would do casting, but the power of dependency injection is that you should actually never have to call an API directly, that you should give hints to the core or to whatever the configuration mechanism is - it could be XML - it could be attributes - basically that meta data describes the relationships, it says object A is related to object B. Those two can have generic methods, than can be generic classes and those are plugged together. That's the loose coupling story. So because there is no API to say "if you use XML there is no attribute your code isn't tied to the framework". And that's a very important feature so it is not invasive. You can take classes you wrote ten years ago or whatever even .Net 1.0 and wire them up. Or you can take a third party library for example TIBCO Rendezvous is a popular library in the financial community, and you want to basically configure your messaging server. You can do that with Spring.Net in this external XML configuration.

Cool. I have one more question I would like to ask. In the real world, are you seeing a lot of .Net developers leveraging this, using it and in particular the C++ .Net crowd?

I haven't seen anyone into C++.Net crowd period. So maybe I am out of touch but I don't see a user base having a large representation from C++ users. It's overwhelmingly C Sharp, followed by VB.Net

The reason I asked the question was the way that managing C++ works is you just use easily in an easy fashion you can use the power of the framework in various ways. So I was thinking something like this could be very helpful for if I am writing a C++ application I could use this framework.

Any language mapped on IO code is going to be usable by this. If you are a C++ developer and like to get this benefit, manage C++ then go ahead use it I would love to actually see that.

Actually what kind of usage patterns are you seeing for this?

There is one very showcase usage pattern which is a company called Mechado Electronico, a leading Latin American B2B company that is shifting from an ASP common infrastructure to .Net. And they are using Spring in many ways not just the dependency injections features but also ASP.Net framework. It's the core of its redesign to architect a new system. And then of course other companies that I can't mention their names but they are in the banking world and because they are already using Java and the service eye with Spring when they do .Net client development a natural choice for them is to use Spring on the client side as well.

Any interoperability?

Interoperability is usually web services and messaging.

What parts of Spring and are not being imported to spring.Net?

Right now the 1.1 release of Spring.Net has all the functionality that Spring 1.2 family and Java had. What the current one leaves behind is things that are not as mature in the .Net platform for example in Java. There is Aspect J which is a byte code weaving to integrated aspect engine that is equivalent on .Net to PostSharp and some others. That's one area we don't have. Another area is integration with dynamic languages, they can define objects that are managed by the container which are defined in Ruby or Python. Those are some of the features that we don't have but the nice part of design being very similar in .Net and Java is that it can start easily bring features into Spring.Net from the Java implementation quickly. And it is actually vice versa. One of the big features of Java version Spring 2 is a custom XML schema. The idea originated in the .Net, so that bidirectionality is used not just for feeding from Java to .Net but vice versa.

Spring in the Java community arose out of problems that existed using the Java EE platforms in the past. What are some problems in the .Net platform that might lead someone towards wanting to use Spring.Net?

One of the issues that I came across is transaction management. In the .Net 1.1 framework there's a enterprise services library that gave you the ability to declarative transaction management through attributes on the class. However that came with certain limitations. One was that you always had to use distributive transactions and that is a very heavy penalty to pay for such a feature. Going a step forward, what we provide is the clarity of transaction management but with local single resource transactions. The system transactions namespace has this kind of promotion model where you can start local and go to distributed but a quark of the usage is that you end up going to distributive transaction out of any realistic design you have of your data access layer. That really adds a lot of value there to bring that flexible programming model of declarative transaction management to .Net.

What does Spring.Net offer .Net developers in the area of Aspect Oriented Programming?

It offers a complete framework for doing Aspect Oriented Programming but usually as a first step people just want to use pretty built aspects, so transaction management is one of those. Recently we have added additional library support so that out of the box you can have Aspects for doing exception translations or login or caching. So it is much as we can present prebuilt aspects that you can use right away, that's a gentle introduction. Then you can write your own using API to introduce functionality that might be specific to you.

Spring AOP is very easy to use in the Java community and it's very cool that the .Net community has Spring.Net to bring the same features. Can you tell us a bit about what AOP actually is and how .Net developers can use it?

Sure. AOP addresses the so-called cross cutting concerns and this is a buzzword or catch phrase, to refer to code that is spread throughout your system but isn't encapsulated in object hierarchy. It goes in places Object Oriented Programming can't go. So for classic example is login code. Login code appears in your service layer, login code appears data access layer, it is just everywhere. And what if you want to change it? It is not modular, it is not encapsulated in one spot. If you start adding up other things that are spread around like that, for example caching; I might cache in various different places. Not only is it spread around and not modularized, but if you start to look at the method implementation it starts to be polluted with things that aren't related to the business. Caching isn't actually related to the business logic, neither is login, but the method implementation might be half of that, half of the method implementation might be related to this so called cross cutting concerns such as transaction management, caching, login, security checks. And so AOP gives you a way to put in one spot that particular implementation so you can focus on making a high quality implementation and then select points in your application to add that functionality. With the upcoming features in Visual C# 3.0 you can think of it in some way as extension methods that extend behavior of classes, you can add functionality from the outside to an existing class.

What's the difference between creating a bunch of static methods that do things whenever they want. So if I am writing a class that is doing something in the UI layer and I could just call a static method to run some log. What's the difference?

The difference is what amount of code noise is that you are going to start writing and say half the method is doing something that analyze the business. That's one concern. The other is that if you want to change what that method is doing with that static method, you have to refractor everywhere and maybe you can do something more drastic. For example the security API might change very fundamental way. If you expect these points to have some variability in particular, then having a way to easily change the implementation and reapply it round the method implementation is very powerful. Basically what you do at transactions: you have a transaction scope, goes around the block of code, and there is that block there. Usually it is more then one line, it is usually a series of lines, you can have cut and paste errors, and people actually end up having also error of omission. If you have a service layer and you say "I would like the service layer to be transactional". Then you'll have 80 classes, each of them have 10 methods, you better make sure in 800 places you have the code right. In AOP in one spot you have the transactional code, and you say "Apply it there, to the service layer", and now you really have confidence that you have done this. Or for example if you are calling it to a controlling layer, into a GUI and you say "I want that to be audited, if there is any errors", now you can simply say in my control layer it is going to be logged and next week I want to add a dialog box that pops up and gets additional contextual information from the user what happens there and now you can just chain another piece of advice as the behavior to what you currently have in your system. And you are done right? You just basically effected the code in multiple places but in a very well controlled manner.

And in Spring.Net how do you identify a pattern of classes that should be wrapped with Aspects?

There is a different point cut classes that give you the ability to define that. There are a couple that come out of the box, the most flexible which is the regular expression one where you basically have sensible conventional naming of your name spaces and you do a regular expression to pick up all the classes in the name space. That is the most common technique. But you have freedom to implement your own custom point cuts, to identify locations in the code. This is where domain specific languages help, that you can have a way to express that in a very high level manners compared to a regular expression or to a code itself, C# code.

What's the performance story in Spring.Net, using reflection isn't that a problem?

It is not a big problem in a fundamental sense that usually this wiring instantiation happens when the application starts. So it's kind of a one time cost. But because of an expression language we built into the framework out came this very optimized reflection library. So we generated IO code at runtime to do reflection and the end result is that you have a code that is reflection like, but executes basically the same speed as normal code.

Very cool

And this is one area that might also get back imported into Java.

Tell us more about the ASP.Net support in Spring.Net.

The ASP.NET support starts up really with enabling you to wire up your user pages, your controls, also custom HTTP modules, and custom provided classes such as membership and role providers. It gives you a great amount of configuration ability without any ties to Spring. Your page can refer to a service layer, to actually call in to do its work once you hit submit on a form for example. But then there is a long list of features, work that people do over and over again that are well represented in the base framework. So one example is data binding. The controllers you have for doing data binding are only one way, so you are constantly picking data out of controls, and then parsing them, and then maybe there are issues in the parsing, and you have to display those parsing errors. That is wrapped up into a very nice bi-directional data binding support, and the model management that you end up having to do as well is it a post back, is it not, get abstracted in a life cycle method that binds the model, unbind the model, so that typical state management you do is significantly simplified.

Portable service factory that almost sounds like a competitor to WCF. Is that true?

There are a lot of similarities in it but the Spring approach goes one step further, if you are very pure about it you might view the annotation itself is being artifact to the technology. But what WCF is doing is in fact very much along the line to what Spring has been doing all along in terms of giving you flexibility, in terms of configuration, what your middle where is, is it messaging, is it web service, is it secured, is it not secured. It meshes well and it probably has less value now as it did for example when you wanted to do .Net remoting and that actually required you to inherit from a special class. Or if you wanted to do web services and you had to add different attributes. Now it is unified but it still has some value if you choose to quickly export some things for administration reasons. You might just want to make a quick .Net management interface that you can use .Net remoting for, take a class, essentially an internal admin API quickly exported to .Net remoting, and you didn't really have to plan that ahead of time. You just later decide "Oh this class would be useful to be remoted" and if you think about it you don't want to make a fine grained API distributed but gives you the choice to do that if you choose to, gives you the opportunity.

Have you noticed any knee-jerk reactions against the framework just because it doesn't come from Microsoft?

There definitely are some people who are conservative almost and stick with the base framework altogether. They don't have any reliance in any external framework. I think to a large extend those people are a little bit misguided because they do bring value even though there is a learning curve. But at the end of the day, the issues of doing development better are most important and because the patterns and practice group are similar work if they choose to stick with pure Microsoft stack, meaning all comes from the Microsoft name space, then they can choose that and I think in scenarios we compete we are better in terms of implementation, then they might go that path and get hooked and then maybe want more and then look to Spring.Net for additional functionality.

You took a mature complete framework from one programming language and environment, and ported it to a whole different one. What was it like? What were some of the interesting twists you had to deal with in that effort?

Some of the interesting twists were around deciding which classes should have virtual methods. In .Net you have to make a conscious decision that a class has got to have this method overwritten. And in particular to a framework it is very important the contract you provide to people who might want to do subclasses. It requires you to think a lot more about the API contract. Clearly the last similarities, some are just boilerplate transformations, getter and setter to properties. But the most interesting part is that I dealt into areas of transaction management that I wouldn't have otherwise had to delve into really unless I was porting a framework. Even if the origins of the need are grounded in reality of usage on projects the depth in which you are exploring an API is greater than if you were doing regular business coding and that was rewarding to gain that level of knowledge.