Measure the test taker's knowledge about the multi-tenant structure and the tenants of the ABP framework.

Measure the test taker's knowledge about the multi-tenant structure and the tenants of the ABP framework.

(This article is also published in my public account "dotNET daily excellent article". Welcome to the QR code on the right to follow it .)

Question: The ABP framework provides excellent support for multi-tenant scenarios. It has a built-in multi-tenant processing mechanism. Let's analyze this feature in depth today.

Recently, an SaaS was developed based on the ABP framework (ASP. NET Boilerplate. Therefore, we may share some of the following articles on the ABP from time to time. Today, we will introduce the features of the support for multi-tenant resources provided by ABP.

Overview

ASP. NET Boilerplate is a new starting point for developing modern WEB applications with best practices and popular technologies. It aims to become a general WEB application framework and project template. Based on the classic layered architecture of DDD, ASP. NET Boilerplate implements many DDD concepts (but does not implement all DDD concepts ). In addition to the architecture design and code writing, the document is also comprehensive and detailed (this is the basis for a development framework to be selected by technology ). In particular, many enthusiastic domestic friends have also organized Chinese documents and documents, such as Guo Yangming's series of articles (http://www.cnblogs.com/mienreal/p/4528470.html) and the Chinese Document (https://github.com/ABPFrameWorkGroup/AbpDocument2Chinese) of the ABC framework group ).

Multi-tenant

SaaS usually requires multi-tenant support. Wikipedia explains multi-tenant: Software multi-tenant refers to a software architecture where the instance software runs on a server, but there are multiple tenants. A tenant is a group of software instances that share a public user's access permissions. In a multi-tenant architecture, software applications are designed to provide dedicated instances for each tenant, including data, configuration, user management, individual tenant functions, and non-functional attributes. Multi-tenant and multi-instance architecture, independent software instances represent different tenant operations.

Multi-tenant generally involves the following scenarios:

• Multi-deployment-multi-database: An application instance is deployed independently for each tenant, and each instance corresponds to a database. This is not really a multi-tenant, but it is a compromise for legacy systems that do not consider multiple tenants to adopt this deployment method.
• Single deployment-multiple databases: there is only one application instance, and each tenant connects to different databases.
• Single deployment-single database: The application instance and database are both one. You can add a data table similar to TanantId or EnterpriseId to isolate the data.
• Single deployment-mashup Database: one application instance, but one or more databases can be used as needed. For example, if a free user is put into a database, advanced users have their own databases.
• Cluster deployment-single/multiple/mixed databases: The logic instance of the application is still one (only for high availability and performance deployment as a cluster ), then the corresponding database can be single, multiple, and mashups.

In addition to tenant-specific databases, a global database (called a host database) may be required to store configuration data on a global scale. In a single database, host data may be put together with tenant data (or even in the same data table ).

Support for multi-tenant

All the multi-tenant scenarios mentioned above can be supported in the ABP. You only need to enable multi-tenant in the startup configuration.

Configuration.MultiTenancy.IsEnabled = true; 

Of course, the most common scenario is probably single deployment-single database. Therefore, the embedded TenantId Processing Mechanism (implemented through the interface IMustHaveTenant or IMayHaveTenant) is provided in the ABP ). The entity implements the IMustHaveTenant interface and contains a TenantId attribute that cannot be empty, which means that the database must be isolated based on TenantId. The IMayHaveTenant interface is implemented and contains a TenantId attribute that can be empty. When TenantId is empty, it indicates that the data belongs to the host range. If it is not empty, it indicates that the data is isolated based on tenants.

In contrast, an IAbpSession in a special encapsulation is used to obtain the current TenantId for the user. If the user logs on to the system as the host, the TenantId is empty; otherwise, the Id of the tenant where the user is logged on.

Can read data under multiple tenants

You can not simply add a TenantId attribute to your object class, but identify the IMustHaveTenant or IMayHaveTenant interface and use the data filtering mechanism (there are different implementation methods based on the underlying ORM) when you read data, the data is automatically filtered Based on the TenantId in the current AbpSession. That is to say, when you query and read data, it is unnecessary to write code such as "where item. TenantId = AbpSession. TenantId.

Note that if the entity implements the IMustHaveTenant interface and AbpSession. when TenantId is null (host user), the data obtained is owned by all tenants unless you explicitly filter the data. In the case of IMayHaveTenant, when AbpSession. TenantId is null, the data of the host user is obtained.

Write Data in Multi-tenant

In multi-tenant scenarios, Data Writing also uses interception mechanisms (such as rewriting the SaveChanges method of DbContext) to automatically set the TenantId attribute for your object, whether you are using IMustHaveTenant or IMayHaveTenant. Although the official documentation recommends that you always set TenantId when creating an object, especially when using IMayHaveTenant (this is also the only place that the abp user needs to relate to this attribute ). However, in my personal opinion, the reason for using the framework is to make the encoding simple, so I still prefer to recommend that you do not explicitly set TenantId.

Change the tenant

At last, you can switch tenant (including switching between tenants and hosts) in the code ). Some of the best practices for switching tenants are also detailed at the end of the official multi-tenant document (http://www.aspnetboilerplate.com/Pages/Documents/Multi-Tenancy.