我只是听了StackOverflow团队的第17个播客,他们高度评价了ASP.NET MVC,我决定将其检查出来.
但首先,我想确定它是值得的.我已经为一个项目创建了一个基础Web应用程序(供其他开发人员使用),这个项目将在几天后开始,并且根据您的经验想知道我是否应该花时间学习MVC的基础知识并重新创建具有此模型的基本Web应用程序.
真的有很多专业人士会让它变得有价值吗?
编辑:这不是一个现有的项目,它是一个即将开始的项目,所以如果我要去做它应该是现在......
我刚发现了这个
但是,它不会将现有的回发后模型用于返回服务器的交互.相反,您将所有最终用户交互路由到Controller类 - 这有助于确保关注点和可测试性的清晰分离(这也意味着没有基于MVC的视图的视图状态或页面生命周期).
那会怎么样?没有观点?没有事件?
如果您今天对WebForms非常满意,那么ASP.NET MVC可能不适合您.
很长一段时间以来,我一直对WebForms感到沮丧.我绝对不是一个人在这里.在复杂的情况下,智能客户端,Web上的状态抽象严重破坏.我碰巧喜欢HTML,Javascript和CSS.WebForms试图向我隐藏它.它还有一些非常复杂的解决方案,可以解决实际上并不复杂的问题.Webforms本身也很难测试,虽然你可以使用MVP,但它对于Web环境来说并不是一个很好的解决方案......(与MVC相比).
MVC将吸引你,如果...... - 你想要更多地控制你的HTML - 想要像其他平台一样拥有无缝的ajax体验 - 想要可测试性通过 - 想要有意义的URL - 讨论回复和视图状态问题
至于预览5的框架,它非常稳定,设计主要在那里,升级并不困难.我在预览1上启动了一个应用程序,并在最新预览可用的几个小时内升级.
重要的是要记住MVC和WebForms不竞争,一个并不比另一个好.它们只是不同的工具.大多数人似乎将MVC与WebForms联系起来,因为"一个人必须是一个比另一个更好的锤子".那是错的.一个是锤子,另一个是螺丝刀.两者都用于将事物放在一起的过程中,但具有不同的优点和缺点.
如果有人给你带来不好的味道,你可能会尝试用螺丝刀敲钉子.WebForms使用MVC变得优雅和简单,某些问题很麻烦,反之亦然.
我使用过ASP.NET MVC(我甚至编写了一个HTTPModule,可以让你在web.config中定义路由),我仍然对此感到苦涩.
这似乎是组织和生产力方面倒退的一大步.也许它不适合某些人,但我已经找到了网络形式,并且他们对我来说没有任何挑战,只要使它们可维护.
那,我并不认可当前的"TEST EVERYTHING"时尚......
ASP.NET MVC基本上允许您分离代码的不同部分的职责.这使您可以测试您的应用程序.您可以测试您的视图,路由等.它还可以加速应用程序,因为现在没有ViewState或Postback.
但是,也存在缺点.因为,您不使用WebForms,您不能使用任何ASP.NET控件.这意味着如果要创建GridView,您将运行for循环并手动创建表.如果要在MVC中使用ASP.NET向导,则必须自己创建.
如果您厌倦了ASP.NET webform并希望自己执行所有操作,那么这是一个很好的框架.但是你需要记住,你是否会因为再次创造所有东西而受益?
总的来说,由于丰富的控件套件和自动管道,我更喜欢Webforms框架.
我会首先创建一个测试站点,看看团队的想法,但对我来说,使用MVC后我不会回到WebForms.
有些人不喜欢与HTML混合的代码,我可以理解这一点,但我更喜欢灵活覆盖页面生命周期,为我呈现HTML和biggy等内容 - 没有嵌入在页面源中的viewstate cruft.
有些人更喜欢MVC以获得更好的可测性,但我个人的大部分代码都在中间层并且无论如何都很容易进行测试......
@Juan Manuel您是否曾经历过经典ASP?当您必须编写所有自己的事件和"viewstatish"项目时(例如在提交表单后回忆其选定值的下拉列表)?
如果是这样,那么ASP.NET MVC就不会觉得尴尬了.我会查看Rob Conery的Awesome系列" MVC店面 ",他一直在浏览框架并为店面网站构建每个预期的组件.这真是令人印象深刻且易于跟进(追赶很难,因为Rob已经恢复活跃并在该系列中发布了很多).
就个人而言,与Jeff Atwood 对这个主题的感受完全相反,我更喜欢webform模型.它确实与vbscript /经典ASP日完全不同,但保持视图状态的检查和编写自己的CSS友好控件实际上是令人愉快的.
再说一遍,请注意我说"喜欢".ASP.NET MVC非常棒,而且更像其他网络技术.如果您喜欢或需要在多个平台上工作,从ASP.NET MVC转换到RAILS肯定更容易.而且,是的,如果贵公司不允许使用任何颜色的"beta"软件,它显然非常稳定(这个网站); 此时将其投入生产可能是一个问题.
@Jonathan Holland我看到你被选中了,但这是一个非常有意义的观点.我一直在阅读关于intertubes的一些帖子,人们似乎在混淆ASP.NET MVC 框架和MVC 模式.
MVC本身就是一个设计模式.如果您所寻找的只是"关注点分离",那么您当然可以通过webforms实现这一目标.就个人而言,我是标准n层环境中MVP模式的忠实粉丝.
如果你真的想要在ASP.NET世界中完全控制你的标记,那么MVC的ramework适合你.
如果您是一名专业的ASP.NET开发人员,并且有时间学习新东西,我肯定会建议您花一些时间来尝试ASP.NET MVC.它可能不是你所有问题的解决方案,并且有许多项目可以从传统的webform实现中获益更多,但是在尝试找出MVC时你肯定会学到很多东西,并且它可能带来很多想法,你可以申请工作.
在尝试开发MVC宠物项目时,我在阅读许多博客文章和视频教程时注意到的一件好事是,大多数都遵循当前的最佳实践(TDD,IoC,依赖注入,以及较低程度的POCO),加上很多JQuery让用户体验更加有趣,这就是我可以在我当前的webform应用程序上应用的东西,而且我之前没有曝光过这么深的东西.
ASP.NET MVC的做事方式与webforms有很大的不同,它会让你的想法发生一些变化,对开发人员来说非常好!
OTOH是一个初级到网络开发的人我认为MVC绝对是一个更好的开始,因为它提供了一个开箱即用的良好设计模式,并且更接近网络真正的工作方式(毕竟HTML是无状态的).在MVC上,你决定在线路上来回传递的每个字节(至少在你没有对html助手疯狂时).一旦这个人得到了,他或她将更好地适应ASP.NET网页表和服务器控件提供的"人工"设施.
如果你喜欢使用为你做很多工作的服务器控件,你就不会喜欢MVC,因为你需要在MVC中做很多手工编码.如果你喜欢GridView,期望自己写一个或者使用别人的.
MVC并不适合所有人,特别是如果你没有对GUI部分进行单元测试.如果您对网络表单感到满意,请坚持使用它.Web Forms 4.0将修复一些当前的缺点,例如由ASP.NET自动分配的ID.您将在下一版本中控制这些内容.