ASP。净webforms + ASP。净Ajax和ASP。净MVC和Ajax框架的*

时间:2022-05-06 03:21:34

If given the choice, which path would you take?

如果让你选择,你会走哪条路?

ASP.NET Webforms + ASP.NET AJAX

ASP。净Webforms + ASP。净AJAX

or

ASP.NET MVC + JavaScript Framework of your Choice

ASP。NET MVC + JavaScript框架的选择

Are there any limitations that ASP.NET Webforms / ASP.NET AJAX has vis-a-vis MVC?

ASP有什么限制吗?净Webforms / ASP。NET AJAX有vi -a-vis MVC?

14 个解决方案

#1


29  

I've done both lately, I would take MVC nine times out of ten.

我最近两样都做过,十次中有九次是MVC。

  • I really dislike the implementation of the asp.net ajax controls, I've run into a lot of issues with timing, events, and debugging postback issues. I learned a lot from http://encosia.com/2007/07/11/why-aspnet-ajax-updatepanels-are-dangerous/
  • 我真的不喜欢asp.net ajax控件的实现,我遇到了很多时间、事件和调试回发问题。我从http://encosia.com/2007/07/11/why-aspnet-ajax-updatepanel -are-dangerous/中学到了很多
  • The asp.net project we used the MVP pattern http://www.codeplex.com/aspnetmvp, and the pattern worked great. However we ended up with a lot of code in the view because we were directly interacting with the server side controls (i.e a lot of gridview manipulations). This code is nearly untestable with the unit test frameworks. We should have been more diligent about keeping code out of the view, but in some instances it was just easier and less messy.
  • net项目我们使用了MVP模式http://www.codeplex.com/aspnetmvp,这个模式非常有效。但是,由于我们直接与服务器端控件交互(i),所以最终在视图中产生了大量代码。大量的gridview操作)。这段代码在单元测试框架中几乎是不可测试的。我们本应该更加努力地将代码从视图中排除出去,但在某些情况下,这样做更容易,也更不麻烦。

The one time I would choose using asp.net forms development would be to use the gridview control. We are using jquery for our javascript framework with MVC and have not yet found a very good gridview like control. We have something that is functional, but the amount of time we have sunk into learning, tweaking, and debugging it vs using asp.net server side controls has been substantial. One looses all of the nice widgets Microsoft provides out of the box doing non asp.net form development. The loss of those widgets is freeing, and scary at the same time when you first start.

我选择使用asp.net表单开发的一段时间是使用gridview控件。我们正在用jquery开发带有MVC的javascript框架,并且还没有找到一个像控件这样很好的gridview。我们有一些功能,但是我们花在学习、调整和调试上的时间比使用asp.net服务器端控件要多。一个人在做非asp.net表单开发时,就会失去微软提供的所有漂亮的小部件。这些小部件的丢失是一种解放,同时在您第一次启动时也是一种恐惧。

At the end of the day I'm happy we are doing MVC development. My team and I have learned a new framework, (we were only asp.net developers before), and have gotten our hands dirty with html and javascript. These are skills we can take onto other projects or other languages if we ever need to.

最后,我很高兴我们正在进行MVC开发。我和我的团队已经学习了一个新的框架(我们以前只是asp.net开发人员),并且我们已经接触了html和javascript。如果需要的话,这些技能我们可以应用到其他项目或其他语言上。

#2


10  

Don't let people fool you into thinking that it is a clear cut choice. You can get the best of both worlds. My approach is to create an MVC project, but instead of adding views, add standard asp.net pages, but change the code behind to inherit from MVC.ViewPage like so:

不要让别人欺骗你,认为这是一个明确的选择。你可以两全其美。我的方法是创建一个MVC项目,但不是添加视图,而是添加标准的asp.net页面,而是更改后面的代码以从MVC继承。:ViewPage一样:

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

If you confine yourself to the single form tag (with runat="server") in the code in front, then you have full code behind access to your standard asp.net server controls. This means you get full server side control of the presentation (eg. using databinding and repeaters) without having to do that old ASP-style code weaving.

如果您将自己限制在前面代码中的单个表单标记(使用runat="server"),那么在访问标准asp.net服务器控件之后,您将拥有完整的代码。这意味着您获得了表示的完整服务器端控制(例如。使用数据库和中继器)而不必进行旧的aspstyle代码编织。

    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();
    }

The post for any control does not post back to the page, but to the controller. If you remember to use the name property on your server controls then they end up in the FormControls collection for access to your page variables as per standard MVC.

任何控件的post都不会返回到页面,而是返回到控制器。如果您记得在您的服务器控件上使用name属性,那么它们最终会在formcontrol集合中以每个标准MVC的形式访问您的页面变量。

So what do you get?:

