Spring.NET - QnA
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 :-)
ReferencesSpring.NET : http://www.springframework.net/
IIOP.NET : http://iiop-net.sourceforge.net/
Spring.NET - QnA
- Raise your hands all practicants. I need to be convinced of the newness of this term. So, here goes...
"If you think about it, there is nothing new about Dependency Injection per se. "
- Is this related to when a function call has a structure address instead of a void pointer as one of it's arguments?
"I could find similar examples in older technologies as well, such as VB6 or COM."
- Gray hairs in my beard. I made the survival choice in the early '90s to Win as the better and under-marketed OS/2 took the brunt of the backlash against Big Blue. Beauty sunk. VB2/3 those days. Give D/COM/++ the hat it deserves today. A modern and relevant technology with a resilient design by perhaps the best mobile and survival oriented object framework implementors. COM remains the inspiration and parent of .NET. Without COM, .NET cannot load on Win32. .NET has still to prove that it can cross the road, stay over for the night, deal with the neighbours, and return as naive as it left the night before. All with a smile.
"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."
- Word-play? Lightweights with mandatory big brothers whether they be a JVM or a .NET runtime, A "nothing new" thing so old that it influenced a whole generation of popular offspring I am guilty of only having read about lately? Some code examples ?
"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."
- Which world are we referring to? How does this handle interoperability between dissimilar factions? This surely relates only to the "protected" and custom and super modern programmed super intimate, well-known/static/designed-after the fact/non-scaleable interface handlers within the domain of the J2EE / .NET world? This can surely not relate to the real world of tightly coupled high-performance and often blundering peculiar and by historical definition distinct protocols. Sockets blasting away at each other all over the place in different-speak no matter what is at the other end? Mainframe LU6.2, DB Call Interfaces, DCOM, CGI, ODBC, Netware etc. Even if everything would be TCP/IP, how does this equate to compatible and discoverable perhaps alive object instances outside J2EE and .NET lingo?
Re: Spring.NET - QnA
I don't quite see what point you are trying to make here. Perhaps you could rephrase it with a little less bitterness and a little more clarity.
Re: Spring.NET - QnA
There are many young and old programmers who could benefit from my post as it stands. Perhaps you could pinpoint an area of my post that offended you.
Re: Spring.NET - QnA
As David pointed out, it is not very clear what in the article you disagree with. If you could point us to the specific points we are making that you don't agree with, Mark and I will be more than happy to respond.
In the meantime, let me try to answer to some of the things you seem to disagree with:
1. Dependency Injection
The term itself is fairly new, and it was coined by Martin Fowler in early 2004. The containers that have made DI so popular in the recent years are also fairly new. The principle, however, is not new and can be used on any platform and in any language, as it is simply a way of designing loosely coupled OO systems.
2. .NET vs COM/DCOM/COM+/VB2-6, etc.
Without getting into discussion which one is better, which would be pretty pointless exercise, I'd just like to say that the article's intended audience are .NET developers. It was not our intention to position it as "everyone should switch to .NET" propaganda, and as far as I can tell it doesn't read that way either. Sorry if you interpreted it wrong.
3. Lightweight vs. Heavyweight
When we are saying that Spring provides a "lightweight" container, we are not comparing it to JVM or CLR. "Heavyweights" are actually EJB container in Java and COM+/MTS on the Microsoft side. All of these containers provide some services, but some are much lighter than the others, and that's where the term came from.
4. Object wiring and cross-platform interoperability
When we are talking about "object wiring", for the most part we are talking about objects on the same platform. There are ways for .NET, Java, C++ and other objects to call each other, but that usually involves some kind of proxy/stub mechanism that bridges platform differences. For example, Spring.NET allows you to create a proxy to any CORBA object, so technically you could wire objects on different platforms together by injecting proxies into your application objects.
Re: Spring.NET - QnA
First off, all kudos go to your project. Credit earned.
As I pointed out, many programmers can benefit from my post; and the follow-ons. Whether it is perceived to be left or right or not at all is up to them to decide.
Per your numbers:
1. Dependency Injection
This term is of no practical use.
All practical programmers understand it already and do not need a new name. Where I was born, making new names for old things and then selling them is a cheap way of making money one does not deserve.
Startup programmers that are already intimidated by the perceived smoke and mirrors complexity of software development in modern world should not be educated in this way.
Programmers need intelligent tools that are free of dependency on external factors like re-invention of existing terminology. I recall an English term about throwing fish (Scottish fish, Herring? (free Nordic fish?) ) in the air to distract enemies.
Writing software is difficult enough yet most of us started and are starting out to have fun whilst being creative. So we choose programming.
2. .NET vs COM/DCOM/COM+/VB2-6, etc.
It seems I made a mistake by invading a ".NET" space?
3. Lightweight vs. Heavyweight
Ths word "light" surely misguided me. Do you mean an undemanding layer over the .NET framework?
I believe it will misguide techno-informed business-oriented managers and new programmers which we value.
It leads to unrealistic expectations and then over budget projects delivered apparently on time due to pressure. After that a piece of cow-dung has to be supported by the developers due to its quirky nature and cannot be fixed without business paying even more.
4. Object wiring and cross-platform interoperability
I must admit that I have not read the Spring.NET source code and this makes me feel like an outsider. Sorry, I do have a life. This is the part I am most interested in. My previous post stands as is on this subject.
Re: Spring.NET - QnA
1. I do agree with you that terms such as "Dependency Injection" can scare new programmers, or even experienced programmers who encounter the term for the first time. However, I do think that Dependency Injection is a much better name than "Inversion of Control", which is the name that was, and to a certain extent still is, used to describe the same concept.
As for "practical programmers" not needing a new name for it, I'd agree with you if there was an old name for it. If we exclude above mentioned "Inversion of Control", which is really a much broader term, I'm not aware of an old name for the thing we are describing as Dependency Injection today.
If you are saying that you don't think we need a name at all, I disagree. Having a common name for something makes discussions much easier. Design patterns have been around for a long time, but it wasn't until GoF compiled them and gave them meaningful names that such a wide audience was able to understands them and discuss them. Short and meaningful names really do make communication much simpler.
2. I don't think you invaded .NET space at all. All I was saying is that article's intended audience are .NET developers and that we are not trying to say that .NET is either better or worse than other technologies out there. We are simply saying that the average .NET developer can greatly benefit from the services provided by Spring.NET -- that's it.
Neither Mark nor I are "territorial" when it comes to technology. I use both Java and .NET on a regular basis, because that's what most of my clients want me to use and what I'm most experienced with, but I have used many other languages and platforms in the past, and will probably use plenty more as long as I'm doing this job. As I pointed out in the article, there is no single tool that is the best choice for every job, so unless the client dictates what to use I tend to choose whatever will work best for the particular application.
3. What I mean by "lightweight container" is an undemanding, fairly simple, configurable and extensible container for application objects. So lightweight in fact that you can bring many of them up when you need them and destroy them when you don't. There is a lot of value in having objects within a container, but that's a topic for whole another article...
4. There is no reason for you to read Spring.NET source code. You can download it and try the features you are interested in for yourself. There is documentation and a few sample apps that will show you how to configure Spring.NET client to access remote EJB, or any other CORBA-compliant object using IIOP.NET integration. Keep in mind that this particular feature is more in the experimental state and there is a lot more than can and needs to be done, but it wouldn't be too difficult to do if there is more user demand for it.
Re: Spring.NET - QnA
I am not going by the numbers this time (:-)
In short, based on my experience I believe words and terms are (re-)invented too often in this industry.
Too many times this is done for the benefit of creating new business opportunities and/ or markets for the biggest guns of the time.
I have not seen the terms nor technology stick around long enough to add real value, teach better individual personal programming ability, confidence in continuity, nor provide a skills growth path that builds instead of re-inventing.
The worst is that most of the best ideas never achieve real corporate penetration. So in the longer term, they do not provide job opportunities for aspiring programmers with sustainable demand for their improving skills.
It is mostly the individuals with skin-deep knowledge on the latest hype that get a job and thus experience until the next best thing comes along.
Essentially, in my humble opinion, by far most modern code is still implemented in, at best, the same way as 20 years ago.
What has changed is the sheer number of people from all walks of life willing to write a bit of code. This has changed the world irreversibly and surely for the better.
However, this is mostly attributable to technologies that empowered individuals (for example the internet, mobiles, games etc.) and individual "nobodies" like the GPL'ers that proved everybody has the right to be a "hacker", indeed a successful one.
I honestly cannot say that I think software development practices and methods have advanced to keep pace with the challenge. It seems more of a "Wild-West" now than when I started. Not that I am personally ignorant of the allure of being a gunslinger myself.
Based on our discussion so far, perhaps I did not make a mistake posting ("invading") here after all.
At least, this is the kind of forum and the kind of post (to your credit), that corporate pioneers will be reading and thus might help to remedy some of my misgivings.
Re: Spring.NET - QnA
Before DI people were trying to build houses by concentrating on creating the best bricks. Nothing wrong with superb, technologically advanced bricks. However in those days people would have to worry a lot thinking about how well do these bricks fit together (in those days the bricks didn't fit well because every time you'd do a better, improved, different brick you'd have problems in fitting them with the old bricks),after DI they stopped worrying on how well the bricks fitted as it suddenly became easy and standard for you to connect all these different bricks so people started focusing on the building instead of the bricks.
Or, as a teacher of mine would put it, before we were thinking as westerners and trying to be reductionist, now people are starting to think as easterners and taking a more holistic view of the world.
We know that the concepts of how to implement DI are not radical, intrusive or something that wasn't possible before, but, if something changes your view of the world, it deserves a new name.
Plus, and I don't know where you live if you don't use them already, these frameworks go a long way from just doing the basic dependency injection and offer pre-made blueprints to build solid, hospitable, pretty,...,houses and it costs you less to build a house that will sell for more.
Re: Spring.NET - QnA
You are right; I suppose I did open the door to more than mere technical arguments.
Re: Spring.NET - QnA
I am an .Net developer, but new to Spring.Net. You mentioned that you are writing a book for Apress. My I ask what this new book about? I, as .Net developer, really need a book for Spring.Net. If yes, when is it going to publish?
I know Manning is going to publish "NHibernate in Action" this year.
Re: Spring.NET - QnA
Yes, the book is on Spring.NET and it will cover all major areas of the framework. It is a bit harder to answer when it will come out...
At the moment, we are working very hard to get the final release out, so there really isn't that much time to work on the book. Hopefully we will have more time to work on it once Spring.NET 1.1 is released, so we might be able to get it done by the end of this year.
That said, Spring.NET reference docs are fairly complete and will be a good starting point for anyone new to the framework. We are also planning a series of articles on Spring.NET for InfoQ, which should cover quite a bit of ground as well. In addition to that, we will start offering public and private Spring.NET training pretty soon as well.
Hope this helps,
Re: Spring.NET - QnA
Is the book ready? I couldn't fount it on the Apress site.