Spring Framework (Version 1.3.0) 2
Chapter 2. Introduction
2.1. Overview
Spring.NET is an application framework that provides comprehensive infrastructural support for developing
enterprise .NET applications. It allows you to remove incidental complexity when using the base class libraries
makes best practices, such as test driven development, easy practices. Spring.NET is created, supported and
sustained by SpringSource.
The design of Spring.NET is based on the Java version of the Spring Framework, which has shown real-world
benefits and is used in thousands of enterprise applications world wide. Spring .NET is not a quick port from the
Java version, but rather a 'spiritual port' based on following proven architectural and design patterns in that are
not tied to a particular platform. The breadth of functionality in Spring .NET spans application tiers which allows
you to treat it as a ‘one stop shop’ but that is not required. Spring .NET is not an all-or-nothing solution. You can
use the functionality in its modules independently. These modules are described below.
Enterprise applications typically are composed of a number of a variety of physical tiers and within each tier
functionality is often split into functional layers. The business service layer for example typically uses a objects
in the data access layer to fulfill a use-case. No matter how your application is architected, at the end of the day
there are a variety of objects that collaborate with one another to form the application proper. The objects in an
application can thus be said to have dependencies between themselves.
The .NET platform provides a wealth of functionality for architecting and building applications, ranging all the
way from the very basic building blocks of primitive types and classes (and the means to define new classes), to
rich full-featured application servers and web frameworks. One area that is decidedly conspicuous by its absence
is any means of taking the basic building blocks and composing them into a coherent whole; this area has typically
been left to the purvey of the architects and developers tasked with building an application (or applications). Now
to be fair, there are a number of design patterns devoted to the business of composing the various classes and
object instances that makeup an all-singing, all-dancing application. Design patterns such as Factory, Abstract
Factory, Builder, Decorator, and Service Locator (to name but a few) have widespread recognition and acceptance
within the software development industry (presumably that is why these patterns have been formalized as patterns
in the first place). This is all very well, but these patterns are just that: best practices given a name, typically
together with a description of what the pattern does, where the pattern is typically best applied, the problems
that the application of the pattern addresses, and so forth. Notice that the last paragraph used the phrase “... a
description of what the pattern does...”; pattern books and wikis are typically listings of such formalized best
practice that you can certainly take away, mull over, and then implement yourself in your application.
The Spring Framework takes best practices that have been proven over the years in numerous applications and
formalized as design patterns, and actually codifies these patterns as first class objects that you as an architect
and developer can take away and integrate into your own application(s). This is a Very Good Thing Indeed as
attested to by the numerous organizations and institutions that have used the Spring Framework to engineer robust,
maintainable applications. For example, the IoC component of the Spring Framework addresses the enterprise
concern of taking the classes, objects, and services that are to compose an application, by providing a formalized
means of composing these various disparate components into a fully working application ready for use
2.2. Background
In early 2004, Martin Fowler asked the readers of his site: when talking about Inversion of Control: “the question
is, what aspect of control are [they] inverting?”. Fowler then suggested renaming the principle (or at least giving