你得到了什么?

  • full server side control of presentation your code in front is purely HTML and asp.net server control tags
  • 完整的服务器端控制显示代码在前面是纯HTML和asp.net服务器控制标签。
  • full separation of concerns - the page does presentation only, and all orchestration and marshalling is done in the controller (rather than asp.net style in the page)
  • 完全分离关注点——页面只做表示,所有的编排和编组都是在控制器中完成的(而不是页面中的asp.net样式)
  • full MVC testability
  • 完整的MVC可测试性
  • No html code weaving
  • 没有html代码编织
  • You can tunr view state off and reduce page bloat
  • 您可以调整视图状态关闭并减少页面膨胀

What do you lose?

你失去什么?

  • Once again you are confined to one form per page if you want to use only server controls
  • 如果您希望仅使用服务器控件,则同样限制每个页面只能使用一个表单
  • You may need to manually specify postback targets for buttons and the form
  • 您可能需要手动为按钮和表单指定回发目标
  • You once again have 2 files for your presentation
  • 您的演示再次有两个文件

Oh, and for AJAX - jQuery definitely. Making a request to a controller method that returns a JsonResult really simplifies things.

对AJAX来说,jQuery绝对是。向返回JsonResult的控制器方法发出请求确实可以简化事情。

#3


9  

I love webforms, but ASP.NET AJAX is a pile of crap.

我喜欢网络表单,但是ASP。NET AJAX是一堆垃圾。

I prefer to use WebForms + custom HTTPHandlers handling the server side of any AJAX calls.

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

Heh, downvoted...

嘿,downvoted……

ASP.NET AJAX Is a pile of crap because a callback requires the entire page class to be reinstantiated, you aren't calling a single method, you are rebuilding the entire page on the server everytime.

ASP。NET AJAX是一堆垃圾,因为回调需要重新恢复整个页面类,您不是调用单个方法,而是每次都在服务器上重新构建整个页面。

Also, UpdatePanels return the entire page, only the section in the update panel is popped in, its a total waste of bandwidth.

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

I understand why its done this way, because WebForms controls can't really be easily other ways, but it still is really lousy.

我理解为什么它是这样做的,因为WebForms控件不能简单地用其他方式控制,但它仍然很糟糕。

#4


8  

I see that the majority of the responses came out prior to MVC 1.0. Since we are now in 2.0 Preview, I thought it might nice to revisit.

我看到大多数响应都是在MVC 1.0之前发出的。既然我们现在是在2.0预览版中,我认为有必要重新审视一下。

I was a ASP.NET developer for about five years before I made the move to MVC last March. I haven't regretted it for a second. I realize now that the stronger I got in ASP.NET WebForms, the more difficult it became to learn other technologies, such as JavaScript and the non-Microsoft implementation of AJAX. Microsoft leveraged their ASP.NET development approach from their WinForms development approach, which helped with the learning curve if you were coming from WebForms development, but it's not a good way to develop web applications if you understand the differences between the two approaches.

我是一个ASP。在我去年3月转向MVC之前,NET开发人员花了大约5年的时间。我一点也不后悔。我现在意识到,我在ASP中越强大。NET WebForms越难学习其他技术,比如JavaScript和AJAX的非microsoft实现。微软利用ASP。NET开发方法来自WinForms开发方法,如果您来自WebForms开发,这有助于学习曲线,但如果您理解这两种方法之间的差异,那么开发web应用程序就不是一个好方法。

The latest project I'm working required me to learn ASP.NET MVC, JavaScript, jQuery, CSS 2, and AJAX (non-Microsoft). After only nine months, I feel much better prepared to approach web development projects than I did after five years of ASP.NET development. The ASP.NET implementation makes things so much more difficult to maintain long-term. MVC makes things so much easier, because you're less dependent on shortcuts. It takes a while to learn the framework, but the more you learn about the framework, the less dependent on the framework you become and the more you start to learn and understand the established standards, like JavaScript and AJAX.

我最近的一个项目需要学习ASP。NET MVC、JavaScript、jQuery、CSS 2和AJAX(非microsoft)。仅仅9个月之后,我就觉得自己在处理web开发项目时比在使用了5年ASP之后准备得更好。网络的发展。ASP。净实现使事情很难长期保持下去。MVC使事情变得如此简单,因为您不太依赖快捷方式。学习框架需要一段时间,但是对框架了解得越多,对框架的依赖性就越小,就越能开始学习和理解已建立的标准,比如JavaScript和AJAX。

For me, it is a clear-cut choice. I will never go back to ASP.NET. If I can't use ASP.NET MVC, I'll learn Ruby or PHP. I want the progress and advancement of my web development tools to be motivated by the needs of the developer community, not by profit.

对我来说,这是一个明确的选择。我不会再回到ASP.NET。如果我不能使用ASP。NET MVC,我会学习Ruby或者PHP。我希望我的web开发工具的进展和进步是基于开发人员社区的需求,而不是利润。

