How to: Store Model Differences in Database

This example illustrates how to store user UI settings (so-called model differences) in the application database instead of the file system (in Windows Forms applications) and session (in ASP.NET appications).

By default, an XAF Windows Forms application stores user customizations of the Application Model in the Model.User.xafml file, located in the application's directory. The application's model difference storage is also file-based (Model.xafml file). These two layers are superimposed when running an application. All model-related changes made by the end-user (e.g., layout customizations) are saved to the Model.User.xafml. The potential disadvantages of this default approach are:

- The Model.xafml file is not shared (except when the application is deployed to the terminal server). So even if this file is modified by an administrator, it must be re-deployed to all users to take effect;

- Since model differences are stored in a plain XML format, anyone who has access to XAFML files can easily influence the work of the application. So, it is possible to affect a critical setting that will cause the application to stop functioning;

- Several users sharing the same copy of the application cannot have individual customizations. This can be resolved by changing the user differences file location to the user profile folder (by setting the UserModelDiffsLocation key value to the CurrentUserApplicationDataFolder in the application configuration file). However, the problem persists if users are working under the same system account.

By default, an XAF ASP.NET application stores user customizations of the Application Model in the session. The global application model difference storage is file-based (Model.xafml file located in the web application folder). These two layers are superimposed when running an application. All model-related changes (e.g., columns order and visibility in List Views, dashboard layouts, etc.) made by end-users are saved to cookies. If a user accesses the ASP.NET application via several different devices (desktop, laptop or tablet), settings are not synchronized.

Generally, you can use the default storage in most scenarios. However, the disadvantages listed above become critical if you wish to give more power to application administrators and enhance application security. This example provides a solution that eliminates all these disadvantages. The main idea is to store all model differences in the application's database. Follow the instructions below to use the database model difference storage in your XAF application.

Build the DatabaseUserSettings.dll Assembly

- Download the solution attached to this example.

- Upgrade the downloaded solution up to your currently installed version of DXperience. Use the Project Converter utility for this purpose.

- Open the converted solution in Visual Studio. Switch to the Release configuration and build the DatabaseUserSettings project (this project contains the module that we are going to use).

- Copy the DatabaseUserSettings.dll assembly to an appropriate location in your development workstation.

Add the DatabaseUserSettings Module to Your XAF Solution

- Open your XAF solution that will use the DatabaseUserSettings module.

- Add the DatabaseModelStrorage.dll reference to the platform-agnostic module project.

- Right-click the Module.cs file and choose View Code. Modify the module's constructor in the following manner.

[C#]
publicsealedpartialclassMySolutionModule:ModuleBase{publicMySolutionModule(){InitializeComponent();this.RequiredModuleTypes.Add(typeof(DatabaseUserSettings.DatabaseUserSettingsModule));}}

Note:Alternatively, you can add the DatabaseUserSettings in the Module Designer.But you should register the DatabaseUserSettingsModule toolbox item first (see How to: Add Items to the Toolbox).

Now you can logon using different credentials and apply different customizations for each user. For instance, you can change the active skin for each user. Different users will have different skins selected after the application is restarted. Users should have read/write access to the XPUserSettings and XPUserSettingsAspect persistent types (these types are provided by the DatabaseUserSettings module and are used to store model differences).

The Configurator Account

To manage default model settings applied to users, a special Configurator account can be used. All customizations made by Configurator in the Model Editor or directly in the UI will be stored to the shared Application Model layer. To create such an account, do the following.

- Add a Role named "Configurator" (this name is declared by the DatabaseUserSettingsModule.ConfiguratorRoleName constant).

- For the added Role, grant full access to the XPUserSettings and XPUserSettingsAspect persistent types and read access to the UserName member of the type that represent users in your application (SecuritySystemUser by default). Alternatively, you can simply mark this role as administrative (see SecuritySystemRoleBase.IsAdministrative).

- Add a User named "Configurator" (this name is declared by the DatabaseUserSettingsModule.ConfiguratorUserName constant), and associate this user with the "Configurator" role.

Refer to the Updater.cs file to see the code.

The ManageUserSettings Action

The Configurator user has access to the ManageUserSettings Action. This Action of the PopupWindowShowActiontype is provided by the ManageUserSettingsWindowController Controller implemented in the DatabaseUserSettings module. This Action is intended to import a user setting from one user to another.

See Also
Core - Provide an easy way to store administrator and user model differences in a custom store (e.g., in a database)
A reusable XAF module for storing model settings in the database (security system type insensitive!)

ImportantNotes
1. Be aware of the following issue with this example: User settings may be duplicated/overridden under certain circumstances after merging configurator and user settings applied to the same element
2. This example solution is not yet tested in the middle-tier and SecuredObjectSpaceProvider scenario and most likely, it will have to be modified to support its specifics.
3. This example solution is not yet tested with custom fields.