Jeremy D. Miller -- The Shade Tree Developer

Pingback from  » It's Smart to Challenge the ASP.NET Status Quo

That questions are now answered even by Microsoft with the MVC project.

But I actually believe the WebForms model was a brilliant idea when .net was in beta stage. A layer of abstraction for fighting the differences between browsers ( IE, Netscape... )

Imagine yourself building a web framework 7 years ago and now hearing people talking about how it is outdated... of course it is !!! :-)

I'm currently on a contract trying to breath some life into a thoroughly mangled ASP.NET application.  Having seen the equivalent in ASP, I wondered just a few days ago if it was really better under ASP.NET.  With WebForms, you have more complexity, and more ways for inexperienced and unskilled developers to get it wrong.  A big part of what was wrong with ASP was how people were designing applications with it, and not necessarily the technology itself.  I think you can grok ASP *much* quicker than ASP.NET today.  You can write clean ASP pages, but it requires discipline.

ASP made developers think in a top-down way, e.g. Response.Writing the page from the opening html tag onwards and throwing in bits of business logic along the way. Sure, templating and COM could be used by the conscientious among us, but there was very little to encourage clean and reusable UI code.

With ASP.Net we have a fully fledged OO language, allowing real software development principles to be applied to UI development. You can't equate WebForms solely with design-time RAD shennanigans (MS certified or otherwise). As always, it's what you make of it, but with ASP.Net WebForms that "it" is now a lot more powerful. There are a many cross-cutting concerns that have been addressed by abstractions in the WebForms model and they are there to be taken advantage of.

1) Is the WebForms approach of considering the page as a hierarchy of page elements (controls) a bad thing, when you compare the alternatives? This is, after all, what the cool AJAX kids are doing with client-side DOM manipulation.

2) In turn, this allows us to develop reusable page elements in the form of WebControls/UserControls. The control hierarchy allows you to break down a page into a set of components in a way that observes SRP (e.g. controls that care about one thing, such as generating HTML from data supplied via a public property without caring about anything else) and the responsibility driven design approach (some controls are "displayers", others play a "coordinator" role by handing off events between other controls).

3) In turn (again), some kind of element id generation is crucial if you're writing re-usable elements, from something as trivial as a calendar control onwards. Is the INamingContainer solution such a bad thing? It is not that hard to inject the ClientID of a control into your JavaScript code. Is it that bad that your controls are automatically assigned an id like "control1_summary_price_item1_startdate. What is the alternative? Maybe a more open-sourcy solution will use a different character to the underscore and people will love it.

4) The controversial ViewState is basically an abstraction of manually adding hidden form fields. In principal this is not evil. ASP.Net out of the box encourages you to rely too much on this feature. However my main point is that Webforms allows you to write pages that aren't overly reliant on unnecessary viewstate.

I don't understand why the entries for the recent "Be the 50th Person to Write a Negative Article about WebForms with the Term 'Leaky Abstraction' in it" competition do not take these advances into account.

The root cause of UI spaghetti code on any platform is a lack of discipline and attention to well-known software design principles (especially something as simple as DRY). Is it because the more experienced coders tend to move towards what are seen as more complex areas of development like the domain layer, while the juniors are left to "just" generate the HTML?

I've been asking this same question for some time now. There are things I really like about ASP.Net and I wouldn't go back to classic ASP by choice, but ASP.Net certainly made something that was already somewhat complicated and made it even more complicated.

The separation between the UI and code in ASP.Net makes it much easier for experienced ASP.Net developers to maintain the code, but the learning curve is much higher with ASP.Net and their seems to be far more opportunities to really screw things up than in classic ASP.

I haven't had a chance to really look at the new MVC architecture that Microsoft is putting out, but it seems pretty cool. However I fear that we are adding another layer of abstraction on top of ASP.Net.

As long as developers are paired with more experienced developers while they are learning and stick with a platform long enough to be good at it this additional complexity is ok (the additional features are good!), but I feel pity for the poor suckers that have to maintain my first ASP.Net application :).