#5


2  

ASP.NET MVC is still in "Preview" form, and as such I wouldn't consider it until it matures. You can roll-your-own MVP pattern pretty easily without much plumbing.

ASP。NET MVC仍然是“预览”形式,因此我在它成熟之前不会考虑它。你可以很容易地使用自己的MVP模式而不需要太多的管道。

On the Ajax front, I'd say try to find libraries (commercial or otherwise) that do what you're looking for. The basics (Grids, trees, autocomplete textboxes, etc.) have been done to death. Don't Reinvent The Wheel.

在Ajax方面,我想说的是尝试找到实现您所查找的功能的库(商业或其他)。基本的东西(网格、树、自动完成的文本框等)已经被彻底摧毁了。不要重新发明*。

#6


2  

When I am designing a site one of the big things I prefer is the DRY principle. IMO ASP.NET MVC is much more dry than web forms.

当我在设计一个网站时,我更喜欢干的原则。国际海事组织ASP。NET MVC比web表单要枯燥得多。

I have recently made the move from webforms to MVC and I hope I never have to go back!

我最近已经从webforms转移到MVC,我希望我再也不用回去了!

#7


2  

If you need update panel, I suggest you to use open source and lite MagicAjax or ComfortASP. If you need framework helps developing custom ajax, I suggest jQuery.

如果您需要更新面板,我建议您使用开源和lite MagicAjax或ComfortASP。如果您需要框架来帮助开发自定义ajax,我建议使用jQuery。

#8


1  

Webforms with ASP.NET Ajax is heaven. The integration between the 2 is just amazing and feels so natural to work with.

Webforms和ASP。净Ajax是天堂。两者之间的融合是令人惊叹的,并且让人感觉很自然。

Using webforms instead of mvc will give you the ability to utilize the lifecycle to develop very good and re-usable controls.

使用webforms而不是mvc将使您能够利用生命周期来开发非常好的、可重用的控件。

But I still like to add a little jQuery into the mix for traversing the dom and adding animations, I just like to use asp.net ajax to get the integration with the server side.

但是我仍然喜欢添加一点jQuery来遍历dom和添加动画,我只是喜欢使用asp.net ajax来获得与服务器端的集成。

#9


1  

The concept behind MVC is great, but be prepared to loose virtually all the functionality of all the server controls you've used for so many years. I've only looked at the MVC implementation for about a week now, but the page lifecycle and view state are gone so these controls no longer function properly.

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

I was also stunned to find a number of examples containing a lot of logic code in the markup. That's right, 'if' and 'foreach' statements in the aspx files -- a horrible step backwards imho. I was very happy to leave classic asp behind but in the current implementation of the asp.net mvc pattern you're back to code in your markup, the need to use helpers everywhere, and the lack of virtually any useable server controls.

我还惊讶地发现,在标记中包含许多逻辑代码的示例。没错,aspx文件中的“if”和“foreach”语句——这是一个可怕的倒退。我非常高兴地离开了经典的asp,但是在当前asp.net mvc模式的实现中,您又回到了标记的代码,需要在任何地方使用助手,以及缺乏几乎任何可用的服务器控件。

If you're starting a new project now I'd recommend sticking with asp.net webforms and make use of a the built in asp.net ajax, the toolkit, and jQuery as needed. The asp.net ajax implementation may not be the absolute best, or most efficient implementation, but unless you're getting a million uniques on day 1 or your server is a commodore vic 20 the performance hit isn't going to be that noticeable.

如果您现在正在启动一个新项目,我建议您坚持使用asp.net webforms,并根据需要使用asp.net ajax、工具包和jQuery内置的工具。asp.net ajax实现可能不是绝对最好的,或者是最有效的实现,但是除非您在第一天就获得了一百万的uniques 20,或者您的服务器是commodore vic 20,否则性能上的冲击不会那么明显。

This of course does depend on your project size. If you're starting a 5 year Enterprise level application that expect millions of page views, UpdatePanel might not cut it, but if you're building an average site, throwing up a prototype, or just need to get moving fast, asp.net ajax works perfectly fine and has an extremely low learning curve.

这当然取决于您的项目大小。如果您正在启动一个5年的企业级应用程序,预计会有数百万的页面浏览量,那么UpdatePanel可能不会影响它,但是如果您正在构建一个普通的站点,抛出一个原型,或者只是需要快速移动,那么asp.net ajax工作得非常好,学习曲线非常低。

And to be clear, the entire page is absolutely not returned every time an ajax call is made. /Only/ the content for the panel that needs to be updated is sent across the wire. Any http monitor will prove this point. Yes, the page /lifecycle/ is performed, but knowing that you can can build fairly efficient asp.net ajax applications.

