<ABP framework> Settings management, and abp framework settings Management
Document directory
Content of this section:
- Introduction
- Define settings
- Setting scope)
- Override setting Definition
- Get Setting Value
- Modify settings
- About Cache
Introduction
Each application must store some settings and use them somewhere in the application. ABPS provides a powerful foundation for storing/retrieving application, tenant, and user-level settings, both on the server and on the client.
One setting is a name-value string, which is usually stored in the database (or other sources ). We can convert a value that is not a string class into a string and store it.
About ISettingStore
To use the setup system, you must implement the ISettingStore interface. Although you can implement it in your own way, it has been fully implemented in the module-zero project. If you do not implement it, the settings will be read from the configuration file (web. config or app. config), but the settings cannot be modified. Similarly, scope cannot work.
Define settings
Before using the settings, you must first define the settings. The ABP is designed to be modular. Therefore, different modules can have different settings. A module defines its settings and creates a class that inherits from SettingProvider. The following is the sample code for setting the Supplier:
public class MySettingProvider : SettingProvider{ public override IEnumerable<SettingDefinition> GetSettingDefinitions(SettingDefinitionProviderContext context) { return new[] { new SettingDefinition( "SmtpServerAddress", "127.0.0.1" ), new SettingDefinition( "PassiveUsersCanNotLogin", "true", scopes: SettingScopes.Application | SettingScopes.Tenant ), new SettingDefinition( "SiteColorPreference", "red", scopes: SettingScopes.User, isVisibleToClients: true ) }; }}
The GetSettingDefinitions method returns the SettingDefinition object set. The SettingDefinition class constructor has some parameters:
- Name (required): A setting must have a unique Name within the system range. It is best to define it as a constant rather than a variable string.
- Default value: There is a Default value, which can be null or "".
- Scope: A setting should have its Scope (see below ).
- Display name: a localized name string displayed on the UI.
- Description: a localized Description string displayed on the UI.
- Group: used only on the UI, not in settings management, for Group settings.
- IsVisibleToClients: Set to true to make the settings on the client available.
- IsInherited: whether this setting is inherited by tenants and users (see "set scope ").
- CustomData: Set a user data for this definition.
After creating a set supply, we should register it for our module in the pre-initialization method.
Configuration.Settings.Providers.Add<MySettingProvider>();
The configuration provider is automatically registered with the dependency injection. Therefore, a configuration provider can inject any dependencies (such as a repository) for setting definitions for other sources.
Setting scope)
In the SettingScopes enumeration, there are three set ranges (or levels ):
- Application: Set an Application scope for independent user/tenant settings. For example, we can define a "SmtpServerAddress" to get the Server IP address when sending an email. If this setting has a single value (not changed based on the user), we can define it as the application scope.
- Tenant: if the application is multi-Tenant, we can define the settings of the specified Tenant.
- User: we can use a User-defined setting to store/obtain the value specified by each User.
SettingScopes enumeration has the Flags feature, so we can use multiple ranges (levels) to define a setting.
The Set range is inherited by default (unless isInherited is set to false ). For example, we define a setting range of "Application | Tenant | user" and then try to get the set current value:
- If it is defined (rewritten) as a user, we get the value of a specific User.
- If not, if it is defined (rewritten) as tanant, we will get the value of a specific Tenant.
- If not, if it has been defined, we get the Application value.
- If not, we get the default value.
The default value may be null or "". We recommend that you provide the default value for the setting as much as possible.
Override setting Definition
Context. Manager can get a setting definition and modify its value. In this way, you can operate the setting definition of the dependent module.
Get Setting Value
After defining a setting, we can get its current value on the server and client.
Server
ISettingManager is used to perform setup operations. We can inject and use ISettingManager anywhere in the application. ISettingManager defines many methods for getting a set value.
The common method is GetSettingValue (or GetSettingValueAsync exception) to obtain the current value set based on the Application, Tenant, User (as described earlier). For example:
//Getting a boolean value (async call)var value1 = await SettingManager.GetSettingValueAsync<bool>("PassiveUsersCanNotLogin");//Getting a string value (sync call)var value2 = SettingManager.GetSettingValue("SmtpServerAddress");
GetSetrtingValue has generic and abnormal versions, as described above. Of course, you can also obtain a set value or a list of all values of a specified tenant or user.
Because ISettingManager is widely used, some special base classes (such as ApplicationService, DomainService, and AppController) have a SettingManager attribute. If you inherit from these classes, you no longer need to explicitly inject ISettingManager.
Client
If you set IsVisibleToClicents to true when defining a setting, you can use Javascript on the client to obtain its current value. The abp. setting namespace defines the required functions and objects, for example:
var currentColor = abp.setting.get("SiteColorPreference");
The getInt and getBoolean methods are also available. You can use the abp. setting. values object to obtain all values. Note: If you modify a configuration on the server side, the client will not know the modification unless you refresh the page, reload the settings in some way, and update the settings with manual code.
Modify settings
ISetingManager defines ChangeSettingForApplicationAsync, ChangeSettingForTenantAsync, and ChangeSettingForUserAsync (and synchronous) methods as one application, one tenant, and one user to modify the settings.
About Cache
The settings are managed by the cache settings on the server. Therefore, we should not directly modify the settings by using the warehouse or database update query.