The root interface for accessing a Spring.NET IoC container.
For a list of all members of this type, see IObjectFactory Members .
|AbstractApplicationContext||Partial implementation of the IApplicationContext interface.|
|AbstractXmlApplicationContext||Convenient abstract superclass for IApplicationContext implementations that draw their configuration from XML documents containing object definitions as understood by an XmlObjectDefinitionReader.|
|GenericApplicationContext||Generic ApplicationContext implementation that holds a single internal DefaultListableObjectFactory instance and does not assume a specific object definition format.|
|StaticApplicationContext||IApplicationContext that allows concrete registration of objects and messages in code, rather than from external configuration sources.|
|WebApplicationContext||Web application context, taking the context definition files from the file system or from URLs. Treats resource paths as web resources, when using IApplicationContext.GetResource. Resource paths are considered relative to the virtual directory. Note: In case of multiple config locations, later object definitions will override ones defined in earlier loaded files. This can be leveraged to deliberately override certain object definitions via an extra XML file.|
|XmlApplicationContext||An IApplicationContext implementation that reads context definitions from XML based resources.|
|AbstractAutowireCapableObjectFactory||Abstract IObjectFactory superclass that implements default object creation.|
|AbstractObjectFactory||Abstract superclass for IObjectFactory implementations.|
|DefaultListableObjectFactory||Concrete implementation of the IListableObjectFactory and IObjectDefinitionRegistry interfaces.|
|StaticListableObjectFactory||Static factory that permits the registration of existing singleton instances.|
|WebObjectFactory||Concrete implementation of IListableObjectFactory that knows how to handle IWebObjectDefinitions.|
|XmlObjectFactory||Convenience extension of DefaultListableObjectFactory that reads object definitions from an XML document or element.|
This is the basic client view of a Spring.NET IoC container; further interfaces such as IListableObjectFactory and IConfigurableObjectFactory are available for specific purposes such as enumeration and configuration.
This is the root interface to be implemented by objects that can hold a number of object definitions, each uniquely identified by a String name. An independent instance of any of these objects can be obtained (the Prototype design pattern), or a single shared instance can be obtained (a superior alternative to the Singleton design pattern, in which the instance is a singleton in the scope of the factory). Which type of instance will be returned depends on the object factory configuration - the API is the same. The Singleton approach is more useful and hence more common in practice.
The point of this approach is that the IObjectFactory is a central registry of application components, and centralizes the configuring of application components (no more do individual objects need to read properties files, for example). See chapters 4 and 11 of "Expert One-on-One J2EE Design and Development" for a discussion of the benefits of this approach.
Normally an IObjectFactory will load object definitions stored in a configuration source (such as an XML document), and use the Spring.Objects namespace to configure the objects. However, an implementation could simply return .NET objects it creates as necessary directly in .NET code. There are no constraints on how the definitions could be stored: LDAP, RDBMS, XML, properties file etc. Implementations are encouraged to support references amongst objects, to either Singletons or Prototypes.
In contrast to the methods in IListableObjectFactory, all of the methods in this interface will also check parent factories if this is an IHierarchicalObjectFactory. If an object is not found in this factory instance, the immediate parent is asked. Objects in this factory instance are supposed to override objects of the same name in any parent factory.
Object factories are supposed to support the standard object lifecycle interfaces as far as possible. The maximum set of initialization methods and their standard order is:
On shutdown of an object factory, the following lifecycle methods apply:
Assembly: Spring.Core (in Spring.Core.dll)