而且要清楚的是,每次ajax调用时,整个页面绝对不会返回。/Only/需要更新的面板的内容是通过网络发送的。任何http监视器都将证明这一点。是的,页面/生命周期/被执行,但是知道您可以构建相当高效的asp.net ajax应用程序。

#10


1  

My experience has been with programming web apps for apache servers in php and ruby. When I got a job maintaining a web app written in asp.net (webforms), I dove into learning the microsoft way of building web apps. I will have to say I was completely mortified! I was thinking WTF is all this viewstate garbage being sent back in forth? Is this even necessary?

我的经验是在php和ruby中为apache服务器编程web应用程序。当我找到一份在asp.net (webforms)中编写的web应用程序的工作时,我开始学习微软构建web应用程序的方法。我得说我完全被羞辱了!我在想WTF是不是所有的viewstate垃圾都被来回发送?这是甚至是必要的吗?

And then I decided to look at doing some simple things with ajax and jquery, which lead me to update panels and clientIDs being generated, and not what I set in the view. What a waste of my time! Why can't I have multiple forms on one page? Why can't I just use regular ajax calls? Why do my views have server logic? These were all questions that im sure that many web programmers face with asp.net webforms. Then, I discovered .NET MVC. My life just got a lot easier.

然后我决定用ajax和jquery来做一些简单的事情,这让我更新了面板和clientIDs,而不是我在视图中设置的。真是浪费我的时间!为什么我不能在一页上有多个表单?为什么我不能使用常规的ajax调用呢?为什么我的视图具有服务器逻辑?这些都是我确信许多web程序员在使用asp.net webforms时要面对的问题。然后,我发现了。net MVC。我的生活简单多了。

I was used to using MVC frameworks like Rails and CakePHP to create web apps the way they were meant to be programmed. With technologies actually meant for the web.

我习惯了使用像Rails和CakePHP这样的MVC框架来创建web应用程序,就像它们应该被编程的那样。技术实际上是为网络服务的。

My suggestion would be this, Leave WebForms for people that are used to programming winforms type applications because it tries to abstract the fact that you are programming on the web. If you want to have real freedom to develop applications for the web which actually make sense to web programmers, use .NET MVC or something similar that wont get in your way.

我的建议是,把WebForms留给那些习惯编程winforms类型应用的人因为它试图抽象出你在web上编程的事实。如果你想要真正*地为web开发对web程序员有意义的应用程序,使用。net MVC或类似的东西不会妨碍你。

Thats my two cents...

这是我的两美分…

#11


1  

to compliment @ben's answer, I used ASP.Net webforms for simple databinding, and JQuery for all Ajax transactions. To be honest, I still couldn't let go of databinding because of its simplicity. Viewstate is almost useless so I basically turn it off. You can use MVC though, but be warned, it will take most of your time developing functionality that you take for granted in Forms. Good luck man!

为了赞扬本的回答,我用了ASP。Net webforms for simple databinding, JQuery for all Ajax事务。老实说,我还是不能放弃数据库,因为它很简单。Viewstate几乎是无用的,所以我基本上关闭了它。您可以使用MVC,但是需要注意的是,开发表单中您认为理所当然的功能将花费您大部分的时间。好运的男人!

#12


0  

I've used asp.net winforms with ajax.net as well as prototype/ext/jquery. I guess something to consider is the goal of the site.. MVC is a popular pattern. I can't say anything against ASP MVC because I haven't had a chance to use it, but I want to make sure you know you are not limited to just ajax.net if you chose webforms.

我使用了asp.net winforms和ajax.net以及prototype/ext/jquery。我想网站的目标是……MVC是一种流行的模式。我不能反对ASP MVC,因为我还没有机会使用它,但是我想确保您知道,如果您选择了webforms,您并不局限于ajax.net。net。

#13


0  

I agree that asp.net ajax UpdatePanels are not an ideal solution.

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

We have avoided using them and instead have been using the client-side libraries to do any communication with the server. I do like what I saw at PDC about the features coming in asp.net ajax 4.0 with declarative components and client-side templating - very nice! Combining JQuery with the existing libraries provides quite a bit - and I have questioned using JQuery exclusively instead given it's much smaller footprint and it's ability to do a lot of the same things as the asp.net ajax client library.

我们避免使用它们,而是使用客户端库与服务器进行任何通信。我喜欢我在PDC上看到的关于asp.net ajax 4.0中带有声明性组件和客户端模板的特性——非常棒!将JQuery与现有库结合在一起提供了相当多的功能——而且我还对仅使用JQuery提出了质疑,因为它的占用空间要小得多,而且它能够做很多与asp.net ajax客户端库相同的事情。

As far as the server stack - I haven't used MVC yet, but we have had success using a home-rolled MVP approach using webforms.

