Should I migrate to ASP.NET MVC?我只是听了StackOverflow团队的第17个播客，他们对ASP.NET MVC的评价很高，以至于我决定检查一下。 但是首先，我想确定这是值得的。 我已经为几天之内开始的项目创建了一个基本的Web应用程序(供其他开发人员使用)，并希望根据您的经验知道我是否应该花时间学习MVC的基础知识并重新创建 具有此模型的基本Web应用程序。 是否真的有真正的大职业值得这样做？ 编辑：这不是一个现有的项目，这是一个即将开始的项目，所以如果我要去做的话，应该现在... 我刚发现这个
那将如何工作？ 没有检视状态？ 没有活动吗？ 如果您今天对WebForms感到很满意，那么也许ASP.NET MVC不适合您。 很长时间以来，我对WebForms感到沮丧。我绝对不是一个人在这里。 Web上的智能客户端，有状态抽象在复杂情况下会严重崩溃。我碰巧喜欢HTML，Javascript和CSS。 WebForms试图向我隐藏它。对于没有那么复杂的问题，它也提供了一些非常复杂的解决方案。 Webforms本质上也很难测试，虽然可以使用MVP，但它并不是Web环境的理想解决方案...(与MVC相比)。
如果...，MVC将吸引您 至于Preview 5框架，它相当稳定，设计就在那儿，升级也不难。我在Preview 1上启动了一个应用程序，并在可用最新预览版后的几个小时内进行了升级。 重要的是要记住，MVC和WebForms没有竞争，并且两者都不比另一个更好。它们只是不同的工具。大多数人似乎将MVC与WebForms结合起来是因为"一个必须比另一个更好"。那是错的。一个是锤子，另一个是螺丝刀。两者都用于将事物放在一起的过程中，但是有不同的优点和缺点。 如果您的口感不好，您可能正在尝试使用螺丝刀砸钉子。 WebForms的某些问题使MVC变得优雅而简单，反之亦然。 我已经使用过ASP.NET MVC(我什至编写了HTTPModule，可以在web.config中定义路由)，但对此我仍然有些苦涩。 这似乎在组织和生产力方面倒退了一大步。也许不是某些人想要的，但我已经弄清楚了Web表单，就可维护性而言，它们对我没有任何挑战。 那，我不赞成目前的"一切都测试"风尚... ASP.NET MVC基本上使您可以区分代码不同部分的职责。这使您能够测试您的应用程序。您可以测试您的视图，路线等。由于现在没有ViewState或Postback，因此它也可以加快应用程序的速度。 但是，也有缺点。因为您不使用WebForms，所以不能使用任何ASP.NET控件。这意味着如果要创建GridView，将运行for循环并手动创建表。如果要在MVC中使用ASP.NET向导，则必须自行创建。 如果您对ASP.NET Webform感到厌倦并想自己执行所有操作，则它是一个不错的框架。但是您需要记住，是否再次创建所有内容会有所帮助？ 通常，由于控件和自动检测功能丰富，我更喜欢Webforms框架。 我将首先创建一个测试站点，然后了解团队的想法，但是对我来说，在使用MVC之后，我不会再使用WebForms了。 有些人不喜欢将代码与HTML混合在一起，我可以理解这一点，但是与页面生命周期(Page Lifecycle)之类的东西相比，我仍然更喜欢灵活性，为我呈现HTML和biggy-页面源代码中没有嵌入视图状态。 有些人喜欢使用MVC来实现更好的可测试性，但是个人而言，我的大多数代码都位于中间层，并且无论如何都易于测试... @Juan Manuel您曾经在经典ASP中工作吗？什么时候需要编写所有自己的事件和" viewstatish"项(例如在提交表单后调用其选定值的下拉菜单)？ 如果是这样，那么ASP.NET MVC不会觉得尴尬。我将查看Rob Conery的Awesome系列" MVC店面"，他在其中浏览了框架并为店面站点构建了每个预期的组件。确实令人印象深刻且易于遵循(追赶非常困难，因为Rob一直非常活跃并在该系列中发布了很多文章)。 就个人而言，与杰夫·阿特伍德(Jeff Atwood)对这个话题的看法完全相反，我宁愿喜欢Webform模型。当然，这与vbscript /经典ASP时代完全不同，但实际上，请务必检查viewstate并编写自己的CSS友好控件。 再说一遍，注意我说"喜欢"。 ASP.NET MVC确实很棒，并且更像其他Web技术。如果您愿意或需要在多个平台上工作，从ASP.NET MVC转换为RAILS当然更容易。而且，是的，如果您的公司禁止使用任何颜色的"测试版"软件，则它显然非常稳定(本站点)。此时将其实施到生产中可能是一个问题。 @乔纳森·霍兰德我看到你被否决了，但这是非常有效的一点。我一直在阅读有关intertube的文章，人们似乎在混淆ASP.NET MVC框架和MVC模式。 MVC本身就是一个设计模式。如果您所寻找的只是"关注点分离"，那么您当然可以使用Web表单来实现。我个人是标准n层环境中MVP模式的忠实拥护者。 如果您真的想在ASP.NET世界中完全控制您的标记，那么MVC便适合您。 如果您是专业的ASP.NET开发人员，并且有一些时间可以用来学习新知识，那么我当然建议您花一些时间来尝试ASP.NET MVC。可能不是所有问题的解决方案，许多项目可能会从传统的Webform实现中受益匪浅，但是在尝试弄清MVC时，您肯定会学到很多，并且可能会提出很多想法，您可以申请工作。 我在尝试开发MVC宠物项目时浏览许多博客文章和视频教程时注意到的一件好事是，其中大多数都遵循了当前的最佳实践(TDD，IoC，依赖注入和较低程度的POCO)，加上大量的JQuery，使用户的使用体验更加有趣，这是我可以在当前的Webform应用程序中应用的东西，而且我以前没有这么深入。 ASP.NET MVC的处理方式与Web表单非常不同，以至于您会有些不安，这对于开发人员来说是非常好的！ OTOH对于Web开发的初学者来说，我认为MVC绝对是一个更好的开始，因为它提供了一种开箱即用的良好设计模式，并且更接近于Web的真正工作方式(毕竟HTML是无状态的)。在MVC上，您决定在网络上来回传输的每个字节(至少在您不对html helper疯狂的情况下)。一旦这个家伙明白了，他或她将有更好的能力转移到ASP.NET Web表单和服务器控件提供的"人工"功能。 如果您喜欢使用为您做很多工作的服务器控件，您将不喜欢MVC，因为您将需要在MVC中进行大量的手工编码。如果您喜欢GridView，请期望自己写一个或使用别人的。 MVC并非适合所有人，特别是如果您不打算对GUI部分进行单元测试。如果您对Web表单感到满意，请继续使用它。 Web Forms 4.0将解决一些当前的缺陷，例如由ASP.NET自动分配的ID。在下一版本中，您将可以控制它们。 除非与您合作的开发人员熟悉MVC模式，否则我不会。至少在进行如此大的更改之前，我会先与他们交谈。 我正在就ASP.NET MVC做出同样的决定，Juan Manuel。我现在正在等待合适的项目来进行实验。如果实验顺利进行(我的直觉就可以了)，那么我将围绕该框架设计新的大型项目。 使用ASP.NET MVC，您将失去ASP.NET Web窗体的视图状态/回发模型。没有这种抽象，您将与HTML以及HTTP POST和GET命令紧密合作。我相信UI编程在某种程度上朝着经典ASP的方向发展。 带来的不便带来了更大程度的控制。我经常发现自己正在与ASP.NET的伪会话会话垃圾作斗争，重新获得对输出HTML的完全控制的前景似乎非常令人耳目一新。 也许这两个世界都是最好的，也可能是最坏的。 您应该仔细研究ASP.NET MVC的5个理由 Ajax，RAD(带有ajax的Web窗体经常是反RAD)，完全控制(无需开发全部代码和周期)。 webforms仅能绑定某些网格，而不是其他任何东西，还有一个更重要的事情-性能，这是很好的。当您陷入网络表单时，您迟早会打开MVC。
您是否从未听说过N-Tier的发展？ 不，你不应该。可以在一个新项目中随意尝试，但是许多熟悉ASP.NET Web表单的人还不喜欢它，因为它们必须混用原始HTML +许多不同的概念+在文档中非常苗条的选择/教程。 我不了解ASP.NET MVC，但是我对MVC模式非常熟悉。我看不到没有MVC来构建专业应用程序的另一种方法。它必须是MVC模型2，例如Spring或Struts。顺便说一下，您的人们如何在没有MVC的情况下构建Web应用程序？当您遇到每个请求都需要某种验证的情况时，例如验证用户是否通过身份验证时，您的解决方案是什么？每页都有某种include(validate.aspx)吗？ 我不建议仅在现有项目上进行切换。也许开始一个小的"演示"项目，团队就可以使用该项目来试验该技术，并(如有必要)了解他们的需要，并向管理层证明进行转换是值得的。最后，即使开发团队也可能意识到他们还没有准备好或者不值得。 无论您做什么，都要确保将其记录下来。也许如果您使用演示项目，请写一份事后备查。 如果您对使用MVC框架一无所知，那么我宁愿使用Castle项目的... 话虽如此，我个人认为WebControls具有很多优点，例如能够创建具有状态客户端的事件驱动应用程序等。构造大多数针对WebControl的参数是因为缺乏对WebControl模型等的理解，而不是因为它们实际上确实很糟糕... MVC不是Silver Bullet，尤其不是Microsoft MVC。 研究ASP.net MVC仅在" Preview 5"中时是否引起关注？ 我知道StackOverflow是使用它创建的，但是微软是否有可能在正式退出beta / alpha / preview版本之前对其进行重大更改？ 我已经看到了MVC框架的某些实现，其中为了可测试性，有人用代码呈现了整个HTML。在这种情况下，视图也是可测试的代码。但是我说，我的朋友，将HTML放入代码中是维护的噩梦，他说我很好，我喜欢编译和测试的所有内容。我没有提出异议，但后来发现他确实将此HTML放入了资源文件中，并且疯狂仍然存在。 他几乎没有意识到分离View的整个想法也解决了维护部分。在某些应用中，它胜过可测试性。如果使用的是WYSWYG工具，则无需测试HTML设计。因此，WebForms很好。 我经常看到人们滥用回发和视图状态，并将其归咎于ASP .NET模型。 请记住，最好的网页仍然是.HTML，这就是ASP .NET MVC的强大功能。 |
