关于asp.net MVC：传统ASP .NET Web窗体与MVC

作为具有某些winforms和客户端应用程序经验的人-值得回顾并学习传统ASP .NET页面的工作方式，还是直接进入ASP .NET MVC可以吗？

我对通用C＃的了解是一种陷阱或陷阱，而从截屏视频系列和ASP .NET网站上的这些知识中我不会知道。

---

这是关于MVC的伟大之处。它比普通的ASP.NET Web窗体更接近框架的基础。因此，通过使用MVC并理解它，您将对WebForms的工作方式有更好的了解。 WebForms的问题在于，要使Web像Windows Forms一样运作，有很多魔力，大约需要6年的时间，因此您具有控件树层次结构，并将所有内容都转换为Web。使用MVC，您可以获得不受WinForm影响的核心。

因此，从MVC开始，如果需要，您将可以轻松地移入WebForms。

---

我同意Nick的观点：MVC更接近于真正的Web范例，通过使用它，您将面对网站的真正工作方式。 WebForms吸引了您大部分这些东西，并且来自PHP背景，我发现它确实是违反直觉的。

我建议您直接跳到MVC并跳过WebForms。如前所述，您将可以在需要时重新使用它。

---

ASP.Net Webforms是基础框架上与ASP.NET MVC完全不同的抽象。与ASP.NET Webforms相比，使用MVC可以更好地控制幕后发生的事情。

我认为学习不同的做事方式通常可以使您成为更好的程序员，但是在这种情况下，可能需要学习更好的东西。

---

ASP.NET MVC适用于希望将客户端代码与服务器代码分离的开发人员。我想编写可以在服务器之间移动的JavaScript，XHTML，CSS客户端(不考虑服务器技术)。客户端安装和完成很耗时，因此您希望将它们(和子组件)用于尽可能多的服务器。此外，这种解耦还允许您的服务器支持任何支持HTTP和尖括号(和/或JSON)的客户端技术，例如WPF / Silverlight。如果没有ASP.NET MVC，您将被迫与整个ASP.NET团队建立敌对关系，但Scott Guthrie是一个很酷的家伙，在他的前任(也许是Scott本人)多年后，他几乎完全专注于MVC了让Windows Forms程序员编写Web应用程序。

在ASP.NET MVC之前，我主要基于ASHX文件-HTTP处理程序来构建ASP.NET应用程序。我可以向您保证，没有"真正的"微软商店会鼓励这种行为。从(明智的)管理角度来看，更容易指出所有开发人员都使用供应商推荐的使用供应商工具的方式。因此，落后一两年的IT商店将要求您了解MVC之前的工作方式。当您需要维护"旧版"系统时，这也很方便。

但是，对于绿色领域，一直都是MVC！

---

这取决于你的动机。如果您打算以ASP.NET开发人员的身份推销自己，那么您将同时需要两者。

如果这只是您自己的乐趣，请转到MVC。

我个人的感觉是，Webforms将存在很多年。如此多的人投入了时间和精力。但是，我认为人们会慢慢(或可能不会那么慢！)迁移。 Webforms始终只是让拖放式VB4实体考虑Web开发的一种方法。它虽然有效，但确实带走了很多控制权。

---

如果您不了解原始水平的Web请求/响应以及原始html / css渲染的方式或经验，那么MVC将是一个不错的起点。
然后，您将更好地了解webforms和mvc的优缺点。它们都将在未来出现，因为它们都将解决不同的需求。

尽管我会说Webforms是一个高度滥用和滥用的平台。
如此多的"不看代码"垃圾给所有使用它的人一个坏名字。
花时间了解它并正确使用它，您会发现它是一个非常可扩展且强大的平台。

---

由于到目前为止我只使用传统模型，因此我不能真正从技术上谈论MVC与"传统"。从我的读物来看，我认为没有哪一个要比另一个优越得多。我认为，一旦您"掌握了它"，您就可以在这两方面都非常有生产力。

但是实际上，我会考虑到大多数书籍，代码示例和现有应用程序都是以"传统"方式编写的。您将获得更多帮助，并且对于以"传统"方式编写的现有应用程序的雇主来说，您的技能将更加有用。

---

IMO，普通的Web表单场景比MVC更具陷阱。 Viewstate和数据绑定有时会很棘手。

但是对于MVC，这只是老式的简单形式，可以用老式的方式发布/渲染东西。并不是说它很糟糕，它只是与众不同，而且更加清洁。

---