Multi-tenancy with ABP framework

(This article also published in my public number "dotnet daily Essence article", Welcome to the right QR code to pay attention to. )

Preface: ABP Framework provides very good support for multi-tenancy scenarios, built-in multi-tenancy processing mechanism, today we have to thoroughly analyze this feature.

A SAAS has recently been developed on the ABP Framework (ASP. Boilerplate). So the next step might be to share an ABP article from time to time. Today, let's introduce the support features that ABP provides to multi-tenancy.

ABP Introduction

ASP. Boilerplate is a new starting point for developing modern web applications with best practices and popular technologies, and is designed to be a common Web application framework and project template. The ASP. NET boilerplate is based on DDD's classic layered architecture concept, which implements many DDD concepts (but does not implement all DDD concepts). ABP not only has a good architecture design and code writing, but also a comprehensive and informative document (this is the basis for a development framework to be chosen by technology). In particular, many of the country's enthusiastic friends have compiled Chinese materials and documents, such as the Guo Yangming series (http://www.cnblogs.com/mienreal/p/4528470.html) and the ABP Framework Chinese team's Chinese document (https:// Github.com/abpframeworkgroup/abpdocument2chinese).

Multi-tenancy

SaaS is often required for multi-tenant support. Wikipedia's explanation for multi-tenancy is that software multitenant refers to a software architecture where instance software runs on a single server, but there are multiple tenants. A tenant is a group of software instances that share a common user access to specific permissions. Multitenant architecture, software applications are designed to provide each tenant-specific instance including data, configuration, user management, tenant individual functionality, and non-functional attributes. Multi-tenancy and multi-instance architectures, separate software instances represent different tenant operations.

Multi-tenancy generally involves the following scenarios:

• Multi-deployment-Multiple databases: a single set of application instances for each tenant, one database per instance. This is not really a multi-tenancy, but it is a compromise for legacy systems that do not consider multi-tenancy at design time.
• Single deployment-Multiple databases: Only one application instance, each connected to a separate database.
• Single Deployment-Single database: Both application instances and databases are one. Differentiate by adding a similar tanantid or Enterpriseid to the data table that needs to isolate the data.
• Single Deployment-Mashup database: application instance one, but the database can be single or multiple depending on the situation. For example, free users are placed in a database, and advanced users have their own databases respectively.
• Cluster deployment-single/Multi/Mashup database: The logical instance of an application or one (just for high availability and performance deployment as a cluster), then the corresponding database can be single, multiple, and mashup.

In addition, a global database (called the host database) may be required to hold global-scope configuration data, in addition to databases for tenants. In a single database scenario, the host data may be put together with the tenant data (even in the same data table).

ABP support for multi-tenancy

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

Of course, the most common scenario might be a single-deployment-single database, so the ABP has a mechanism for handling Tenantid (implemented via interface imusthavetenant or imayhavetenant). The entity implements the Imusthavetenant interface, which contains a Tenantid attribute that cannot be empty, meaning that the database in it needs to be isolated based on Tenantid. Implements the Imayhavetenant interface, which contains a nullable Tenantid property that represents the data as a host scope when the Tenantid is empty, and is not empty when the data is isolated based on the tenant.

and ABP through a special package of iabpsession to provide users with the current Tenantid access, if the host user login system, then Tenantid is empty, otherwise the user is logged in the tenant's ID.

ABP reads data under multi-tenancy

The ABP does not simply add a Tenantid attribute to your entity class, but by identifying the imusthavetenant or Imayhavetenant interface, using a data filtering mechanism (different implementations depending on the ORM used in the underlying) automatically when you read the data To filter the data based on the Tenantid in the current abpsession. That is, when you query the read data, write "where item." TenantId = = Abpsession.tenantid "Such code is unnecessary.

It is important to note that if the entity implements the Imusthavetenant interface and Abpsession.tenantid is null (that is, the host user), the data obtained is owned by all tenants, unless you explicitly filter it yourself. In the case of imayhavetenant, Abpsession.tenantid is null to obtain the data of the host user.

ABP writes data under multi-tenancy

In the case of multi-tenancy, writing data also through interception mechanisms (such as overriding the DbContext SaveChanges method), you can automatically set Tenantid properties for your entity, whether you use Imusthavetenant or imayhavetenant. Although the official documentation is recommended when creating entities, always display the settings Tenantid, especially when using imayhavetenant (which is also the only place that the ABP user needs to relate this attribute). However, in my personal opinion, the reason for using the framework is to make the coding simple, so I prefer to suggest that you do not have to explicitly set Tenantid.

ABP Switching tenants

Finally, the ABP also provides a series of mechanisms for you to switch tenant in your code (including the switch between tenants and hosts). The final content of the official document on multi-tenancy (http://www.aspnetboilerplate.com/Pages/Documents/Multi-Tenancy) also details some of the best practices for switching tenants.

Multi-tenancy with ABP framework