We will introduce the new code based approach by working with a very simple application that will provide us the context to understand the concepts of CodeConfig. We start by examining a sample application that uses Spring.NET configured via ‘traditional’ XML configuration files. Then we show how CodeConfig can be used to achieve the same results without any XML configuration files at all.

To begin with, let’s explore the sample application that we will be working with. This sample app is included in the Spring.NET CodeConfig download package in the /examples/Spring.CodeConfig.Migration folder.

To keep things simple, it’s just a .NET console application designed to calculate and display the prime numbers between zero and an arbitrary maximum number. There are four classes that must collaborate together to do the work: ConsoleReporter, PrimeGenerator, PrimeEvaluationEngine, and OutputFormatter. ConsoleReporter depends on the PrimeGenerator which in turn depends on the PrimeEvaluationEngine to calculate the prime numbers. ConsoleReporter also depends on OutputFormatter to format the results. The main console application then simply asks ConsoleReporter to write its report and ConsoleReporter goes to work. The following Figure is a UML class diagram showing a simple way to visualize the dependencies between these objects.

A simple Main() method that would do this without the Spring.NET container could look something like Listing 1. Note the in-line injection of dependencies via constructor arguments that builds up the collaborating objects.

//Listing 1 (sample Main method not using Spring.NET)
static void Main(string[] args)
{
     ConsoleReport report = new ConsoleReport(
                              new OutputFormatter(),
                              new PrimeGenerator(new PrimeEvaluationEngine()));

     report.MaxNumber = 1000;
     report.Write();

     Console.WriteLine("--- hit enter to exit --");
     Console.ReadLine();
}

Using Spring.NET, as opposed to manually injecting dependencies as in Listing 1, the collaborating objects are composed together with their dependencies injected by the Spring.NET container at run-time. Initially, the configuration of these objects is controlled from a Spring.NET XML configuration file (see Listing 2).

<!-- Listing 2 (Spring.NET XML Configuration file, application-context.xml) -->
<?xml version="1.0" encoding="utf-8" ?>
<objects xmlns="http://www.springframework.net">
 
  <object name="ConsoleReport" type="Primes.ConsoleReport, Primes">
    <constructor-arg ref="PrimeGenerator"/>
    <constructor-arg ref="OutputFormatter"/>
    <property name="MaxNumber" value="1000"/>
  </object>
 
  <object name="PrimeGenerator" type="Primes.PrimeGenerator, Primes">
    <constructor-arg>
      <object type="Primes.PrimeEvaluationEngine, Primes"/>
    </constructor-arg>
  </object>
 
  <object name="OutputFormatter" type="Primes.OutputFormatter, Primes"/>
 
</objects>

In Listing 2 you can also see the use of “ref” element to refer to collaborating objects and the property “MaxNumber” being set to “1000” on the ConsoleReport object after it’s constructed. This is the maximum number up to which we want the software to calculate prime numbers. In Listing 3 we see the construction of the XmlApplicationContext which is initialized by passing it the name of the XML Configuration file. This container is then used to resolve the ConsoleReport object with all of its dependencies properly satisfied and its MaxNumber property assigned the value of 1000.

//Listing 3 (initializing the XmlApplicationContext container)
static void Main(string[] args)
{
     IApplicationContext ctx = CreateContainerUsingXML();
 
     ConsoleReport report = ctx["ConsoleReport"] as ConsoleReport;
     report.Write();
 
     ctx.Dispose();
 
     Console.WriteLine("--- hit enter to exit --");
     Console.ReadLine();
}
 
private static IApplicationContext CreateContainerUsingXML()
{
     return new XmlApplicationContext("application-context.xml");
}

While this XML-based configuration is well-understood by Spring.NET users and others alike as a common method for expressing configuration settings, it suffers from several challenges common to all XML file including being overly-verbose and full of string-literals that are unfriendly to most of the modern refactoring tools.

To reduce or even eliminate the use of XML for configuring the Spring.NET DI container, let’s look at how we can express the same configuration metadata in code using Spring.NET CodeConfig. There are several steps to using CodeConfig. We will look at each of them in the likely sequence that one would follow to convert an existing XML-based configuration for Spring.NET over to use the CodeConfig approach.

// Listing 4, (Spring.NET Configuration Class, PrimesConfiguration.cs)
using System;
using System.Configuration;
using Primes;
using Spring.Context.Attributes;
 
