Friday September 4th

Thursday September 3rd

13 comments

I kinda like ASP.Net.

With the 8 trillion ASP.NET MVC posts we've had to this site, NOBODY has commented yet??

# The ridiculous amount of time I spend in Reflector trying to figure out why things that are supposed to "just work" when wired up "just don't"

I don't think I've ever had to use reflector to figure out why something in asp.net isn't working. Really? You're CONSTANTLY in reflector? I find that hard to believe.

# Not having control over the HTML that is spit out.

HTML that is rendered by server controls you mean? Does MonoRail give you control magically over server control output, or do you just not USE server controls when using monorail? Either write your own controls or you could use control adapters.

Trying to do anything with AJAX or DHTML with the insane control names controlName.ClientID anyone?

Whatever.

I think that WebForms (the title should really have been something like "ASP.NET WEBFORMS: officially unmaintanable") got some things right. I love the RAD aspect of WebForms, and it is one of the things that really attracted me to ASP.NET moving from JSP/Java Servlets/JavaBeans. If I would've done ASP development, I probably would've felt the same about the transition.

Since ASP.NET MVC is so young, it's hard to tell what v1.0 will include, but we're not really that far away from an RTM (granted, out-of-band support, think ASP.NET AJAX before .NET 3.5). The immature/grassroot server/user controls, state persistance (e.g.: viewstate), and validation stories are what concern me the most that in some aspects it may be a step backwards.

I love the open nature vision of ASP.NET MVC, with its pluggable architecture, but "off-the-shelf" it needs to have MS-supported baselines/defaults for server/user controls, state persistance (e.g.: viewstate), and validation, IMO, to be ready for production and mass consumption.

These sorts of posts about ASP.NET being unmaintainable are an exaggeration to me. I have seen time after time new frameworks created because some developers did not like a feature in the widely popular framework. And either they did not like the feature because it really had some problems or they did not understand how to work with it properly. I personally put very little code into my pages and code-behinds and export the vast majority of functionality to class libraries that I can unit test. No development pattern (MVC, MVP) will automatically prevent me from placing code where it should not be if I do not commit to keeping my code organized for maintainability. The over-reaction and false perception here is that ASP.NET is not 100% unit testable. In fact, if you do export most of your moving parts to class libraries, perhaps modular by their purpose, you can create a very maintainable web site with pretty complete code coverage. What MVC is sacrificing now is many benefits on the other end of the spectrum, like powerful server controls, productivity benefits of the design surface, etc. I hope that ASP.NET MVC does not swing too far on the side of the spectrum for unit testing and forget that many developers still want to leverage all of the existing productivity features.

I do not want the .NET framework and platform to start fragmenting like Java has done the last 10 years. There are many MVC frameworks in Java. How do you hire someone for your team that happens to know the one you are using? One major benefit of ASP.NET is that you pretty much all have the same IDE (VS) and if a developer has worked with the PostBack model they can be productive on day one. When I was working with Java and other languages I found that taking up maintenance for existing web sites started as a research project to figure out how it was built and then try to learn that framework and understand all the nuances of it. At least with ASP.NET it is the devil I know.

In my experience, if you can't write maintainable ASP.NET applications, that's not the fault of the framework. It may often tempt you to make poor design decisions, but it doesn't force you to.

Yeah, I should have named the post "Web Forms" and not "ASP.NET". That was my mistake.

@Photoz

Coming from ASP 3.0, first I hated it, then loved it, then hated then loved then hated again. We needed a break.

@aquinas

All MVC frameworks (not just the .NET ones) give you complete control over the HTML. Which generally leads to easier-to-maintain HTML, much smaller pages, etc etc. As for being in Reflector constantly, no not constantly, but too much. Actually, about 2 years ago I gave up searching in Reflector, as I found some things are just broken. I still have a site in production, with a single TextBox and asp:Button that will not work if you hit "Enter" in the TextBox. For other things, I found the complexity of the inner workings was too great, and just picked a manual Repeater. The best thing I did in ASP.NET was abandon all control vendors and complex server controls like the GridView, and just used simpler HTML and templates. Repeater works wonders.

@offwhite

I meant to say "WebForms", not "ASP.NET". You're right, the bulk of your application can be made maintainable. It's unfortunate that the last mile can't. Once you learn the MVC pattern, all frameworks are pretty much the same. Java has options, but it gives you choices. I'd go with choices.

