动态重建实时 (MVC 3) 网站的最佳方法是什么
我认为我的问题与 MVC 3 网站有关并不重要，但我还是提到了它。
好的。我在 * PRODUCTION * 中有一个 subDomain MVC 3 网站，例如。 “dowork.mydomain.com”。
我正在为每个登录的客户动态创建区域。 （没有问题）。
如果客户位于他的区域（例如“dowork.mydomain.com/customer1234/”），并在他的帐户上工作，而新区域正在添加到应用程序中以供新加入的客户使用，例如。 dowork.mydomain.com/customer5678”，然后调用 MSBuild.exe 将新区域更新到实时网站，customer1234 在重建期间/之后是否会出现任何错误？
这是可行的方法，还是我会更好关闭为每次登录创建动态子域 (customer1234.mydomain.com) 以防止动态创建 customer5678.mydomain.com 时会发生任何错误 1234？
I do not think it matters that my question pertains to a MVC 3 website but I mention it anyway.
OK. I have a subDomain MVC 3 website in * PRODUCTION * , eg. "dowork.mydomain.com".
I am dynamically creating areas for each customer who logs on. (no prob with that).
If a customer is in his area, eg."dowork.mydomain.com/customer1234/", and doing work on his account, while a new area is being added to the app for a new customer who joins in, eg. dowork.mydomain.com/customer5678", to then which MSBuild.exe is called to update that new area to the live website, does the customer1234 incur any errors during/after that rebuild?
Is this the feasible approach, or would I be better off creating a dynamic subdomain for each logon (customer1234.mydomain.com) to prevent any errors 1234 would incur when customer5678.mydomain.com is dynamically created?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我仍然不完全理解您的要求，但重建网站将导致应用程序重新启动，这会严重影响可扩展性和性能。
第 1234 章"http://msdn.microsoft.com/en-us/library/e1f13641.aspx" rel="nofollow">httpRuntime maxWaitChangeNotification 和 waitChangeNotification 设置，用于控制何时appdomain 重新启动。
您可能需要重新思考如何构建系统，转而依赖更灵活、更动态的系统，该系统使用 URL 重写或动态路由以及共享数据驱动视图。
I still don't fully understand your requirements, but rebuilding the website will cause the application to restart, which has serious scalability and performance implications.
1234 shouldn't incur any errors since their request should finish running on the existing appdomain before the build started, but depending on the size of the files and the dependencies you may need to tweak the httpRuntime maxWaitChangeNotification and waitChangeNotification settings that control when the appdomain is started anew.
You may want to rethink how you've architected your system and rely instead on a more flexible and dynamic system that uses URL rewriting or dynamic routing along with a shared data driven view.