The first modification to the existing sample application involves changes to the <spring> element in the App.config file:

   <spring>

    <parsers>
      <!-- Equivalent to 'NamespaceParserRegistry.RegisterParser(typeof(ContextNamespaceParser));' -->
      <parser type="Spring.Context.Config.ContextNamespaceParser, Spring.Core.Configuration" />
    </parsers>

    <context>
      <!-- using embedded assembly configuration file -->
      <resource uri="assembly://Spring.IocQuickStart.MovieFinder/Spring.IocQuickStart.MovieFinder/CodeConfigBootstrap.xml"/>
    </context>

  </spring>

The important changes here are the introducton of the <parsers> section (to register the ContextNamespaceParser required for CodeConfig) and the change of the <resource> element to point to the CodeConfigBootstrap.xml file instead of the Appcontext.xml file as before.

Where before the Appcontext.xml contained all of the XML-based object definitions for the application, in this case the CodeConfigBootstrap.xml merely contains the single instruction telling the context to use CodeConfig:

<?xml version="1.0" encoding="utf-8" ?>
<objects xmlns="http://www.springframework.net" 
         xmlns:context="http://www.springframework.net/context">

  <description>An example that demonstrates code based configuration for object definitions.</description>

  <context:code-config/>

</objects>
 

In this case, the single <context:code-config/> element is sufficient to tell the context to perform scanning for its object definition metadata.

The final modification needed to migrate the sample application to rely upon CodeConfig is to author the classes that will provide the Object Definitions for the Application Context to discover when performing the scan. In the case of this simple application, this is encapsulated in the single new MovieFinderConfiguration class as shown in the following:

    [Configuration]
    public class MovieFinderConfiguration
    {

        [ObjectDef]
        public virtual MovieLister MyMovieLister()
        {
            MovieLister movieLister =  new MovieLister();
            movieLister.MovieFinder = FileBasedMovieFinder();
            return movieLister;

        }

        [ObjectDef]
        public virtual IMovieFinder FileBasedMovieFinder()
        {
            return new ColonDelimitedMovieFinder(new FileInfo("movies.txt"));
        }
    }

Using a combination of [Configuration] and [ObjectDef] attributes, this class faithfully reproduces the same Object Definition configuration as had been described by the Appcontext.xml file in the iniitial sample application as delivered with the main Spring.NET Framework download.

The first modification to the existing sample application involves changes to the <spring> element in the Web.config file:

<spring>
    <parsers>
      <!-- Equivalent to 'NamespaceParserRegistry.RegisterParser(typeof(ContextNamespaceParser));' -->
      <parser type="Spring.Context.Config.ContextNamespaceParser, Spring.Core.Configuration" />
    </parsers>

    <context>
      <resource uri="~/Config/CodeConfigBootsrap.xml"/>
    </context>
  </spring>

The important changes here are the introducton of the<parsers> section (to register the ContextNamespaceParser required for CodeConfig) and the change of the <resource> element to point to the CodeConfigBootstrap.xml file instead of the controllers.xml file as before.

In addition, the section name for the <parsers> element must be registered with the <spring> sectionGroup as shown here so that the element can be properly interpreted:

  <configSections>
    <sectionGroup name="spring">
      <section name="context" type="Spring.Context.Support.MvcContextHandler, Spring.Web.Mvc"/>
      <section name="parsers" type="Spring.Context.Support.NamespaceParsersSectionHandler, Spring.Core"/>
    </sectionGroup>

    <!--
        remainder of configSections element here...
    -->

  </configSections>

Where before the controllers.xml file contained all of the XML-based object definitions for the controllers for our MVC application, in this case the CodeConfigBootstrap.xml merely contains the single instruction telling the context to use CodeConfig:

<?xml version="1.0" encoding="utf-8" ?>
<objects xmlns="http://www.springframework.net" 
         xmlns:context="http://www.springframework.net/context">

  <context:code-config/>

</objects> 

In this case, the single <context:code-config/> element is sufficient to tell the context to perform scanning for its object definition metadata.

The final modification needed to migrate the sample application to rely upon CodeConfig is to author the classes that will provide the Object Definitions for the Application Context to discover when performing the scan. In the case of this simple application, this is encapsulated in the single new ControllerConfiguration class as shown in the following:

    [Configuration]
    public class ControllerConfiguration
    {
        [ObjectDef]
        [Scope(ObjectScope.Prototype)]
        public virtual HomeController HomeController()
        {
            HomeController controller = new HomeController();
            controller.Message = "Welcome to ASP.NET MVC powered by Spring.NET (Code-Config)!";
            return controller;
        }
    }

Using a combination of [Configuration] and [ObjectDef] attributes, this class faithfully reproduces the same Object Definition configuration as had been described by the controllers.xml file in the iniitial sample application as delivered with the main Spring.NET Framework download.