I haven't used the design surface in years. Firefox and IE are my design surfaces. Postbacks are completely alien to anyone familiar with how HTTP works. Exaggeration? Maybe. Hyperbole? Sure, it's the internets, right?

@gt1329a

The issue with WebForms is that you have to work against the architecture to build maintainable apps. Your code-behind will forever and always be unmaintainable. I like to go from the DDD side, where the Application layer is as thin as frickin' possible.

Current .NET MVC frameworks have their limitations and annoyances

"All MVC frameworks (not just the .NET ones) give you complete control over the HTML."

Because you have to write all the HTML yourself, correct? You can write all the HTML yourself in ASP.NET, just don't use any controls. Like you said: repeater works wonders. For many applications, you may need to do a lot of that. Depends on what you're doing.

"I found some things are just broken. I still have a site in production, with a single TextBox and asp:Button that will not work if you hit "Enter" in the TextBox."

For the case you mentioned you need to add defaultbutton="your button" to the form. This only is an issue with IE actually. Also, no offense but did you actually google this problem? e.g., google: "single textbox button submit onclick asp.net".

What else is broken?

"Trying to do anything with AJAX or DHTML with the insane control names "

Apparently he never saw the [Control].ClientID property.

> Since ASP.NET MVC is so young, it's hard to tell what v1.0 will include, but we're not really that far away from an RTM (granted, out-of-band support, think ASP.NET AJAX before .NET 3.5). The immature/grassroot server/user controls, state persistance (e.g.: viewstate), and validation stories are what concern me the most that in some aspects it may be a step backwards.

I'm fairly certain we'll see none of these. Complex server controls simply won't be there. Apparently all the "smart" people do nothing but use simple textboxes and dropdowns for all their forms. Viewstate is hated by those doofs at Code "Better", and for some reason they have some major pull with MS. Validation that approaches anything in WebForms is a pipe dream.

I agree that webforms are unmaintainable myself, but for the following reasons:

To me webforms when used with its server controls is just a leeky abstraction of HTML. Id much rather be able to see the actual html when I am looking at the aspx code file as is the case with MVC. But overcoming this issue whats worse is that, In order to understand what the page is trying to render one has to be flicking between the markup and the codebehind, since they are just so tightly coupled together. The codebehind needs to know all the controls on the ui and needs to set all their values etc. Personally I dont see how this makes a maintainable frontend.. Multiply this by the number of pages that you have in your site...

Viewstate is just being abused too much, in my opinion it should have just been off by default so that users have to explicitely enable it for the controls that actually need it. That way it saves us from having to toss around 1MB+ of viewstate data. Again the __dopostback paradigm means that we are completely ignoring the 5% of the users that dont have javascript disabled, (this is 5000 for every 100k visitors) as well as any WAI and WCAG accessibility guidelines...

I much rather prefer the tidyness of the proposed MVC approach where the UI is simply 'pulling' the information it needs from the viewdata, and the controller is not pushing this info to specific controls, it doesnt need to know them, its just pushing it to the viewdata - the UI logic in our markup kicks in to put the right viewdata at the right places. (sweet :-) At a glance you can understand how the page is about to be rendered without having to flick between controller and markup as you need to do with webforms...

Simple is better, all we are talking about is HTTP request... all the page lifecycle events just adding to the complication where things could have just been simpler, (again take a look at MVC lifecycle http://weblogs.asp.net/stephenwalther/archive/2008/03/17/asp-net-mvc-in-depth-the-life-of-an-asp-net-mvc-request.aspx)


just my 2c

@foobar

kinda pointless to reply to an anonymous user, but oh well.

Yes I know about ClientID. That won't work well with CSS or external javascript. It's a kludge.

As far as complex validation, MonoRail has very, very rich validation support. Much improved over WebForms, as you put the validation attributes on your View DTOs. [Required] on a Name property, for example.

Complex server controls aren't there because the pages become much simpler. The most complex pages I wrote, with many server controls, third party and custom, were an absolute nightmare to maintain. I couldn't edit the page without it breaking, as all the controls were very tightly coupled, because of the ASP.NET runtime.

Web development is simply a vicious beast. :( And as far as unit testing goes, well, you eventually have to use that UI to test it.

Commenting on Stories is limited for now and will open up to those recommended by the community. Learn how
Loading DotNetKicks...
brought to you by the Kicks Network