至于服务器堆栈——我还没有使用MVC,但是我们已经成功地使用了使用webforms的自制MVP方法。

#14


0  

It's been a long time since the original question. Now we have MVC3 and .NET 4

从最初的问题到现在已经有很长时间了。现在我们有了MVC3和。net 4

Is MVC now a better solution than before?

MVC现在比以前更好吗?

#1


29  

I've done both lately, I would take MVC nine times out of ten.

我最近两样都做过,十次中有九次是MVC。

  • I really dislike the implementation of the asp.net ajax controls, I've run into a lot of issues with timing, events, and debugging postback issues. I learned a lot from http://encosia.com/2007/07/11/why-aspnet-ajax-updatepanels-are-dangerous/
  • 我真的不喜欢asp.net ajax控件的实现,我遇到了很多时间、事件和调试回发问题。我从http://encosia.com/2007/07/11/why-aspnet-ajax-updatepanel -are-dangerous/中学到了很多
  • The asp.net project we used the MVP pattern http://www.codeplex.com/aspnetmvp, and the pattern worked great. However we ended up with a lot of code in the view because we were directly interacting with the server side controls (i.e a lot of gridview manipulations). This code is nearly untestable with the unit test frameworks. We should have been more diligent about keeping code out of the view, but in some instances it was just easier and less messy.
  • net项目我们使用了MVP模式http://www.codeplex.com/aspnetmvp,这个模式非常有效。但是,由于我们直接与服务器端控件交互(i),所以最终在视图中产生了大量代码。大量的gridview操作)。这段代码在单元测试框架中几乎是不可测试的。我们本应该更加努力地将代码从视图中排除出去,但在某些情况下,这样做更容易,也更不麻烦。

The one time I would choose using asp.net forms development would be to use the gridview control. We are using jquery for our javascript framework with MVC and have not yet found a very good gridview like control. We have something that is functional, but the amount of time we have sunk into learning, tweaking, and debugging it vs using asp.net server side controls has been substantial. One looses all of the nice widgets Microsoft provides out of the box doing non asp.net form development. The loss of those widgets is freeing, and scary at the same time when you first start.

我选择使用asp.net表单开发的一段时间是使用gridview控件。我们正在用jquery开发带有MVC的javascript框架,并且还没有找到一个像控件这样很好的gridview。我们有一些功能,但是我们花在学习、调整和调试上的时间比使用asp.net服务器端控件要多。一个人在做非asp.net表单开发时,就会失去微软提供的所有漂亮的小部件。这些小部件的丢失是一种解放,同时在您第一次启动时也是一种恐惧。

At the end of the day I'm happy we are doing MVC development. My team and I have learned a new framework, (we were only asp.net developers before), and have gotten our hands dirty with html and javascript. These are skills we can take onto other projects or other languages if we ever need to.

最后,我很高兴我们正在进行MVC开发。我和我的团队已经学习了一个新的框架(我们以前只是asp.net开发人员),并且我们已经接触了html和javascript。如果需要的话,这些技能我们可以应用到其他项目或其他语言上。

#2


10  

Don't let people fool you into thinking that it is a clear cut choice. You can get the best of both worlds. My approach is to create an MVC project, but instead of adding views, add standard asp.net pages, but change the code behind to inherit from MVC.ViewPage like so:

不要让别人欺骗你,认为这是一个明确的选择。你可以两全其美。我的方法是创建一个MVC项目,但不是添加视图,而是添加标准的asp.net页面,而是更改后面的代码以从MVC继承。:ViewPage一样:

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

If you confine yourself to the single form tag (with runat="server") in the code in front, then you have full code behind access to your standard asp.net server controls. This means you get full server side control of the presentation (eg. using databinding and repeaters) without having to do that old ASP-style code weaving.

如果您将自己限制在前面代码中的单个表单标记(使用runat="server"),那么在访问标准asp.net服务器控件之后,您将拥有完整的代码。这意味着您获得了表示的完整服务器端控制(例如。使用数据库和中继器)而不必进行旧的aspstyle代码编织。

    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();
    }

The post for any control does not post back to the page, but to the controller. If you remember to use the name property on your server controls then they end up in the FormControls collection for access to your page variables as per standard MVC.

任何控件的post都不会返回到页面,而是返回到控制器。如果您记得在您的服务器控件上使用name属性,那么它们最终会在formcontrol集合中以每个标准MVC的形式访问您的页面变量。

So what do you get?:

你得到了什么?

  • full server side control of presentation your code in front is purely HTML and asp.net server control tags
  • 完整的服务器端控制显示代码在前面是纯HTML和asp.net服务器控制标签。
  • full separation of concerns - the page does presentation only, and all orchestration and marshalling is done in the controller (rather than asp.net style in the page)
  • 完全分离关注点——页面只做表示,所有的编排和编组都是在控制器中完成的(而不是页面中的asp.net样式)
  • full MVC testability
  • 完整的MVC可测试性
  • No html code weaving
  • 没有html代码编织
  • You can tunr view state off and reduce page bloat
  • 您可以调整视图状态关闭并减少页面膨胀

