序文
最後の2週間は、私はEFコアマルチテナントの使用について書かれたエッセイを行い、EF自動移行に関するいくつかの詳細を示しています。
エッセイのこのシリーズは、このコードの最適化の一部と作られたクラスライブラリをしたいです。
私は良い仕上がりと抽象を持っており、仕上げのアイデアをご紹介したいと考えていました。しかし、後にいるかのように、ここでのコードの量は、あまりにも、何も言わないことができることを見出しました。
このエッセイは、説明しますので、このライブラリ関数の使用を達成することができます。
マルチテナントの紹介
エッセイのシリーズを紹介するよると、今、主に3つのモードがサポートされています。彼らは、次のとおりです。表は、データベース内のスキーマとデータで区切られています。
サポートされているデータベースはMySQLとのSQLServerを持っている、と私はまた、Postgreを再構成したときに、それに統合されます。
このリファクタリングを通じ、コードの構造は、以前の記事、デモレベルでの滞在と同じようではありません。
コードの変更後は、私の目標は、個別の読み取りと書き込みに進化し、最も基本的なマルチテナント、マルチテナントをサポートすることです。
典型的なモード
分離の1.データベースモードはまた、ライブラリProductテーブルをそれぞれ有するDbContext 3異なるデータベースに接続分かるであろう。
あなただけDbContextを見ることができます。表2の分離モードでは、同時に、データベースに接続する製品のテーブルと同じ構造を持つデータベース3が、その名前は区別さ接頭辞です。
3.スキーマ分離モード、データベースに同時に接続のみDbContext、製品テーブルスキーマを有しながらスキーマ3,3を持つデータベースがあります
マルチテナントのシナリオバリアントで
データベースの構造の採用により、我々は、データベースを知ることができ、スキーマとテーブルが階層関係です。Nスキーマ、スキーマnの表のデータベース。
混合モードのデータベースとテーブル、データベースやスキーマの混合モード、混合モードおよび表スキーマ、スキーマおよびデータベースのテーブルと混合モード：このレベルの特性により、我々は4つのモードの変形に彼を置くことができます
一般的に、しかし、後でモード2は、より多くの圧力データベースに同時にあり、ハードウェア/データベースインスタンス態様、データの量が増加し続ける場合、別のデータベースへのデータの必要性の最終的に複数の単離されません。
1. 数据库和表混合模式，可以看到DbContext里面有3个连接分别连接到3个Store Container的数据库，里面各自存在3个结构相同的数据表。
通过3个Store container，共有9个租户
2. 数据库和Schema混合模式，一个DbContext里面有3个连接连接到3个Store Container的数据库，里面各自有3个Schema，每个Schema下都有一个结构相同的数据表
通过3个Store Container， 共有9个租户
转变为读写分离
在目前的系统中，读写分离是的应用更加广泛。通过下面的图看出，同一个DbContext下有3个连接分别链接到不同的数据库。数据库里见面有完全相同的表
其中一个是主库，2个是从库。
如果对比我们典型的多租户模式，其实是非常类型的，显而易见他们之间是可以互相演变的。事实上我项目中其实就是通过多租户模式下演变成读写分离的。
读写分离&多租户图解
我们这里先看看下图中的结构。其实这里的图就是我整个系列的主要流程。其中有几个关键步骤
A. Http Request通过asp.net core的中间件或者拦截器。通过AOP的模式，通过http header和url等， 调用Tenant Generator。
B. Tenant Generator根据调用的接口参数，获取这是哪一个租户和API的操作类型（读或写），并且讲租户信息和操作类型返回
C. Connection Resolver接收租户和操作信息的组合，通过配置文件或配置中心获取具体的连接字符串，并且把连接字符串作为参数传入到DbContext的构造函数。
D. Db Context利用接收到连接字符串，通过EF core的封装，自动连接到不同的数据库。
注：租户和操作信息的组合，拿store1 & read的组合举个例子，他的配置的连接字符串的键值是 store_read。同理 store2 & write 的键值就是store2_write
通过上图的结构，其实读写分离在我们的封装下，也是能轻而易举的实现的。估计读者来到这里会发现有3个关键组件是需要用户自定义才能完成。
分别是中间件或拦截器、Tenant Generator和Connection Resolver。他们3者需要同时维护和使用一个TenantInfo。
总结
好了，来到这里已经是本文的结束。是的，本文并没有贴出任何代码，仅仅是一个介绍的随笔。
本文的目的是，让阅读者对多租户和读写分离模式有抽象的概念，利用图和抽象对象尽量描述出这个模式实现下的关键是什么。
从系列的第一篇开始，是对多租户的入门，之后的随笔是对该模式的深入理解和加深实施办法。
经过了前面几篇文章的基础，通过本文的抽象概念和之前的实施代码进行融合，从而希望读者能够系统地了解到分库分表。
关于代码
由于之前的代码都只停留在Demo阶段，所以后来我重构了，并且使用了新的Github Repository.
并且我把如何使用的示例代码都放在了同一个Repository下。
请到这个github地址下获取重构的代码：
https://github.com/woailibain/kiwiho.EFcore.MultiTenant
对于这份代码，由于我也是在最近2天写的，只做了基础功能测试，并且事例代码量有限，我会随着系列文章的进行中，不断补充事例代码也同时修复bug。
其中事例代码，我会包含今天讲到的所有内容。并且我在编写example的同时，也会发文写关于怎么使用，为什么这样使用的详细。
往期文章
如果读者是首次阅读本系列，建议阅读系列的其他文章。因为本文是对前文的总结
Asp.net core下利用EF core实现从数据实现多租户（1）
Asp.net core下利用EF core实现从数据实现多租户（2） : 按表分离
EF core (code first) 通过自定义 Migration History 实现多租户使用同一数据库时更新数据库结构
EF core (code first) 通过自动迁移实现多租户数据分离 ：按Schema分离数据