"To be honest, I'm [mostly] a spectator in this argument because I've barely done any web development since 2002."  Quoted for effect.  If you aren't doing ASP.NET development, please don't tell us who actually do it for a living what we "should" do.

The new MVC is not the answer it’s too far in the other direction, MVC is a great concept, was doing it in ASP before I even knew what MVC was.  What we really need is a new web form model that uses MVC at the control level.

MSTest is bad, but MVC is good. Why? Coz Soctt revealed it to ALT.Net folks first? Funny indeed.

WebForms code behind is already a form of MVC.  The .aspx page is your view, the .aspx.cs page is your controller.    You can build asp.net with this very seperated... the code behind in completley seperate modules even.  I believe the CommunityServer project is built this way, if I recall correctly.

I never did ASP.  I was involved in the infrastructure side of the house back then trying to keep ASP apps running.  There's no way I'd go back.  The ASP model was so badly flawed from the start, such that even the simplest of applications would inevitably fail in a catastropic manner.  Not because of coding problems, but because the OS/IIS would take a dump.  This was a side-effect of COM and how dreadfully awful that was.

What's wonderful about .NET, IMHO, is that we can have discussions about how we should use it.  We can experiment with different models, and are not stuck being able to use it only in one way or another.

The introduction of AJAX has made things worse, in that now one page can contain multiple discrete functions.  So even your code behind can become spaghetti.  I've been working with the MVP pattern in recent months, and I find that eases much pain.

But as others have pointed out, these layers of abstraction make it much harder to learn how to program in .Net.  There is a steep learning curve.

@Dan

The big problem with ASP.NET Webforms as they exist now isn't with the object representation of the HTML page, it's with cramming the nice OO model into a procedural page lifecycle. Once you need to do something out of sync with the page lifecycle, say create controls dynamically and have them remember their state between postbacks, the pain becomes very real and evident. And that's just a simple example. When you get into unit/functional testing, the pain becomes even greater.

"I'd very strongly disagree with that statement.  I like having the code behind, and in WinForms too now, but the code behind is VIEW code, not a controller.  The idea that the code behind is an equivalent to MVC separation of concerns is a myth."

Not saying it's pretty, but that did seem to be the intent of Microsoft when they came up with the code-behind model.

"Since we all make far more than the average worker, don't you think we can really expect a little bit of learning in order to work more effectively?  Is MVC or MVP really hard, or just strange because it's not that well known?"

Yes, it's why we get the big bucks.  What I find more interesting.  I go to an MSDN event or some user group thing at the Microsoft office, and I look around and everybody is well over 30.  The youth is non-existent.    I think MS is facing the problem that every "enterprise" product maker faces, and it's hard to start up in it. So we make it harder, more encompassing, and we lose the n00bs.  The n00bs go off and program in [something else], which they then start clamoring for more and more and more stuff, and in time as they get older it becomes the enterprise product maker and at age 45 they look around and wonder where everybody else is.

