如果有选择的话，我们会走哪条路？

ASP.NET Webforms + ASP.NET AJAX

或者

ASP.NET MVC + JavaScript Framework of your Choice

ASP.NET Webforms / ASP.NET AJAX与MVC相比有什么限制？

解决方案

我喜欢Web表单，但是ASP.NET AJAX是一堆废话。

我更喜欢使用WebForms +自定义HTTPHandlers处理任何AJAX调用的服务器端。

呵呵，不满意...

ASP.NET AJAX是一堆废话，因为回调要求重新实例化整个页面类，我们不是在调用单个方法，而是每次都在服务器上重建整个页面。

另外，UpdatePanels返回整个页面，仅弹出更新面板中的部分，这完全浪费带宽。

我理解为什么这样做是因为WebForms控件实际上不是很容易以其他方式实现，但是它仍然很糟糕。

我已经将asp.net winforms与ajax.net以及prototype / ext / jquery一起使用了。我想应该考虑的是网站的目标。MVC是一种流行的模式。对于ASP MVC，我无法说什么，因为我没有机会使用它，但是我想确保我们知道，如果我们选择Webforms，则不仅限于ajax.net。

ASP.NET MVC仍处于"预览"形式，因此，在它成熟之前，我不会考虑它。我们可以轻松滚动自己的MVP模式，而无需花费太多精力。

在Ajax方面，我想尝试找到可以满足我们需求的库(商业库或者其他库)。基础知识(网格，树，自动完成的文本框等)已经死了。不要重新发明轮子。

我最近都做过，我会在十次中拿九次MVC。

• 我真的不喜欢asp.net ajax控件的实现，我遇到了很多有关计时，事件和调试回发问题的问题。我从http://encosia.com/2007/07/11/why-aspnet-ajax-updatepanels-are-dangerous/中学到了很多
• 在asp.net项目中，我们使用了MVP模式http://www.codeplex.com/aspnetmvp，该模式效果很好。但是，由于我们直接与服务器端控件进行交互(即，许多gridview操纵)，因此在视图中最终得到了很多代码。此代码几乎无法在单元测试框架中进行测试。我们应该更加努力地将代码放在视图之外，但是在某些情况下，它更容易实现，并且不会造成混乱。

我选择使用asp.net表单开发的一次是使用gridview控件。我们在MVC的JavaScript框架中使用的是jquery，但尚未找到控件之类的很好的gridview。我们有一些功能，但是相对于使用asp.net服务器端控件，我们投入了大量的时间进行学习，调整和调试。可以松开Microsoft提供的所有精美的小部件，它们可以进行非asp.net表单开发。这些小部件的丢失正在释放，并且在我们首次启动的同时令人恐惧。

归根结底，我很高兴我们正在进行MVC开发。我和我的团队已经学习了一个新的框架(以前我们只是asp.net开发人员)，并且已经开始使用html和javascript。这些是我们可以根据需要用于其他项目或者其他语言的技能。

在设计站点时，我更喜欢的一大优点是DRY原则。 IMO ASP.NET MVC比Web表单干得多。

我最近已经从Web表单转移到了MVC，我希望我再也不必回头了！

带有ASP.NET Ajax的Webforms是天堂。两者之间的集成令人惊叹，并且使用起来非常自然。

使用Webforms代替mvc将使我们能够利用生命周期来开发非常好的和可重复使用的控件。

但是我仍然喜欢在混合中添加一些jQuery，以便遍历dom和添加动画，我只是喜欢使用asp.net ajax与服务器端集成。

我同意asp.net ajax UpdatePanels不是理想的解决方案。

我们避免使用它们，而是一直使用客户端库与服务器进行任何通信。我确实喜欢我在PDC上看到的关于具有声明性组件和客户端模板的asp.net ajax 4.0中的功能，非常好！将JQuery与现有库结合在一起可以提供很多功能，并且我一直质疑使用JQuery来代替它，因为它占用的空间小得多，并且能够执行与asp.net ajax客户端库相同的事情。

就服务器堆栈而言，我还没有使用过MVC，但是我们成功使用了通过Webforms自行开发的MVP方法。

MVC背后的概念很棒，但是要准备好释放多年来使用的所有服务器控件的几乎所有功能。我只看了大约一个星期的MVC实现，但是页面生命周期和视图状态都消失了，所以这些控件不再正常工作。

我也惊呆了，找到了许多包含大量逻辑代码的示例。没错，aspx文件中的" if"和" foreach"语句-倒退了恕我直言。我很高兴将经典的asp抛在后面，但是在asp.net mvc模式的当前实现中，我们可以回到标记中的代码，需要在所有地方使用辅助程序以及几乎没有可用的服务器控件。

如果我们现在开始一个新项目，我建议我们坚持使用asp.net webforms，并根据需要使用内置的asp.net ajax，工具包和jQuery。 asp.net ajax实现可能不是绝对最佳或者最有效的实现，但是除非我们在第一天获得一百万个唯一身份，或者服务器是vic 20，否则性能影响不会那么明显。

当然这取决于项目规模。如果我们要启动一个期望获得数百万页面浏览量的5年企业级应用程序，UpdatePanel可能不会削减它，但是如果我们要构建一个普通的网站，抛出一个原型或者只是需要快速行动，请访问asp.net ajax的工作原理非常好，学习曲线极低。

需要明确的是，每次进行ajax调用时，绝对不会返回整个页面。 / Only /需要更新的面板内容通过网络发送。任何http监视器都会证明这一点。是的，页面/ lifecycle /已执行，但是知道我们可以构建相当有效的asp.net ajax应用程序。

