如何使用 ASP.Net MVC 创建多租户应用程序？
这个问题与其他问题不同，因为到目前为止我看到的所有问题都在谈论数据库。我了解多租户的数据库方面，但我不能 100% 确定前端的方法。
我正在设计一款产品，该产品基本上是为客户提供的托管服务。就多租户而言，您可以考虑托管 FogBugz 帐户。客户注册后，他们会获得自己的子域，然后访问 customersubdomain.thenormalurl.com 并登录到应用程序的一小部分。
当客户注册时，我们需要为子域设置 DNS 记录，但从应用程序方面来看，我们如何将应用程序“范围”到该客户？它只是应该查看发出请求的 url 还是有其他方法？这对我来说似乎过于简单，但也许我只是想让本应该简单的事情复杂化。
在 ASP.Net 世界中，这通常是如何完成的？
This question is different from the others because all of the questions I've seen so far are talking about the database. I understand the database side of multitenacy, but I'm not 100% sure on the way to do the front end.
I'm working on the design for a product that will basically be a hosted service for customers. As far as the multitenacy goes, you can think of a hosted FogBugz account. The customer signs up, they get their own subdomain, and then they go to customersubdomain.thenormalurl.com and login to their little portion of the application.
When the customer signs up we will need to setup a DNS record for the sub domain, but from the application side of it, how do we "scope" the application to that customer? Is it just supposed to look at the url that the request was made to or is there some other way? That seems overly simple to me, but maybe I'm just trying to complicate something that should be simple.
How is this normally done in the ASP.Net world?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Luke Sampson 在 ASP.NET MVC 下提供了一些使用子域的多租户应用程序的技术和示例代码：
http://blog.lukesampson.com/subdomains-for-a-single-application-with-asp-net-mvc
Luke Sampson has some techniques and sample code for multi-tenant applications using sub-domains under ASP.NET MVC here:
http://blog.lukesampson.com/subdomains-for-a-single-application-with-asp-net-mvc
是的，只需查看子域即可。如果您的用户登录，那么您可以忽略子域并通过登录凭据找出他们是谁。弄清楚他们是谁后，剩下的就是获取正确数据而不是显示错误数据的问题了。这就是所有这些数据库问题出现的地方。您可以通过使用单独的数据库或使用客户密钥标记所有记录来进行“范围界定”。所以你的应用程序必须实现这一点。
Yeah, just look at the subdomain. If your users log in, then you can ignore the subdomain and figure out who they are by their login credentials. After you figure out who they are, then it's just a matter of getting the right data and not showing the wrong data. And that's where all those DB questions come in. You do that 'scoping' by either using separate DBs or by marking all your records with keys to the customer. So your app has to implement that.