在这种情况下，asp.net mvc比传统的asp.net网站差吗？

Question

今天，我和我的同事就这个话题进行了辩论。对于他的观点，他并不认为ASP.NET MVC适合构建一个小而且不断更新的网站。相反，他认为传统的asp.net网站仅适用于这种情况。因为ASP.NET MVC需要先编译才能生成.dll文件。这样我们就可以部署Web应用程序了。另一方面，传统的asp.net没有。

是真的吗？

Answer 1

首先，你需要记住，没有严格的规则，你可以使用任何适合你的方法。现在澄清一下，有3个选项（不是2个）：

1. ASP.NET MVC项目（您的选项）

2. ASP.NET Web应用程序项目（WebForms）

3. ASP.NET WebSite项目（WebForms以及显然是您同事的选择）

现在，我大大简化了这一点，但通常＃1和＃2在部署之前共享编译/构建的相同基本原则。这是你的同事指出的潜在缺点，这就是为什么他的选择是＃3。 ASP.NET WebSite项目“按设计”将在部署后进行编译。您可以预编译它们，但您不必这样做。现在，在这种情况下，你的争议将使用与＃2 vs＃3相同的推理，幸运的是，这已经多次出现过：

ASP.NET Web Site or ASP.NET Web Application?

http://blogs.msdn.com/b/aspnetue/archive/2009/12/14/asp-net-web-application-projects-vs-web-site-projects-in-visual-studio.aspx

另一方面，我敢说你的同事是经过认证的MS技术人员，因为这类问题经常出现在MS ASP.NET考试中。根据我的经验，我只能说微软为选择网络项目而设定的这些指导方针实际上并没有让我相信。他们说这取决于项目和团队风格，但是根据我的专业经验，我从未有机会看到ASP.NET WebSite项目的“优势”在实践中得到了回报。

请记住，我们只讨论预编译与非预编译（您的同事的论点），ASP.NET MVC和WebForms之间的内容远不止这些。

Answer 2

ASP.NET MVC构建于传统ASP.NET之上。你需要编译两者。我认为MVC对于快速变化的网站更有利，因为它有助于更​​好地分离关注点和使用最佳实践，从而使设计更容易更新。

Answer 3

我认为根据部署网站所需的自动化操作数量选择工具是不好的做法。

您可以轻松（并且一次）准备一个脚本来单击部署网站的下一个版本（即，如果Visual Studio的标准部署向导不适合您），编译是否无关紧要参与与否。

真正重要的是您熟悉的框架，或者想要熟悉的框架。

如果您不熟悉Web窗体和ASP.NET MVC，那么我建议您学习第二篇。

Answer 4

即使您没有预编译您的asp.net webforms网站，ASP.NET也会自行完成。 因此，MVC更适合您的项目 - 因为它可以轻松地部分更新网站。