ASP.NET Application Life Cycle

Posted 2020-09-24 foreach

 

 

The table in this topic details the steps performed while an XAF ASP.NET application is running.

Note

Currently, only the steps that are performed until the main page is shown are detailed.

Stage	Description	Ways to Interfere
Application is requested	See ASP.NET Application Creation and Initialization.
An end-user is authenticated	See User Authentication using a Logon Window in ASP.NET Applications and User Authentication Without a Logon Window in ASP.NET Applications.
Start-up Pop-up Window Show Actions are executed.	A collection of Pop-up Window Show Actions is populated by the Actions that are registered as start-up Actions in modules used by the application. For instance, the ChangePasswordOnLogon represents a start-up Action. A pop-up window is displayed for each Action after an end-user has executed or canceled the previous Action.	To register an Action as a start-up, override the GetStartupActions method in your module class. Return a list of Pop-up Window Show Actions in this method (see PopupWindowShowAction).
Start-up window is shown	See Show the Main Page in ASP.NET Applications.

 

 

ASP.NET Application Creation and Initialization

 

This topic details the steps performed after an end-user has requested an XAF ASP.NET application, until the moment the main XAF objects, like the WebApplication, are created and initialized.

In the following image, you can see that the entire process of the application initialization can be divided into five steps.

 

The table below describes all these steps in detail.

Stage	Description	Ways to Interfere
A Web Application is created	At the beginning of a request that begins a new session, an instance of the WebApplicationclass is created. This is performed by the Global.Session_Start method, automatically generated in your ASP.NET application project.
Initial Application Initialization	A newly created application is initialized. The settings that are specified in the configuration file‘s appSettings section are read to the application:
	The XafApplication.TablePrefixes property is set to the value assigned to the TablePrefixeskey in the configuration file.	If it is not necessary for you to set table prefixes in the configuration file, you can do it in code. To do this, set the TablePrefixesproperty after an application object has been created, but before its XafApplication.Setup method is called.
	The location to be used to store the Model.User.xafml file is specified by the UserModelDiffsLocation key.
	The location to be used to store the application‘s Log file is specified by the TraceLogLocation key.
Application Initialization by the Designer	Then, the application is initialized by the values specified in the Application Designer. This is performed by the InitializeComponent method, automatically called in the WebApplication constructor.
	The XafApplication.Modules collection is populated by the modules added to the Modulessection in the Designer. Each module is set up. This means that the current WebApplication.Instance is assigned to the ModuleBase.Application property.	If you need to add a module that is not registered in the Toolbox, and thus cannot be added via the Designer, use one of the following approaches. Specify the required module name(s) in the application project‘s configuration file. Pass this string as a parameter of the XafApplication.Setup method in the Global.Seesion_Start method. Add this module to the module that is contained in your solution. To do this, use the ModuleBase.RequiredModuleTypes collection. To see code samples of both these approaches, refer to the Ways to Register a Module topic. You can perform custom actions with a module, in addition to setting the Application object. To do this, override the module‘s ModuleBase.Setup method.
	The XafApplication.Connection property is set to the object of the type specified in the Designer‘s Connection section. The connection string is specified in the Properties grid, when the Connection section is selected.	You can avoid the use of the Designer applying one of the following techniques. Specify the connection string in the application project‘s configuration file. Assign this string to the XafApplication.ConnectionStringproperty (see this property‘s description). Set the XafApplication.Connection and/or XafApplication.ConnectionString property before the XafApplication.Setup method is called.
	The XafApplication.Security property is set to the object of the type specified in the Designer‘s Security section. The authentication strategy to be used by the Security System is specified in the same section. The User type to be used by the Security System is specified in the Properties grid, when the Security section is selected.	The eXpressApp Framework supplies two security system types: SecuritySimple and SecurityComplex. You can set them using the Application Designer. If you need to use a security of a custom type that implements the ISecurity interface, create and assign it to the XafApplication.Security property in code, before the XafApplication.Setup method is called. If you need to use a custom authentication strategy or a custom User type, initialize them and the XafApplication.Security property, before the XafApplication.Setup method is invoked. If you don’t initialize a security system via the Application Designer or in code, a SecurityDummy will be used. This security type allows all operations with all types of objects. That‘s why the presence of the security system is invisible when you run an application.
	The XafApplication.ApplicationName property is set to the value that is specified in the Properties grid when the Application section is selected.	You can assign a custom value to the XafApplication.ApplicationName property in code - before the XafApplication.Setup method is called.