namespace SpringApp
{
    [Configuration]
    public class PrimesConfiguration
    {
        [ObjectDef]
        public virtual ConsoleReport ConsoleReport()
        {
            ConsoleReport report = new ConsoleReport(OutputFormatter(), PrimeGenerator());
 
            report.MaxNumber = Convert.ToInt32(ConfigurationManager.AppSettings.Get("MaximumNumber"));
            return report;
        }
 
        [ObjectDef]
        public virtual IOutputFormatter OutputFormatter()
        {
            return new OutputFormatter();
        }
 
        [ObjectDef]
        public virtual IPrimeGenerator PrimeGenerator()
        {
            return new PrimeGenerator(new PrimeEvaluationEngine());
        }
    }
}

//Listing 5 (bootstrapping the CodeConfigApplicationContext from Program.cs)
private static IApplicationContext CreateContainerUsingCodeConfig()
{
    CodeConfigApplicationContext ctx = new CodeConfigApplicationContext();
    ctx.ScanAllAssemblies();
    ctx.Refresh();
    return ctx;
}

The example in Listing 4 and Listing 5 demonstrates only the most basic use-cases for CodeConfig. More granular control over each of the definitions is provided by applying additional attributes to the [Configuration] classes and [ObjectDef] methods and by setting various values on these attributes. Among these are the following:

In addition, finer-grained control of the specific assemblies to scan, and specific [Configuration] classes to include and/or exclude is supported by the scanning API. It is also possible to compose configurations by dividing your [ObjectDef] methods into multiple different [Configuration] classes and then to assemble them as building blocks to configure your container as it is initialized.

The CodeConfig approach enables us to express the same configuration metadata to our Dependency Injection container as the XML file in Listing 2 had provided, but in a form that is at once both significantly more powerful and flexible as well as more resilient to the refactoring our container-managed application objects.

To address additional common non-XML configuration scenarios, such as the XML schemas for AOP and Transaction management, Spring.NET is also evolving a more fluent-style configuration API that will build upon CodeConfig in even more flexible ways in the near future including convention-based registration of objects.

The examples referenced in this document and provided in this distribution almost all employ merely a single [Configuration] class from which their ApplicationContext is to be configured. For these simple examples this approach is viable but just as is the case when configuring the ApplicationContext via XML, any significantly complex solution is likely to require separating your [ObjectDef] methods into multiple [Configuration] classes.

Just as there are several strategies for effectively managing multiple XML configuration files, so too are there many options available to the developer to organize and compose multiple [Configuration] classes together in a larger solution. This section doesn't attempt to cover all of the available options in deep detail, but is intended to provide a high-level understanding of some of the techniques that can be combined together to help manage multiple such classes. Users familair with the common techniques for composing together multiple XML configuration files for Spring.NET will recognize some of these same patterns applied to [Configuration] classes in the following sections as well.

[Configuration]
public class WcfServicesConfigurations
{
     [ObjectDef]
     public virtual IWebService MySpecialService()
     {
          //construct and return a IWebService implementation here
     }
}

[Configuration]
public class RepositoryServicesConfigurations
{
     [ObjectDef]
     public virtual ICustomerRepository MyCustomerRepository()
     {
          //construct and return a ICustomerRepository implementation here
     }

     [ObjectDef]
     public virtual IShippingRepository MyShippingRepository()
     {
          //construct and return a IShippingRepository implementation here
     }
}

[Configuration]
[Import(typeof(MyWebServicesConfigurations))]
[Import(typeof(MyMessagingServicesConfigurations))]
[Import(typeof(MyPersistenceServicesConfigurations))]
public class ServicesConfigurations
{
     //rest of class here as needed
}

[Configuration]
public class FirstConfiguration
{
     [ObjectDef]
     public virtual TransactionManager MySpecialTransactionManager()
     {
          return new TransactionManager();
     }
}

[Configuration]
public class SecondConfiguration : IApplicationContextAware //note the interface implementation
{
     //field to hold the injected context
     private IApplicationContext _context;

     //property setter defined by the IApplcationContextAware interface
     //     so that the context can inject itself into the class
     public IApplicationContext ApplicationContext { set { _context = value; } }

     [ObjectDef]
     public virtual ICustomerRepository CustomerRepository()
     {
          //to construct the CustomerRepository, we need a TransactionManager instance
          //     as a constructor argument so let's ask the injected context to resolve one for us
          return new CustomerRepository(_context.GetObject<TransactionManager>());
     }
}

//somewhere else in your solution the CustomerRepository class is defined as follows...
public class CustomerRespository : ICustomerRespository
{
     private TransactionManager _transactionManager;

     public CustomerRespository(TransactionManager transactionManager)
     {
          _transactionManager = transactionManager;
     }
}