XAS. System Design

The statements below are recommended though not obligatory.

  • Divide the application's modules (i.e. custom modules) according to their purpose: the modules that implement the business logic and the modules that provide UI. For the fact UI modules of the app are usually not needed for working with XAS, this simple division makes it much easier to prepare the list of modules for XAS integration.
  • When implementing custom modules, inherit module classes from the Xafari.BC.Xas.XasModuleBase provided by the Xafari.BC.Xas.dll assembly. XasModuleBase base class guarantees the custom Controllers deactivation while XAS is running. The fact is that when the administrator starts the XAS, that, in turn, will load the controllers of referenced modules. Since XAS is not intended for business tasks, the execution of business logic and editing business objects are outside its area of responsibility. Therefore, it is advisable to hide for XAS the custom Сontrollers and the ability to edit the business objects. The activity of custom Controllers when XAS is running may lead to undesirable consequences.
  • If custom Controller supposed to stay active even when XAS is working, use Xafari.BC.Xas.EnabledInXasModeAttribute. For instance, all the Controllers that are intended to configure the functionality in XAS mode should be decorated with EnabledInXasModeAttribute.
  • Apply Xafari.BC.Xas.EnabledInXasModeAttribute to all business objects that should be available for editing in Views when XAS is running. By default, XAS mode blocks the ability to modify business objects.  However, it is necessary to allow modifications to some objects when XAS is launched. These objects include security system tables of Users, Permissions, and Roles. If the application has its own implementation of the classes mentioned above, they should be marked with Xafari.BC.Xas.EnabledInXasModeAttribute.