What do you lose?

你失去什么?

  • Once again you are confined to one form per page if you want to use only server controls
  • 如果您希望仅使用服务器控件,则同样限制每个页面只能使用一个表单
  • You may need to manually specify postback targets for buttons and the form
  • 您可能需要手动为按钮和表单指定回发目标
  • You once again have 2 files for your presentation
  • 您的演示再次有两个文件

Oh, and for AJAX - jQuery definitely. Making a request to a controller method that returns a JsonResult really simplifies things.

对AJAX来说,jQuery绝对是。向返回JsonResult的控制器方法发出请求确实可以简化事情。

#3


9  

I love webforms, but ASP.NET AJAX is a pile of crap.

我喜欢网络表单,但是ASP。NET AJAX是一堆垃圾。

I prefer to use WebForms + custom HTTPHandlers handling the server side of any AJAX calls.

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

Heh, downvoted...

嘿,downvoted……

ASP.NET AJAX Is a pile of crap because a callback requires the entire page class to be reinstantiated, you aren't calling a single method, you are rebuilding the entire page on the server everytime.

ASP。NET AJAX是一堆垃圾,因为回调需要重新恢复整个页面类,您不是调用单个方法,而是每次都在服务器上重新构建整个页面。

Also, UpdatePanels return the entire page, only the section in the update panel is popped in, its a total waste of bandwidth.

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

I understand why its done this way, because WebForms controls can't really be easily other ways, but it still is really lousy.

我理解为什么它是这样做的,因为WebForms控件不能简单地用其他方式控制,但它仍然很糟糕。

#4


8  

I see that the majority of the responses came out prior to MVC 1.0. Since we are now in 2.0 Preview, I thought it might nice to revisit.

我看到大多数响应都是在MVC 1.0之前发出的。既然我们现在是在2.0预览版中,我认为有必要重新审视一下。

I was a ASP.NET developer for about five years before I made the move to MVC last March. I haven't regretted it for a second. I realize now that the stronger I got in ASP.NET WebForms, the more difficult it became to learn other technologies, such as JavaScript and the non-Microsoft implementation of AJAX. Microsoft leveraged their ASP.NET development approach from their WinForms development approach, which helped with the learning curve if you were coming from WebForms development, but it's not a good way to develop web applications if you understand the differences between the two approaches.

我是一个ASP。在我去年3月转向MVC之前,NET开发人员花了大约5年的时间。我一点也不后悔。我现在意识到,我在ASP中越强大。NET WebForms越难学习其他技术,比如JavaScript和AJAX的非microsoft实现。微软利用ASP。NET开发方法来自WinForms开发方法,如果您来自WebForms开发,这有助于学习曲线,但如果您理解这两种方法之间的差异,那么开发web应用程序就不是一个好方法。

The latest project I'm working required me to learn ASP.NET MVC, JavaScript, jQuery, CSS 2, and AJAX (non-Microsoft). After only nine months, I feel much better prepared to approach web development projects than I did after five years of ASP.NET development. The ASP.NET implementation makes things so much more difficult to maintain long-term. MVC makes things so much easier, because you're less dependent on shortcuts. It takes a while to learn the framework, but the more you learn about the framework, the less dependent on the framework you become and the more you start to learn and understand the established standards, like JavaScript and AJAX.

我最近的一个项目需要学习ASP。NET MVC、JavaScript、jQuery、CSS 2和AJAX(非microsoft)。仅仅9个月之后,我就觉得自己在处理web开发项目时比在使用了5年ASP之后准备得更好。网络的发展。ASP。净实现使事情很难长期保持下去。MVC使事情变得如此简单,因为您不太依赖快捷方式。学习框架需要一段时间,但是对框架了解得越多,对框架的依赖性就越小,就越能开始学习和理解已建立的标准,比如JavaScript和AJAX。

For me, it is a clear-cut choice. I will never go back to ASP.NET. If I can't use ASP.NET MVC, I'll learn Ruby or PHP. I want the progress and advancement of my web development tools to be motivated by the needs of the developer community, not by profit.

对我来说,这是一个明确的选择。我不会再回到ASP.NET。如果我不能使用ASP。NET MVC,我会学习Ruby或者PHP。我希望我的web开发工具的进展和进步是基于开发人员社区的需求,而不是利润。

#5


2  

ASP.NET MVC is still in "Preview" form, and as such I wouldn't consider it until it matures. You can roll-your-own MVP pattern pretty easily without much plumbing.

