asp.net mvc vs客户端繁重的webforms
当最近设计一个中到大型的web应用程序时，我决定使用以客户端为主的webforms实现，而不是UI层的asp.net MVC。
原因是，使用webforms可以很容易地快速打开屏幕并将web应用程序粘合在一起(我广泛使用Telerik的radcontrols，因为它们有一个富客户端模型)。我发现，我越早在客户面前得到一个原型UI，他们就能越快地看到它，并将其演变为他们真正想要的东西。
当我说以客户端为主的webforms时，我主要是在客户端绑定数据，然后使用web服务来处理来自客户端的事件-这些web服务与我的业务层交互，并以JSON进行处理。比方说，当一个UI事件需要更新许多控件时，好处就来了--然后我可以回到asp.net页面周期，并在将各种控件包装在更新面板中之后，启动一个部分回发。
在我看来，我可以有我的蛋糕，我可以吃它！我可以将闪电般的JSON web服务用于应用程序的性能关键区，但对于复杂的UI区域，我可以恢复到回发/部分回发模型。总而言之，更少的开发时间和重要的性能。
最后，我要问你一个问题！
我并不是试图抗拒MVC，只是简单地问它是否比我上面所做的更好，如果是，为什么？
回答 3
Stack Overflow用户
发布于 2011-05-07 00:27:14
你使用web表单的理由是有道理的:快速原型化，在客户面前获得模拟用户界面。另一个原因是大量的供应商提供服务器控件来转储到web窗体页中。
我个人认为，对于那些习惯于使用拖放设计器而不是手动编辑HTML的人来说，MVC有一点学习曲线。也就是说，一旦你克服了它，我相信你再也不会使用web表单了。弹出了许多控件，它们可以很好地与MVC一起工作。Telerik's MVC Extensions只是一个例子，恰好也是开源的。
Stack Overflow用户
发布于 2011-05-07 00:30:04
在某些情况下，您回退到页面回发，这意味着您实际上维护了两个不同的模型。一个在客户端，一个在服务器端。在回发的情况下，您在服务器端进行了更改，现在您需要找到一种方法将这些更改传达给客户端。我不知道您是如何做到这一点的，但这不是完全可扩展的，因为每个更改都必须在客户端和服务器端之间同步。在MVC中，我们使用服务器端视图模型来处理这一点，这些模型在客户端由框架自动处理。(在顶部，我们使用客户端绑定库，如Knockoutjs，与MVC一起使用要比使用webforms容易得多)
其次，在webforms中，您也没有获得路由优势。所以你的路由仍然看起来像那些丑陋的Mysite.com/mypage.aspx。
Stack Overflow用户
发布于 2013-12-07 17:38:47
我在这里有一个房地产应用: www.homevana.com。这是一个web表单应用，但我打赌你不会知道的。对于这个项目的需求，客户端繁重的应用程序在有大型复杂表单要完成的时候仍然使用web表单来收集关于待售房屋的数据是最佳选择。因此，Homevana应用程序上的大多数.aspx页面都没有后置代码，但是当有复杂验证的表单时，我使用带有服务器控件的.aspx页面和Peter Blum的验证套件：http://www.peterblum.com/Home.aspx (当然都是复杂的客户端验证)来快速完成这方面的工作。
可以通过nuget：http://www.hanselman.com/blog/IntroducingASPNETFriendlyUrlsCleanerURLsEasierRoutingAndMobileViewsForASPNETWebForms.aspx安装FriendlyUrl包很容易摆脱“丑陋的”.aspx扩展，不过也可以使用一个IIS7正则表达式url路由规则来完成。
这一切都是关于合适的工具来完成这项工作。MVC非常棒，我还有很多其他使用MVC的项目，但它并不总是满足项目需求的最佳工具。
https://stackoverflow.com/questions/5914243
复制相似问题
腾讯云开发者