如果需要更新面板，建议我们使用开源和精简版MagicAjax或者ComfortASP。如果我们需要框架有助于开发自定义Ajax，建议使用jQuery。

不要让人误以为这是一个明确的选择。我们可以两全其美。我的方法是创建一个MVC项目，但不要添加视图，而要添加标准的asp.net页面，但要更改其背后的代码以继承自MVC.ViewPage，如下所示：

public partial class SamplePage : System.Web.Mvc.ViewPage
{
    protected void Page_Load(object sender, EventArgs e)
    {
    }
}

如果我们将自己限制在前面代码中的单个表单标签(带有runat =" server")中，那么在访问标准asp.net服务器控件之后，我们将拥有完整代码。这意味着我们可以完全控制表示的服务器端控制(例如，使用数据绑定和转发器)，而不必进行旧的ASP样式的代码编织。

protected void Page_Load(object sender, EventArgs e)
    {
        IObjectDefinition instance = (IObjectDefinition)ViewData["definition"];
        _objectName.Text = instance.DisplayName;//textbox or label

        DataTable itemVals = new DataTable();
        itemVals .Columns.Add("itemName");
        itemVals .Columns.Add("itemValue");            

        IDictionary<string, string> items = (IDictionary<string, string>)ViewData["items"];
        foreach (KeyValuePair<string, string> datum in items)
        {
            conditions.Rows.Add(new object[] { datum.Key, datum.Value});
        }

        _itemList.DataSource = itemVals;//repeater
        _itemList.DataBind();
    }

任何控件的发布都不会发回到页面上，而是发回到控制器上。如果我们记得在服务器控件上使用过name属性，则它们最终会出现在FormControls集合中，以根据标准MVC访问页面变量。

那你得到什么呢？

• 演示的完全服务器端控制我们前面的代码完全是HTML和asp.net服务器控制标签
• 完全分离的关注点-该页面仅进行演示，所有编排和编组均在控制器中完成(而不是页面中的asp.net样式)
• 全面的MVC可测试性
• 没有html代码编织
• 我们可以关闭视图状态并减少页面膨胀

你输了什么？

• 再一次，如果我们只想使用服务器控件，那么我们将被限制为每页仅使用一种表单
• 我们可能需要手动为按钮和表单指定回发目标
• 我们再次有2个文件供我们演示

哦，绝对是AJAX jQuery。向返回JsonResult的控制器方法发出请求确实简化了事情。

我看到大多数响应都在MVC 1.0之前发布。由于我们现在处于2.0预览版中，所以我认为重新访问它可能会很好。

在去年三月移至MVC之前，我是ASP.NET开发人员大约五年了。我没有后悔一秒钟。现在我意识到，我对ASP.NET WebForms的了解越强，学习其他技术(如JavaScript和非Microsoft AJAX实现)的难度就越大。 Microsoft从WinForms开发方法中利用了ASP.NET开发方法，如果我们来自WebForms开发，这可以学习，但是如果我们了解这两种方法之间的差异，那么这不是开发Web应用程序的好方法。

我正在工作的最新项目要求我学习ASP.NET MVC，JavaScript，jQuery，CSS 2和AJAX(非Microsoft)。仅9个月后，与进行5年的ASP.NET开发相比，我感觉更好地准备进行Web开发项目。 ASP.NET实现使事情很难长期维护。 MVC使事情变得如此简单，因为我们对快捷方式的依赖性降低。学习框架需要花费一些时间，但是我们对框架的了解越多，对框架的依赖就越少，我们就越会开始学习和理解已建立的标准，例如JavaScript和AJAX。

对我来说，这是一个明确的选择。我将永远不会回到ASP.NET。如果我不能使用ASP.NET MVC，我将学习Ruby或者PHP。我希望Web开发工具的进步和进步是受开发人员社区的需求驱动的，而不是受利润驱动的。

我的经验是使用php和ruby为Apache服务器编程Web应用程序。当我从事维护用asp.net(webforms)编写的Web应用程序的工作时，便开始学习Microsoft构建Web应用程序的方法。我不得不说我完全受了伤！我当时在想WTF是否会将所有这些ViewState垃圾发送回来？这甚至有必要吗？

然后，我决定考虑用ajax和jquery做一些简单的事情，这些使我更新正在生成的面板和clientID，而不是我在视图中设置的内容。真浪费我的时间！为什么我不能在一页上有多个表格？为什么我不能只使用常规的ajax调用？为什么我的视图具有服务器逻辑？这些都是无法确保许多Web程序员面对asp.net Webforms的问题。然后，我发现了.NET MVC。我的生活变得轻松多了。

我习惯于使用Rails和CakePHP等MVC框架以编程方式创建Web应用程序。技术实际上是指网络。

我的建议是，将WebForms留给习惯于对winforms类型的应用程序进行编程的人员使用，因为它试图抽象出我们正在Web上编程的事实。如果我们想拥有真正的自由来开发对Web程序员真正有意义的Web应用程序，请使用.NET MVC或者类似的东西，而不会妨碍我们。

那是我的两分钱...

为了补充@ben的答案，我使用ASP.Net Webforms进行简单的数据绑定，并使用JQuery进行所有Ajax事务。老实说，由于它的简单性，我仍然不能放弃数据绑定。 Viewstate几乎没有用，所以我基本上将其关闭。虽然我们可以使用MVC，但是请注意，将花费大多数时间来开发在Forms中视为理所当然的功能。祝你好运！

自最初的问题以来已经有很长时间了。现在我们有了MVC3和.NET 4

现在，MVC是不是比以前更好的解决方案？