ASP。NET MVC仍然是“预览”形式,因此我在它成熟之前不会考虑它。你可以很容易地使用自己的MVP模式而不需要太多的管道。

On the Ajax front, I'd say try to find libraries (commercial or otherwise) that do what you're looking for. The basics (Grids, trees, autocomplete textboxes, etc.) have been done to death. Don't Reinvent The Wheel.

在Ajax方面,我想说的是尝试找到实现您所查找的功能的库(商业或其他)。基本的东西(网格、树、自动完成的文本框等)已经被彻底摧毁了。不要重新发明*。

#6


2  

When I am designing a site one of the big things I prefer is the DRY principle. IMO ASP.NET MVC is much more dry than web forms.

当我在设计一个网站时,我更喜欢干的原则。国际海事组织ASP。NET MVC比web表单要枯燥得多。

I have recently made the move from webforms to MVC and I hope I never have to go back!

我最近已经从webforms转移到MVC,我希望我再也不用回去了!

#7


2  

If you need update panel, I suggest you to use open source and lite MagicAjax or ComfortASP. If you need framework helps developing custom ajax, I suggest jQuery.

如果您需要更新面板,我建议您使用开源和lite MagicAjax或ComfortASP。如果您需要框架来帮助开发自定义ajax,我建议使用jQuery。

#8


1  

Webforms with ASP.NET Ajax is heaven. The integration between the 2 is just amazing and feels so natural to work with.

Webforms和ASP。净Ajax是天堂。两者之间的融合是令人惊叹的,并且让人感觉很自然。

Using webforms instead of mvc will give you the ability to utilize the lifecycle to develop very good and re-usable controls.

使用webforms而不是mvc将使您能够利用生命周期来开发非常好的、可重用的控件。

But I still like to add a little jQuery into the mix for traversing the dom and adding animations, I just like to use asp.net ajax to get the integration with the server side.

但是我仍然喜欢添加一点jQuery来遍历dom和添加动画,我只是喜欢使用asp.net ajax来获得与服务器端的集成。

#9


1  

The concept behind MVC is great, but be prepared to loose virtually all the functionality of all the server controls you've used for so many years. I've only looked at the MVC implementation for about a week now, but the page lifecycle and view state are gone so these controls no longer function properly.

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

I was also stunned to find a number of examples containing a lot of logic code in the markup. That's right, 'if' and 'foreach' statements in the aspx files -- a horrible step backwards imho. I was very happy to leave classic asp behind but in the current implementation of the asp.net mvc pattern you're back to code in your markup, the need to use helpers everywhere, and the lack of virtually any useable server controls.

我还惊讶地发现,在标记中包含许多逻辑代码的示例。没错,aspx文件中的“if”和“foreach”语句——这是一个可怕的倒退。我非常高兴地离开了经典的asp,但是在当前asp.net mvc模式的实现中,您又回到了标记的代码,需要在任何地方使用助手,以及缺乏几乎任何可用的服务器控件。

If you're starting a new project now I'd recommend sticking with asp.net webforms and make use of a the built in asp.net ajax, the toolkit, and jQuery as needed. The asp.net ajax implementation may not be the absolute best, or most efficient implementation, but unless you're getting a million uniques on day 1 or your server is a commodore vic 20 the performance hit isn't going to be that noticeable.

如果您现在正在启动一个新项目,我建议您坚持使用asp.net webforms,并根据需要使用asp.net ajax、工具包和jQuery内置的工具。asp.net ajax实现可能不是绝对最好的,或者是最有效的实现,但是除非您在第一天就获得了一百万的uniques 20,或者您的服务器是commodore vic 20,否则性能上的冲击不会那么明显。

This of course does depend on your project size. If you're starting a 5 year Enterprise level application that expect millions of page views, UpdatePanel might not cut it, but if you're building an average site, throwing up a prototype, or just need to get moving fast, asp.net ajax works perfectly fine and has an extremely low learning curve.

这当然取决于您的项目大小。如果您正在启动一个5年的企业级应用程序,预计会有数百万的页面浏览量,那么UpdatePanel可能不会影响它,但是如果您正在构建一个普通的站点,抛出一个原型,或者只是需要快速移动,那么asp.net ajax工作得非常好,学习曲线非常低。

And to be clear, the entire page is absolutely not returned every time an ajax call is made. /Only/ the content for the panel that needs to be updated is sent across the wire. Any http monitor will prove this point. Yes, the page /lifecycle/ is performed, but knowing that you can can build fairly efficient asp.net ajax applications.

而且要清楚的是,每次ajax调用时,整个页面绝对不会返回。/Only/需要更新的面板的内容是通过网络发送的。任何http监视器都将证明这一点。是的,页面/生命周期/被执行,但是知道您可以构建相当高效的asp.net ajax应用程序。

#10


1  

