Introduction
Spring.Net is a framework aimed at providing comprehensive infrastructural support for .Net enterprise applications. At the core of Spring.Net is the concept of Dependency Injection, otherwise known as Inversion of Control. With the example code provided, you can follow along as you take a look at Spring.Net and how it implements this powerful concept.
Spring.Net: Overview
Spring.Net is an open source framework that provides a toolset of components that help developers implement industry best practices such as Dependency Injection and Aspect-Oriented Programming. The concept of the Spring.Net framework was adopted from the Java version of the Spring Framework. To date, the Java version of Spring has been used very successfully in thousands of enterprise applications worldwide. With the success of the Java version, it was only a matter of time before Spring.Net came along, and now that it is maturing, Spring.Net is gaining a following in the .Net world.
Here is a quick list of some of the functionality Spring.Net includes:
- Dependency Injection
- Aspect-Oriented Programming
- Data access support including support for NHibenrate (ORM framework)
- Web Framework
- Integration Testing
- Validation Framework
- Dynamic Reflection
- Threading and Concurrency Support
- Object Pooling
- Expression Evaluation
- Services
- More...
And with the community behind it, Spring.Net is constantly growing with new functionality being added on a regular basis.
Also note that Spring.Net is set up like a toolbox. You are not required to utilize every tool in the box. You can mix and match different functionalities and use only what makes sense for your application. Spring.Net is even split up into different assemblies so you don't need to include the entire framework in your application.
Dependency Injection with a Factory Pattern
At the core of Spring.Net is the concept of Dependency Injection (DI), also known as Inversion of Control (IoC). The basic idea of Dependency Injection is to provide external dependencies to objects through some external mechanism as opposed to requiring the objects themselves to set up their own dependencies or even worse, requiring the processes that use the objects to set up the required dependencies. The end goal is Loose Coupling. Groups of objects should work independently of one another, focusing on their specific tasks without needing to worry about how other groups of objects work or are constructed.
To better understand the concept of Dependency Injection, it is probably best to look at the classic implementation of DI by using factory classes. As described in the ever useful book, Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, there are two main factory patterns on which factories are built: the Abstract Factory Pattern and the Factory Method Pattern. The idea of the Abstract Factory Pattern is to provide an interface for creating families of related or dependent objects without specifying their concrete classes, and the idea of the Factory Method Pattern is to provide an interface for creating objects but letting the subclasses decide which classes to implement.
Figure 1: Abstract Factory Pattern
Figure 2: Factory Method Pattern
To put it simply, factories are a separate object or set of objects that handle the logic for selecting the correct concrete object for a given scenario and constructing the object by injecting any dependencies needed and setting it to a predefined state. Generally, the process using the object will not even know the concrete implementation of the class and instead will work with the object through an interface. By encapsulating the instantiation and construction logic in the factory, the process using the object doesn't need to know specifically what concrete object is being used, how the object is built, or how the object does its job. It only knows that the object will do its job when asked.
In larger applications with multiple possible configurations, factories also can serve as the central point of configuration. For example, if you need to swap out several database components that communicate with MySQL and replace them with a new set of components that communicate with Oracle, all you need to do is change the factory classes to point to the new Oracle components. The rest of the application will be unaffected, because as far as it is concerned, all database components that implement the same interface to retrieve, save, update, and delete objects should work the same. How the components work under the covers and what database they communicate with doesn't really matter.
It is this simple yet powerful idea of a separation of concerns that is the crux of Dependency Injection and Loose Coupling.
IE 7
Firefox 2.0