The application instance is stored in the current Session.	An instance of your WebApplication component is assigned to a Session variable named SessionApplicationVariable. This is performed via the WebApplication.SetInstance method invoked in the Global.Session_Start method that is automatically generated in your ASP.NET application project. When the Session is abandoned or times out, the WebApplication instance is disposed of.
Application Initialization by the Setupmethod	The XafApplication.Setup method is called. This is performed by the Global.Session_Startmethod, automatically generated in your ASP.NET application project. There are several overloads of the Setup method. By default, the method without parameters is called. It leaves the properties that are already initialized as they are and proceeds with the initialization process using default values:	You can call the Setup method with the required parameters, dependent on what objects you need created in a custom way. However, we recommend that you use the approaches presented above, instead.
	A default Object Space Provider (see XafApplication.ObjectSpaceProvider) is created using a connection string specified by the XafApplication.ConnectionString property.	To create a custom Object Space Provider, subscribe to the XafApplication.CreateCustomObjectSpaceProvider event before the Setupmethod is called. Alternatively, pass the required ObjectSpaceProvider object using the Setup method as a parameter. You can override the XAFApplication.CreateDefaultObjectSpaceProvider method in your WebApplication class descendant. This method is called when none of the custom approaches to pass an Object Space Provider are used. This method creates an instance of a built-in ObjectSpaceProviderThreadSafe class. You can return an instance of another class that implements the IObjectSpaceProvider interface.
	A default Controllers Manager (ControllersManager) is created. This object contains a collection of all the Controllers that are declared in the registered modules.	You can override the XAFApplication.CreateControllersManager method in your WebApplication class descendant. This method creates an instance of the built-in ControllersManager class. You can return an instance of another class.
	A default Modules Manager (ApplicationModulesManager) is created. This object contains the Modules collection along with the modules to be used by the application. This collection is populated by modules from the XafApplication.Modules collection. In addition, the SystemModule is added as a default module.	You can override the XAFApplication.GetDefaultModuleTypes method in your WebApplication class descendant. This method creates an instance of the built-in ApplicationModulesManager class. You can return an instance of another class. In addition, you can override the GetDefaultModuleTypes method to return modules to be added to an application by default, in addition to the System module.
	A default Application Model Differences Store (FileModelStore) is created.	If you need to store Application Model‘s differences in a place that is different from an XafML file, you can create a custom Application Model Differences Store. To do this, subscribe to the XafApplication.CreateCustomModelDifferenceStore event before the Setupmethod is called, or override the CreateModelDifferenceStoreCore method in your WebApplication class descendant.
	The Object Space Provider and Controllers Manager are assigned to the application‘s corresponding properties: XafApplication.ObjectSpaceProvider and ControllersManager.	Subscribe to the XafApplication.SettingUp event, to customize objects to be assigned to the application object. Use the event handler‘s parameters to access the required objects.
	The modules from the Modules Manager‘s Modules collection are added to the XafApplication.Modules collection of the current application, since at this step, the latter collection includes the modules that are only added via the Application Designer.
	The Application Model Manager (ApplicationModelsManager) that manages the creation and initialization of the Application Model is instantiated.
	The Application Model is created. Internally, the Application Model has a layered structure. So, at first, the actual layers that comprise the Application Model internals are created:
	The zero layer of the Application Model is created. Initially it is empty. It is filled with data on demand, during an application‘s life cycle.	To extend the Application Model, pass the required model interfaces via the application modules‘ ModuleBase.ExtendModelInterfacesmethods. Alternatively, you can implement the IModelExtender interface in Controllers. To modify existing node generators, implement a generator updater and register it via the ModuleBase.AddGeneratorUpdaters method of a module. For details, refer to the Extend and Customize the Application Model in Code topic.
	A layer for each module used in the application is created. This layer is filled with data from the Model.DesignedDiffs.xafml file that contains Application Model differences made in a particular module.	To modify this layer‘s data, modify the required module‘s XafML file. This can be done, for example, via the Model Editor.
	A layer for the application project is created. This layer is filled with data from the Model.xafml file that contains Application Model differences made in the application project.	To modify this layer‘s data, modify the application project‘s XafML file. This can be done, for example, via the Model Editor.
	Second, all the created layers are wrapped with the master layer.	The master layer does not contain any information itself. It serves as a proxy to all other layers. Usually, when you access the Application Model, you deal with the master layer.
	The final state of the Application Model is assigned to the XafApplication.Model property. Note that in ASP.NET Web XAF applications, the common part of the Application Model is represented by a single instance, shared between the users.	Subscribe to the XafApplication.SetupComplete event, to create extra objects (helpers, extractors, etc.) after the application has been entirely initialized.

Note

If the current Session has expired, it is restarted, which leads to the re-creation and re-initialization of the WebApplication object.