My experience has been with programming web apps for apache servers in php and ruby. When I got a job maintaining a web app written in asp.net (webforms), I dove into learning the microsoft way of building web apps. I will have to say I was completely mortified! I was thinking WTF is all this viewstate garbage being sent back in forth? Is this even necessary?

我的经验是在php和ruby中为apache服务器编程web应用程序。当我找到一份在asp.net (webforms)中编写的web应用程序的工作时,我开始学习微软构建web应用程序的方法。我得说我完全被羞辱了!我在想WTF是不是所有的viewstate垃圾都被来回发送?这是甚至是必要的吗?

And then I decided to look at doing some simple things with ajax and jquery, which lead me to update panels and clientIDs being generated, and not what I set in the view. What a waste of my time! Why can't I have multiple forms on one page? Why can't I just use regular ajax calls? Why do my views have server logic? These were all questions that im sure that many web programmers face with asp.net webforms. Then, I discovered .NET MVC. My life just got a lot easier.

然后我决定用ajax和jquery来做一些简单的事情,这让我更新了面板和clientIDs,而不是我在视图中设置的。真是浪费我的时间!为什么我不能在一页上有多个表单?为什么我不能使用常规的ajax调用呢?为什么我的视图具有服务器逻辑?这些都是我确信许多web程序员在使用asp.net webforms时要面对的问题。然后,我发现了。net MVC。我的生活简单多了。

I was used to using MVC frameworks like Rails and CakePHP to create web apps the way they were meant to be programmed. With technologies actually meant for the web.

我习惯了使用像Rails和CakePHP这样的MVC框架来创建web应用程序,就像它们应该被编程的那样。技术实际上是为网络服务的。

My suggestion would be this, Leave WebForms for people that are used to programming winforms type applications because it tries to abstract the fact that you are programming on the web. If you want to have real freedom to develop applications for the web which actually make sense to web programmers, use .NET MVC or something similar that wont get in your way.

我的建议是,把WebForms留给那些习惯编程winforms类型应用的人因为它试图抽象出你在web上编程的事实。如果你想要真正*地为web开发对web程序员有意义的应用程序,使用。net MVC或类似的东西不会妨碍你。

Thats my two cents...

这是我的两美分…

#11


1  

to compliment @ben's answer, I used ASP.Net webforms for simple databinding, and JQuery for all Ajax transactions. To be honest, I still couldn't let go of databinding because of its simplicity. Viewstate is almost useless so I basically turn it off. You can use MVC though, but be warned, it will take most of your time developing functionality that you take for granted in Forms. Good luck man!

为了赞扬本的回答,我用了ASP。Net webforms for simple databinding, JQuery for all Ajax事务。老实说,我还是不能放弃数据库,因为它很简单。Viewstate几乎是无用的,所以我基本上关闭了它。您可以使用MVC,但是需要注意的是,开发表单中您认为理所当然的功能将花费您大部分的时间。好运的男人!

#12


0  

I've used asp.net winforms with ajax.net as well as prototype/ext/jquery. I guess something to consider is the goal of the site.. MVC is a popular pattern. I can't say anything against ASP MVC because I haven't had a chance to use it, but I want to make sure you know you are not limited to just ajax.net if you chose webforms.

我使用了asp.net winforms和ajax.net以及prototype/ext/jquery。我想网站的目标是……MVC是一种流行的模式。我不能反对ASP MVC,因为我还没有机会使用它,但是我想确保您知道,如果您选择了webforms,您并不局限于ajax.net。net。

#13


0  

I agree that asp.net ajax UpdatePanels are not an ideal solution.

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

We have avoided using them and instead have been using the client-side libraries to do any communication with the server. I do like what I saw at PDC about the features coming in asp.net ajax 4.0 with declarative components and client-side templating - very nice! Combining JQuery with the existing libraries provides quite a bit - and I have questioned using JQuery exclusively instead given it's much smaller footprint and it's ability to do a lot of the same things as the asp.net ajax client library.

我们避免使用它们,而是使用客户端库与服务器进行任何通信。我喜欢我在PDC上看到的关于asp.net ajax 4.0中带有声明性组件和客户端模板的特性——非常棒!将JQuery与现有库结合在一起提供了相当多的功能——而且我还对仅使用JQuery提出了质疑,因为它的占用空间要小得多,而且它能够做很多与asp.net ajax客户端库相同的事情。

As far as the server stack - I haven't used MVC yet, but we have had success using a home-rolled MVP approach using webforms.

至于服务器堆栈——我还没有使用MVC,但是我们已经成功地使用了使用webforms的自制MVP方法。

#14


0  

It's been a long time since the original question. Now we have MVC3 and .NET 4

从最初的问题到现在已经有很长时间了。现在我们有了MVC3和。net 4

Is MVC now a better solution than before?

MVC现在比以前更好吗?