Composite Web Application Block - WebConfigModuleInfoStore and WebModuleEnumerator in Web Client Software Factory
by David Hayden ( Florida .NET C# SQL Server Developer ), Filed: Web Client Sofware Factory
The Web.config files in your Web Client Software Factory applications play a huge role during application startup. During startup, the Composite Web Application Block reads all the Web.config files throughout your website to create a list of all Modules ( Business Modules and Foundation Modules ) and their dependencies. The modules registered in the Web.config files then get initialized and loaded into the web application.
Web.Config Module Information
By default, you will usually find the following module configuration information in the root Web.config file in you ASP.NET Application:
<compositeWeb>
<modules>
<module name="Shell" assemblyName="Shell" virtualPath="~/" />
</modules>
</compositeWeb>
The root module by default will usually contain all the Foundation Modules in your application. Foundation Modules are modules not associated with web pages and user interface logic. Foundation modules are typically global services consumed by your Business Modules, which are associated with web pages and user interface logic.
Registered in the root Web.config file is the Shell Foundation Model that is generated automatically by the Web Client Software factory. The module information in the root Web.config file will be read by the Composite Web Application Block during application startup.
As you create Business Modules using the Web Client Software Factory, directories will be added to the root directory that also contain Web.config files containing Business Module Information:
<compositeWeb>
<modules>
<module name="Customers" assemblyName="Customers"
virtualPath="~/Customers">
<dependencies>
<dependency module="Shell" />
</dependencies>
</module>
</modules>
</compositeWeb>
The Business Modules and their dependencies will also be initialized and loaded by the Composition Web Application Block during application startup.
Recursively, this discovery of Web.config files and registered Modules will occur during application startup until all modules and their dependencies are found in all directories of the web application.
WebConfigModuleInfoStore and WebModuleEnumerator
If you take a peek at the Composite Web Application Block Source Code that comes with the Web Client Software Factory, two classes are basically responsible for the discovery and tabulation of module information in the web application: WebConfigModuleInfoStore and WebModuleEnumerator.
WebConfigModuleInfoStore discovers all the Web.config files in the applications and reads all the Module Configuration Sections. WebModuleEnumerator parses the configuration information and returns an array of IModuleInfo[] that is used by the Composite Web Application Block to initialize and load all the Business and Foundations Modules.
public class WebModuleEnumerator : IModuleEnumerator
{
private IModuleInfo[] _modules;
private IModuleInfoStore _store;
[InjectionConstructor]
public WebModuleEnumerator([ServiceDependency]
IModuleInfoStore store)
{
_store = store;
}
/// <summary>
/// Gets the list of modules needed by the application.
/// </summary>
/// <returns>An array of <see cref="IModuleInfo"/>.</returns>
public IModuleInfo[] EnumerateModules()
{
// ...
}
// ...
}
You Choose - 1 or Many Web.config Files
Knowing this bit of information about the Web Client Software Factory empowers you a bit. You can choose to consolidate all your Module Information into a single Web.config file in the root directory of your ASP.NET Application or accept the default used by the Web Client Software Factory, which is to have each Business Module registered in its own Web.config file in its associated directory off the root directory. Foundation Modules are typically registered in the root Web.config along with the Shell Module.
What is really nice about having multiple Web.config files is that you have a plug n' play environment where new Business Modules are discovered and registered by the ASP.NET Application on-the-fly during application startup. This means you can independently work on Business Modules across your development team and have them automatically discovered and registered with a quick XCOPY to the development, staging, and production web servers.
You don't need to centrally register modules and worry about your Module Information being lost or overwritten. The Composite Web Application Block will recursively read through the entire ASP.NET Application to discover all modules and their dependencies.
Conclusion
Don't forget to check out all my Web Client Software Factory Tutorials. Enjoy this stuff!
Source: David Hayden ( Florida .NET C# SQL Server Developer )
Filed: Web Client Sofware Factory