With our experience in industrial software, we noticed that many projects needed a modular architecture for configuration or recipes. To facilitate the work of the developer and reduce development time, Concept provides tools to create, edit and serialize a modular architecture.

The simple model below, illustrates perfectly a modular configuration requiring components like :

• Polymorphous component.
• Polymorphous list.
• Links between different objects

Concept provides all of these elements to easily create a hierarchical model like this one. Furthermore Concept also provides many other functionalities such as:

• Unique identity of a component within its parent, using a unique name. This feature enables any object in a Concept tree to be found by its absolute path (from this object up to the root) giving the ability to define links, serialize the model and more.
• Default value of a property by using an attribute. The property will be set with this default value upon first use, when new properties which have not yet been serialized are defined and when a model is cleared with Concept.
• Serialization / de-serialization of a modular architecture. This feature enables to save a complete architecture in a xml file to reuse it later.        
• Management of Concept attributes on classes and properties. Concept provides various attributes to facilitate the application development such as an attribute to automatically create objects.
• Creating an application's process based on a configuration. Concept enables the creation of a process depending on the elements used in the configuration (see the provider mechanism). 
• Automatic edition of a Concept data model. This feature enables to edit a data model effortlessly with the ConceptEditor and the default views provided by Concept                 

We usually create a root element which will contain the different models of the application (configuration, job, ...) such as the configuration shown above. Through this root element, we will have access to the different models of the application. To easily get to the different models, the root must be accessible from anywhere in the application, therefore it should implement the singleton design pattern. In this documentation we will call this root element FrameworkController.

Usually the name of the root element is constructed as follows : xxxController where xxx can be the project name or any descriptive name.

Usually the FrameworkController contains the load and unload methods to initialize the model at application startup and finalize it at the application shutdown. Load and Unload methods must be called at the right time by the bootstrapper.

The bootstrapper has two virtual methods Load and Unload which can be overridden if necessary. See Initialization and the finalization of application services chapter in Starting a new application.

public sealed class FrameworkController
{
    private FrameworkController()
    { }
    public static FrameworkController Instance
    {
        get { return _instance; }
    }
    private static readonly FrameworkController _instance = new FrameworkController();

    public void Load()
    { }
    public void Unload()
    { }
}