MVC multi-tenancy in ASP.NET MVC

1. When our application starts, initialize our top level IoC container. We will use a separate StructureMap registry for our core dependencies (the ones needed to load and initialize our tenants and their containers)
2. Next we need to load our tenants. In Zack's example he is using StructureMap's assembly scanning feature to find each concrete tenant. We will provide an ITenantRepository interface so you can decide how to load your tenants - we will start with a static list but you could easily load the tenants from an xml file or use YAML files like Orchard.
3. Once we have our list of tenants we initialize each tenant's container. Each will use the same registry but of course any requests for IApplicationTenant will resolve to the tenant owning the container.
4. Next we new up our tenant selector, passing it our list of of tenants. We also pass it an ITenantResolver, whose job it is to select the appropriate tenant. The default resolver will use the request context (like Zack's example) but can be swapped out for your own implementation or for testing.
5. Finally we pass our tenant selector to our custom controller factory (pretty much the same as Zack's example).

1. 其实对于数据库，或数据存储设计这块，multi-tenancy这个比较多的讨论以下三个方式：

2. Separate Databases - in this architecture each customer's data is stored in a separate database. The databases may all be on the same database server or they could be partitioned across multiple database servers. This approach provides for maximum isolation of customer data. If we were building a hosted application using the Northwind database and had three customers then with this approach we would have three databases - Northwind01, Northwind02, and Northwind03 - and each database would have the same tables, views, stored procedures, and so on. Customer 1's data would all be located in the Northwind01 database, while Customer 2's data would be over in the Northwind02 database.
3. 数据最独立，但如何把整合数据拿出来，平台需要使用跨数据库的访问，会导致一些问题，比如租户之间的交叉的引用，由于基础的东西需要集中存储，一般会有center DB+tenant DB--X
   
4. Shared Databases, Separate Schemas - SQL Server 2005 introduced the concept ofschemas, which offer a way to group a set of tables. With this approach you can have a single database with one schema for each customer. Returning to the Northwind example, with this approach there would be a single database, but there would be three schemas - Customer01Schema, Customer02Schema, and Customer03 schema. Each schema would have the same set of tables, views, stored procedures, and so forth. Customer1's product information would be found in theCustomer01Schema.Products table, whereas Customer2's product information would be stored inCustomer02Schema.Products.

5. select * from Test
   union 
   select * from ContosoSchema.Test

6. 一直没有明白这样的好处是是什么？

7. 
   select * from Test
   union 
   select * from ContosoSchema.Testselect * from Test
   union 
   select * from ContosoSchema.Testselect * from Test
   union 
   select * from ContosoSchema.Testselect * from Test
   union 
   select * from ContosoSchema.Testselect * from Test
   union 
   select * from ContosoSchema.Test

8. Shared Database, Shared Schema - here we have only a single database and a single schema. There would be only oneProducts table. To differentiate one customer's products from another we'd need to add aNorthwindCustomers table that would have a record for each customer and then add aNorthwindCustomerID foreign key to theProducts table (and to the other pertinent tables).

9. 比较常见，但所有的租户基础主表 查询/修改等需要一个KEY ID。比较麻烦，所以有做view的方式：

   Tenant View Filter

   SQL views can be used to grant individual tenants access to some of the rows in a given table, while preventing them from accessing other rows.

   In SQL, a view is a virtual table defined by the results of a SELECT query. The resulting view can then be queried and used in stored procedures as if it were an actual database table. For example, the following SQL statement creates a view of a table calledEmployees, which has been filtered so that only the rows belonging to a single tenant are visible:

   CREATE VIEW TenantEmployees AS
   SELECT * FROM Employees WHERE TenantID = SUSER_SID()

   //Returns the security identification number (SID) for the specified login name.

   select SUSER_SID()
go
SELECT SUSER_SID('sa');
go
select SUSER_SID('ro-PC\administrator')

   ===〉在所有基础表上做出一个虚拟的Views，然后就可以进一步操作了，避免了很多写ID=‘’的SQL语句。明显需要准备很多SQL account吧

   http://msdn.microsoft.com/en-us/library/aa479086.aspx 如之前博文所言，其实多不是新东西，如何看/架构大师还是比程序员高明，但没有程序员经验，架构不出来的/

   Separating tenant data into individual databases is the "premium" approach, and the relatively high hardware and maintenance requirements and costs make it appropriate for customers that are willing to pay extra for added security and customizability. For example, customers in fields such as banking or medical records management often have very strong data isolation requirements, and may not even consider an application that does not supply each tenant with its own individual database.？问题是如何把相关数据搞出来？比如companyID，在平台的数据库中存在租户信息表以及对应的DB名字，但在租户的系统的数据库中不需要租户信息表。

   这次的设计一定要可靠：PlatformDB(就是一个普通的系统，用户角色分类-)  company-tenant（登陆URL进入-可以获得tenantID->可以获取PlatformDB关联的数据）（平台派单功能）

   //如果两系统完全无锋衔接，会增加很多场景，例如派单时候需要先选择--本公司，后考虑平台派单，不如先做成单一的，非集中的入口，操作员控制，后续再做整理。

   There are nearly 350 database tables, hundreds of ASP.NET pages, and several automated backend processes. 后台自动程序，独立数据库是看起来很诱人的方案//

   How many customers do you expect to be using the system?
   • There is a maintenance cost associated with each new database. If you expect hundreds or thousands of customers then aSeparate Databases architecture is probably going to be prohibitive from a maintenance standpoint.

   http://scottonwriting.net/sowblog/archive/2009/08/19/163361.aspx ---

   SQL Server model database //我们真的需要数据库工程师了么？

   技术问题的抽象:

   high level requirements are:

   • Provide a single endpoint (controller action) for displaying widgets
   • Provide a generic way of configuring widgets
   • Find a way of creating complex widgets that can load their own data without violating MVC principles
   • Allow widgets to be dropped into our app as assemblies without requiring an additional configuration.

   NH & code first EF// make decision just before you are familar with one of them. 往往能够影响你对技术选项判断的，就是学习成本以及项目压力...

   思考所有关联领域/技术积累，可能方案等等：

10. As previously mentioned, RenderAction to display the plugin
11. Dynamic view models
12. MVC’s EditorFor template helper for widget configuration
13. Entity Framework Code First (although I’m likely going to switch to NH for reasons I will explain).
14. StructureMap to provide the “pluggable” aspects of the application and inject dependencies into our widgets. 。。