将单数据库 ASP.NET 站点转换为多租户 - 成员资格和角色困境
我正在将单个 SQL DB 网站 (ASP.NET/VB.NET) 更改为多租户应用程序，其中每个客户端都有自己的数据库。
在旧站点中，所有 ASP 角色、登录名和提供程序都指向单个数据库。
现在我们有多个数据库，我想知道最好使用什么架构/技术。 有一个数据库用于配置租户，例如公司名称、各种设置（通常位于 web.config 中）以及租户数据库的连接字符串。
我们应该拥有所有的会员资格吗？ 配置租户的单个数据库中的角色内容或者我们是否拥有会员资格和权限？ 每个租户数据库中的角色？ 选项 2 似乎很棘手，因为我认为 ASP.NET 只喜欢 web.config 中定义的一组 RoleProvider。
有人尝试过这个或者有什么建议吗？
I'm in the process up changing a single SQL DB website (ASP.NET/VB.NET) into a multitenant app, where each client has their own database.
In the old site, all the ASP roles, logins and providers pointed to the single database.
Now we have multiple databases, I'm wondering what would the best architecture/techniques to use. There is one database that configures the tenants, such as the company name, various settings (that would normally be in a web.config) and the connection string to their tenant database.
Should we have all the membership & role stuff in the single database that configures the tenants or do we have membership & roles in each individual tenants database? Option 2 seems tricky because I think ASP.NET only likes one set of RoleProviders defined in the web.config.
Has anyone tried this before or got any recommendations?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您将 ASP.Net 会员模型与内置提供程序一起使用，那么将它们放入一个数据库中是最简单的，正如您所指出的。
一种选择（我没有尝试过）是在 web.config 文件中为每个租户定义一个提供程序。 这将允许每个租户拥有自己的成员资格数据库，并允许您避免租户之间的用户名冲突（如果这是必需的）。
If you're using the ASP.Net Membership model with the built-in providers' then putting them into one DB is the easiest as you indicated.
One option, and I've not tried this, is to define in your web.config file a provider for each tenant. This would allow each tenant to have their own membership db, and allow you to avoid username collisions between the tenants (if this is a requirement).
您应该能够在运行时配置 ASP.NET 成员资格数据库连接字符串。 此帖子有几个选项，包括自定义会员资格提供程序或尽早更改值通过 Global.asax.cs 在请求生命周期中。
You should be able to configure the the ASP.NET membership database connection string at runtime. This thread has a few options including a custom membership provider or changing the value early on in the request lifecycle via Global.asax.cs.