Think about it a bit.  I guess the point is, having those avenues for people to quick throw something together even if you regard it as shit, is a path to bring people in that you can train in the ways of yoda.

   *  WebForms out of the box doesn't do much to promote separation of concerns either, so what did we really improve?

   > We improved separation of concerns by having a App_Code and App_Data folder where you can put your model and controller code. (separated by object orientation)

   * If we'd beaten the spaghetti code problem in ASP classic instead of drastically changing the UI model, would we be better off today?

 > That problem was even solved by asp.net 1.1, you can just separate everything in classes and projects. There's never the need to spread your code through clumsy .asp files.

   * Might we actually be better off working directly with HTML elements and JavaScript than trying to use a very complicated set of abstractions on top of HTML?

  > asp.net has something called a .aspx file, you can edit it to be working directly on HTML elements like any other webdevelopers language. Low level controls like the repeater and masterpages will give you a lot of control over your rendered HTML, if you want to go quick and dirty you can use the premade usercontrols.

   * Is Visual Programming really the fastest way to build software?  Because if it's not, we need to rethink most of the .Net tooling.

   > I don't think any webdeveloper actually uses the visual programming features of visual studio for more than dragging the premade or selfmade controls to the place they desire configuring them but then further tweak them in codebehind, because you can't make a cross browser website without looking at your html.

   * Is Visual Programming really the most approachable way to build software?

  > Does anyone claim it is the only way asp.net offers?

   * Every other platform uses inline scripting, and most other platforms also use some sort of MVC framework or another.  Wouldn't it be advantageous to work like that?  Wouldn't moving .Net web development closer to the more common model make it easier for us to switch platforms and to onboard folks from other platforms onto .Net?

 > asp.net offers controls like the repeater and the gridview that make inline scripting unnecessary. Also by making it possible to package selfmade user controls it's very easy to create your own framework and share controls with others.

I don't really understand why you're blogging about asp.net when you haven't worked with it for 5 years. Also did you miss microsoft's announcement that it will be releasing a asp.net mvc separation plugin for visual studio?

@Scott: What other way than procedural do you want a page lifecycle to be? It's just like that, you get a request, and you handle it. There's various events you can handle to create your controls dynamically and methods you can override. Also .net offers various object bags to persist states between postbacks.

@Tinco

"What other way than procedural do you want a page lifecycle to be? "

Well that's just it, I don't want a page lifecycle at all. That's an artificial construct created by the Webform framework. Overriding the methods is exactly the pain I mentioned earlier. All I want are the objects. I like the objects, I don't like the fact that code out of my control changes the state of the objects at various times and that if I want to influence the state of those objects I have to override and babysit them.

@Scott, Jeremy - Yes, the “page lifecycle” as a stateful process that endures between postbacks is a faulty concept that breaks down when you dynamically add controls etc. The web _forms_ model does imply this lifecycle, unfortunately.

In most cases, a good application of MVP will allow your views to be postback agnostic and you don’t need to mess around with the page lifecycle concept.

If you're dealing with dynamically added controls, then it gets more tricky. However there are solutions that allow you to restore dynamically added controls to the control tree on each request (adding the controls again during the Init phase – DynamicControlsPlaceholder can do this automatically).

This is a good thing in a way as it forces you to work with the reality of a stateless web request rather than our friend the leaky abstraction.  The “request lifecycle” mechanism (in terms of the Init, Load, PreRender etc phases of an individual request) comes into play here - I think this is what Tinco was standing up for.

The process of making a complex object graph available for editing, where you're using control inheritance and dynamically adding controls based on the subclass of each object is quite complicated and will be difficult on any platform. However I've been happy with the way that WebForms has allowed me to implement this.  A Response.Write or templating solution to this particular problem could get very messy indeed and would probably not be as conceptually clean as creating a hierarchy of controls that reflects the object graph.

Sure, there are plenty of things I don't like ("one form to rule them all" especially and all that design time data access nonsense), but I'm trying to redress the balance. There’s plenty of good stuff in there that allows you to write effective code.

I also was getting tired of ASP.NET WebForms development.  I think it was a mistake for MS to mimic the "fat client" model for development.  The two are just two different (winforms and web dev).  The new MVC sounds like it might work.  I had tough time with the eventing on WebForms and control hierarchies, when they get built, when they don't, the viewstate, etc. etc.  Unnecessarily complex IMHO.

I am very glad to be doing mostly WinForms development now.

What I really think, and always have been thinking, is that HTML/JavaScript/CSS is not an application development platform.  We make it work but at what cost?  When people started building simple apps using <form> tag and simple javascript, people saw it and immediately embraced it.  Now we have AJAX and the whole WEB 2.0 thing.  It's the wrong direction.  HTML was meant for documents, not applications.  I'll take Silverlight/Flash or any other embedded runtime over HTML/JavaScript/CSS any day.