0

Being a PHP guy myself I recently had to write a spider to an asp.net site. I was really surprised by the different approach to ajax and form-handling.

For example, in the PHP sites I've worked with, a deletion of a database entry would be something like: 

GET delete.php?id=&confirm=yes
and get a "success" back in some form (in the ajax case, probably a json reply).

In this asp.net application you would instead post a form, including all inputs on the page, with a huge __VIEWSTATE and __EVENTVALIDATION. This would be more than 10 times as big as above.

The reply would be the complete side again, with a footer containing some structured data for javascript to parse and display the result. Again, the whole page is sent, and then throwed away(?) since it's already displayed. Why not just send the footer with the data to parse (it's not json nor xml but a | separated list).

I really can't see why you would design a system that way. Usually you've a fast client, and a somewhat fast server but a really slow connection. Why not keep the datatransfer to a minimum? Why those huge __VIEWSTATE and __EVENTVALIDATION?

It seems that everything is done way to chatty and way to complicated. I really can't see the point and that usually means that I'm missing something. So please tell me, what are the reasons for this design and what benefits (and weaknesses) does it have?

(Yes I know that __VIEWSTATE is used to tell what type of form-konfiguration should be sent back to the server. But WHY is this needed?)

Please keep this discussion strictly technical and avoid flamewars.

Update:

Please excuse the somewhat rantish question. I tried to explain my view to be able to get a better answer. I am not saying that asp.net is bad, I am saying that I don't understand the meaning of those concepts. Usually that means that I've things to learn instead of the concepts beeing wrong.

I appreciate the explanations about that "you don't have to do this way in asp.net", I'll read up on MVC and other .net technologies. However, there most be a reason for this site (the one I referred to) to be written the way it is. It's written by professionals for a big organisation with far more experience than what I've. Any explanation about their (possible) design choice would be welcome.

iveqy
  • 468

3 Answers3

8

Webforms was designed in a time when people wanted web applications to look like windows applications. This was a dark time on the internet where developers were forced to learn page lifecycles and deal with horrible view states and 3rd party controls which would cause such bloat the very fabric of the internet would be shaken...

That is Webforms, an archaic technology that is better left forgotten, and people who say otherwise should also be forgotten.

Like another answer says, MVC is the latest way from MS (although it was pretty much just spawned from Ruby on Rails I think) to design good websites.

Anyway the "Why is MVC great" is another topic, but for this one the answer is.

YES WEBFORMS IS AWFUL DO NOT USE IT FOR NEW PROJECTS

Grofit
  • 863
6

Please keep this discussion strictly technical and avoid flamewars.

We'll see ;) (As Bart van Ingen Schenau points out, your question is a little ranty, which may not help the situation)

You're actually referring to ASP.NET Webforms. ASP.NET doesn't suck at all; MVC is great (and doesn't share the problem you mention).

You're right that the ViewState is large and seems like a nuisance to work with. In a way it can be for developers too. Why was it developed this way? Well it can be useful - I suspect particularly for developers coming from Winforms; the web behaves fundamentally differently from desktop applications but Microsoft tried to mimic the behaviour with abstractions like the ViewState (a big object to keep track of where everything is at). The large Viewstate being passed around is also less of an issue with things like Intranets (where Webforms may be fairly common).

A great discussion and comparison of the two is answered in this question: When to favor ASP.NET WebForms over MVC. Why it was designed this way is also mentioned.

Community
  • 1
Rowan Freeman
  • 3,488
0

I think that there is a simple answer to this, in my view its not so much that its bad as that the choices - compromises - that they made in order to produce a productive framework are not ones that you agree with.

That said the ease with which you can do (and I have done) really stupid things and the amount of bloat that you can trivially add to a page are good arguments for why its flawed.

The flip side of this is that you can do a lot of clever things with not a lot of effort - and if you're targeting a focused site for internal use for a business as opposed to a wider public facing website then the productivity gains can be a huge win.

With the ongoing development of the webforms framework and with developers that have a clue you don't now have to produce poor bloated pages any more either (though lots of people still will).

Murph
  • 7,843