作为具有一些 winform 和客户端应用程序经验的人 - 是否值得回去学习传统 ASP .NET 页面的工作方式,或者直接进入 ASP .NET MVC 是否可以?
我正在寻找我的一般 C# 知识中的陷阱或陷阱,我不会从截屏视频系列和 ASP .NET 站点上的内容中知道这些。
作为具有一些 winform 和客户端应用程序经验的人 - 是否值得回去学习传统 ASP .NET 页面的工作方式,或者直接进入 ASP .NET MVC 是否可以?
我正在寻找我的一般 C# 知识中的陷阱或陷阱,我不会从截屏视频系列和 ASP .NET 站点上的内容中知道这些。
这是关于 MVC 的伟大之处。它比普通的 ASP.NET Web 窗体更接近框架的基础。所以通过使用 MVC 并理解它,你将更好地理解 WebForms 是如何工作的。WebForms 的问题是它有很多魔力,并且花了大约 6 年的时间试图让 Web 像 Windows Forms 一样工作,所以你有控制树层次结构和所有东西都转换到 Web 上。使用 MVC,您可以获得不受 WinForm 影响的核心。
因此,从 MVC 开始,如果需要,您将能够轻松地迁移到 WebForms。
我同意 Nick 的观点:MVC 更接近于真正的Web 范例,通过使用它,您将了解您的网站是如何工作的。WebForms 将这些东西中的大部分从你身上抽离出来,并且来自 PHP 背景,我发现它真的很反直觉。
我建议你直接跳到MVC,跳过WebForms。如前所述,如果需要,您将能够恢复它。
与 ASP.NET MVC 相比,ASP.Net Webforms 是对基础框架的完全不同的抽象。使用 MVC,与使用 ASP.NET Webforms 相比,您可以更好地控制幕后发生的事情。
在我看来,学习不同的做事方式通常会让你成为一个更好的程序员,但在这种情况下,可能会有更好的东西要学。
ASP.NET MVC 适用于希望将客户端代码与服务器代码分离的开发人员。我想编写可以在服务器之间移动的 JavaScript、XHTML、CSS 客户端(不考虑服务器技术)。客户端的安装和完成非常耗时,因此您希望将它们(和子组件)用于尽可能多的服务器。此外,这种解耦允许您的服务器支持任何支持 HTTP 和尖括号(和/或 JSON)的客户端技术,如 WPF/Silverlight。如果没有 ASP.NET MVC,您将被迫与整个 ASP.NET 团队建立敌对关系——但 Scott Guthrie 是一个很酷的家伙,在他的前任(也许还有 Scott 本人)几乎完全专注于让 Windows 窗体程序员编写 Web 应用程序。
在 ASP.NET MVC 之前,我主要基于 ASHX 文件——HTTP 处理程序构建 ASP.NET 应用程序。我可以向您保证,没有“真正的”微软商店会鼓励这种行为。从(明智的)管理角度来看,更容易规定所有开发人员都使用供应商推荐的方式来使用供应商的工具。因此,落后一两年的 IT 商店将要求您了解 MVC 之前的做事方式。当您需要维护“遗留”系统时,这也会派上用场。
但是,对于绿色领域,它一直是 MVC!
这取决于你的动机。如果您打算以 ASP.NET 开发人员的身份推销自己,则两者都需要。
如果这只是为了你自己的乐趣,那就去 MVC。
我个人的感觉是,网络表单还会存在很多年。很多人都在他们身上投入了时间和精力。然而,我认为人们会慢慢地(或者可能不会那么慢!)迁移。Webforms 始终只是一种让拖放式 VB4 死者思考 Web 开发的方法。它有点工作,但它确实带走了很多控制权。
IMO,在普通的 Web 表单场景中,除了 MVC 之外,还有更多的陷阱。视图状态和数据绑定有时会很棘手。
但是对于 MVC,它只是简单的形式发布/渲染东西,老式的方式。并不是说它不好,它只是不同,而且更干净。
我不能真正从技术上谈论 MVC 与“传统”,因为到目前为止我只使用了传统模型。不过,从我读过的内容来看,我不认为其中一个比另一个优越得多。我认为一旦你“得到它”,你就可以在这两个方面都非常有成效。
但实际上,我会考虑到大多数书籍、代码示例和现有应用程序都是为“传统”方式编写的。您可以获得更多帮助,并且您的技能对于以“传统”方式编写现有应用程序的雇主来说将更加有用。
如果您不知道或没有原始级别的 Web 请求/响应和原始 html/css 渲染的经验,那么 MVC 将是一个不错的起点。然后,您将更好地了解 webforms 和 mvc 的优缺点。它们都将在未来出现,因为它们都满足不同的需求。
虽然我会说网络表单是一个被高度滥用和滥用的平台。如此多的“不看代码”垃圾给所有使用它的人一个坏名声。花时间去理解它并正确使用它,你会发现它是一个非常可扩展且强大的平台。