在我看来,似乎有很多事情在继续,每个人都跳上了MVC的潮流.几乎每个人都在宣称WebForms是邪恶的,没有太多说服力的撒旦.然后他们继续说控件是邪恶的,他们不应该在Web应用程序中.你如何在没有任何控制的情况下展示任何东西？
我记得当WebForms第一次出现并且每个人都喜欢它们时.我想在几年后,人们会接下来的事情,并宣布MVC邪恶,因为你必须实际创建控件来使用MVC,他们会说你必须开发一个应用程序而不用担心控件.
我认为MVC的方式可以通过在Form标签中不包含RunAt来实现.然后,如果要检索数据,只需使用Ajax.
有人能说服我为什么要使用MVC而不是WebForms？
你不应该在一个或另一个之间任意决定; 不要仅仅因为它是块中的新孩子并且每个人都赞不绝口地使用MVC框架,特别是如果你对使用Web Forms做事感到满意的话.实际上,每个现有系统都将使用较旧的,更成熟的技术,并且没有任何问题.
虽然MVC框架确实允许更容易地分离关注点(毕竟,这就是MVC模式的用途),但它也带来了编写更多HTML的责任,而且我认为对如何更好地理解网络工作; 不一定是一个不合理的要求,但你可以说它会让你在开始使用它的前几次稍微放慢速度.
说实话,我同意Web Forms需要很多不应有的瑕疵.当然,背景中有很多魔法,你对一些HTML输出的控制较少,但用CSS设置风格并不是完全不可能的(你最终!important可能会使用很多),这也不是不可能的.即使它不符合纯粹主义者对可能存在的看法,也要分离一些关注点.您仍然可以使用MVC框架编写相当糟糕的代码.如果你想快速拼凑一些东西,并且你对Web Forms很好,那么你将能够很快实现这一目标,并且没有什么可以感到羞耻的,是吗？
当然,这并不是说你应该坚持你的枪而忽略MVC; 它是一个很好的框架(事实上,它是一个非常好的框架),它确实带来了一些你可能想要长期利用的好处.您还必须记住它不会自动使您学习的有关ASP.NET 2.0的所有内容无效; 很多支持架构都包含在MVC框架中,包括会员提供商之类的东西.
在Webforms中:
Viewstate和Postbacks都遇到了很多问题,并增加了Web应用程序开发的复杂性.许多具有数百KB大小的Viewstate的网页有时会影响应用程序的性能.
开发人员无法控制Web表单的呈现HTML和使用混合内联样式呈现html的服务器控件以及不遵循标准的已弃用标记.
Web窗体的页面生命周期过于复杂,并且在ASP.net框架中的所有内容之间具有紧密耦合,并且单个类用于显示输出和处理用户输入.
单元测试几乎是不可能的任务.今天,单元测试在现代软件开发中非常重要,特别是当我们遵循敏捷方法和实践时.由于web是无状态的东西,Events,Postbacks和Viewstate不是一个好方法.
使用asp.net MVC,所有这些都被简化了
如果这些事情不适用于您并且您喜欢使用Webforms,那么坚持使用您最擅长的.不要试图修复没有破坏的东西.
有关更多详细信息,请参阅:Shiju的ASP.net MVC Vs ASP.net Web Form的博客
我认为MVC的主要优点是:
更清洁,更简单的架构.不再猜测您正在处理哪个事件来正确连接数据.不必再插入一个钩子来"修复"数据绑定问题,因为框架没有完全按照你想要的那样做.
框架并没有像你那样得到你的方式.
解耦架构使得更多代码更容易测试.
更紧密地与网络架构保持一致.对于来自WebForms背景的人来说,在你接受它并为它设计而不是试图在MVC中编写类似WebForms的应用程序之前,这似乎不是一个优势.幸运的是,在使用ASP.NET MVC之前,我已经探索过一些Ruby on Rails,并且已经开始以更RESTful的方式编写我的WebForms应用程序.
历史/无处不在 - 尽管微软正在推出它,但MVC是一个众所周知且备受推崇的模式.它广泛用于许多框架中的许多Web应用程序.如果您需要切换到他们也在进行MVC的其他技术(例如RoR或Java/Struts),学习MVC将为您提供支持.
缺点:
微软的实施是新的,而不是那么成熟.
很少有第三方"控件"/插件用于往返使用 - 通用网格等,尽管客户端通过jQuery有很多插件.
需要从WebForms中学习一些范例来有效地使用它.
该框架对您来说没有那么重要; 你将不得不学习一些Javascript并编写更多的客户端代码,因为框架不会为你注入它.
京公网安备 11010802040832号 | 京ICP备19059560号-6 