Created On:

06/03/2007

Author:

Aaron Robson

Tags:

aspnet

Asp.net (is) for Dummies...

Comments

Ryan Nichols -

I agree. I think that creating the platform AROUND it's IDE was a poor mistake, and is at the heart of a lot of decisions. Create a language in which you could develop quickly IN through code, then the create an IDE for it. Take datasets and datatables. Progmatically creating those would be a waste of time. They are useless. Oh but drag and drop them in an IDE and it's fantastic...or is it? How many ORM or DAL layers that were created after, you know, the kind of data layers you would use in an enterprise level app, completely shunned either datatables, or at least the use of the IDE altogether. Personally I never used the Visual part of the IDE for what they wanted it for, because in 1.1 we needed GOOD templates, and no decent template solution could be used alongside drag and drop. Then we developed a true OO ORM/DAL, and divorced ourselves from datatables. In effect for the life of 1.1 I only used about 30 megs of the 1gig massive VS install. In short you raise a very valid point about the weakness of VS :)

Dave -

yeah... i guess i can see this. i mean, the controls that the ide sort of puts in your face are simply the result of a built up framework which causes bloat. there are plenty of frameworks out there for java, php, etc, which will contain the same amount of bloat. me, personally... i still hand-code everything in asp.net, even asp.net web controls. keeps the control in your hands. i like asp.net mostly for removing code from the traditional inline style. just like any language/framework, the code you get is only as good as the developer creating it.

Arni Gunnar -

Well ... I think this is not a question of the programming language, but the programmer himself/herself. You have lazy programmers that do endless drag and drop in design veiw, and the real dudes that really know their stuff and use the objects built into ASP.NET as they are ment to be used.

ScottGu -

When we think about designing new features in ASP.NET, we usually approach it in terms of a multiple layer approach -- where there are core features at the bottom layer that provide base levels of functionality, and multiple framework abstraction layers as you move up. The lower down you are in the functionality stack, the more flexibility (and power) you have to-do anything you want. As you move up, the feature-set then becomes more scenario focused. A good example of this I think is security authentication support: At the very lowest level of the stack ASP.NET has a protocol agnostic way to represent user identity. A little higher in the stack is a forms-authentication ticket management architecture, that provides a secure encrypted way to issue identity tickets using a cookie (or with V2 now optionally a cookie-less) approach that is credential store neutral. A little higher in the stack is then a new Membership API that provides credential management APIs on top of a Membership Provider architecture that allows you to plug-in any credential store you want (you just build a provider). A little higher in the stack are the built-in membership credential providers for SQL databases and AD that are built-into the box (so you don't have to write these). Then at the top-most of the stack are the new login controls in V2 that avoid you having to even write code to call the Membership APIs -- and provide all the built-in functionality for you. A developer can then choose which level of this stack he or she wants to plug-in at based on the level of customization and flexibility they need (the lower they go, the deeper the flexibility). Hopefully people will find that there is a lot of rich framework support and extensibility at pretty much any layer to take advantage of. Hope this helps, Scott

Adel -

Totally agree.

Aaron -

Considering this was written so long ago, there is still an amazing amount of similar feeling around, with lots of people feeling the pain in slightly different ways. Two recent discussions I've seen are from Jeremy D Miller and from the Entity Spaces blog...

Well, they seem similar to me, but I could be imagining it :)

OmegaSupreme -

Your saying what I've been thinking but of course what Scott says is completely valid. A case in point Master pages, great in the drag and drop demos but when you need nested master pages, your in a wolrd of pain and kiss the designer good bye. As it happens nesting was the FIRST thing I needed them to do... Of course there are work arounds each with their own pros and cons... A good example of how the approach works well is AJAX, you have the drag and drop control extenders which just work and work well or you can go deep and create your own controls, javascript classes and so on. Please note though I wouldn't use anyother framework despite my minor gripes :)

Anonymous Coward -

This sort of reminds me of the people who protested compilers over assembly language because too many implementation etails were hidden and there would never be "real programmers" again. Later Java engendered the same response from "old school" C programmers who felt that it was impossible to write an efficient program unless you understood pointer arithmetic. Get over it: the natural evolution of development is higher and higher level of abstraction. It deosn't eliminate the need to understand deep behaviors, low-level protocols, but I think you're attacking a straw man. Nobody said that ASP.NET was supposed to make programming a drag and drop activity. That's why all the fancy UI stuff is bidirectional -- it generates code, and you can safely modify that code and the UI will be updated.

Dee -

I think what's missing in all of this is a clear MVC style structure. There are too many layers of abstracted, quasi-abstracted, non-abstracted code intermingled with business, data and presentation layers. If there was some clear MVC structure definition it would go a long way to improving ASP.net development.

Simon -

I agree with this. I've ended up virtually rewriting ASP.NET. Admittedly that was to get the functionality that I want (we use a lot of XSLT). I'm probably going to take this further and ditch everything in the future, rewrite the lot from the request down. As a result I'm very familiar with the structure of ASP.NET and where all the compromises have been made. It all comes from one thing, trying to make a web application look the same as a desktop application. They jump through so many hoops to make it familar when fundamentally it's not.

Aaron -

Anonymous:

Well, you're entitled to your view, but you're wrong obviously :) Hehehe, no seriously I've worked in x86, C etc and I did have those gripes about Java - but funnily enough, I was right - my gripe was that user interfaces didn't fit in with the native UI and demanded a paradigm switch from the user. I don't see that many desktop java apps becoming succesful (in the windows world!) nowadays. I was also writing computer games during the switch from software rendering to hardware rendering which was a classic case of people feeling too restricted by the underlying frameworks (what, no phong shading!). In that case, and also in the case of Java's performance issues in desktop UI's, hardware moved on and the pros defeated the cons. With Asp.net, I'm yet to see anything done with visual designers and high level web forms controls that is convincing beyond the prototype / demo stage as a way to develop apps.

Dee:

I agree, thats a major part of it, and funnily enough, it seems like the constraints of having a specified structure make development easier. Perhaps part of the asp.net problem is that it doesn't constrain developers enough! I like the way Rails basically says - do it this way - otherwise too much time can be spent debating the pros and cons of various different ways.

Simon:

XSLT eh - damn that can be a scary beasty too :) It sounds like you got some similar insights to myself when you put your own framework in place. I've been writing a framework called PoCoRail, which is basically MVP. I found I would come up with a requirement for PoCoRail, and then as I tried to implement it, I'd realize that asp.net was having to deal with exactly the same issues, and that their solution was pretty good. I really think there must be a few members of the initial asp.net team who were going - oh please no, don't do that to my creation - as the visual designer crew got to work turning it into a RAD tool.

Mohamed Salem Korayem -

Couldn't agree more. I am a 5 years classic ASP developer. With the first release of ASP.NET (ver 1.0) I was attracted by the fact of "easier" implementation. But whenever I tried to customize anything, I was astonished by the amount of digging into different parts to do what I want exactly. I ditched ASP.NET 1.0 and continued working classically with ASP. With the second release, I was again attracted into trying to switch. Well quite honestly I WAS insterested this time and did a lot of free lance work to different customers. But still what you wrote is true. ASP.NET might "seem" a lot easier offering drag and drop stuff, it still requires a lot of work in customization to the extent that it might take less time to do what you want with classic ASP. I always say that, classic ASP has a small learning curve (I learnt it in one week only) but you have to do literally everything on your own. With ASP.NET, has a much larger scaled learning curve with some nifty out of the box stuff to use.

Dee -

Mohamed: I too am a freelance developer from c classic ASP background, and have had the exact same transition experience as you have. Building custom apps for clients in ASP.net 2.0 always is a major effort which I frequently think were likely to have been much easier to create in classic ASP. Oddly enough I find that my customers are also turned off by ASP.net because it is to complex for them to tinker with. They liked the idea that they could go in and tweak a page for minor items without having to get me involved but are unable to do so with.net. I have 2 customers that won't upgrade to, or order anything .net.

GuyIncognito -

I agree with Scott's response. I sort of respect the work the DataGrid-like controls are trying to accomplish, but most of the time they get in my way. I'm much happier with creating my own custom server controls for grids, menus, lists, etc. I am a control freak when it comes to the HTML, CSS and Javascript that is generated. I can't have 100% control, but I come close. You can even go so far as implementing your own HttpHandlers and forgo the Page class completely. You end up also having to give up the "design" window in VS.NET, but to be honest, I never use that anyway. As for VB6 not being able to create Enterprise Apps... RUBBISH. Complete rubbish. I've programmed "Enterprise Apps" in everything from COBOL with CICS, MUMPS, DBASE, ASP, VB6, WIN32, MFC, Windows Forms, etc. All of those were and still are capable languages/environments. (Although there are a few I'd love to forget!)

Aaron -

Guy:

Sure you can create decent apps in VB etc. I mean lets face it, some useful apps could be put together in BBC Basic. I think the issue is more what the language or the IDE encourages you to do - people always want to follow the path of least resistance, even if that happens to be far from ideal in anything but the short term.

Its a bit like cleaning your house by brushing the dirt under the carpet - it won't take long before it starts to smell - and I don't think anyone can deny there are a few smelly VB6 apps out there.

Mike Gale -

My experience with the ASP.NET IDE is that it gets in the way of development. (Admittedly my opinion is shaped by the version for version 1.x) When using it I: 1) Switch off the design surface as much as possible. 2) If I use the design surface I first take a copy of the code/markup, then I hand edit the design surface contributions back in. (Time wasting but damage is avoided.) 3) I write code that generates markup and code behind, so that I can avoid the design surface. 4) I may prototype with supplied controls, but often throw them out for final product and replace with something that does what I want and passes my tests. (One CSS, one JScript...) So for me the attempt to "make a UI for dummies" ends up creating a lot of work and has left permanent bitterness.

Aaron -

Mike:

Yeah, the IDE in 2005 is a lot better at not messing things up, and the quality of markup is a lot better. I still don't use the designer though. I suppose a lot of that could be to do with the fact that I know it wouldn't look right anyway as CSS layouts rarely work in design view. It sounds like VS Orcas could be a move in the right direction (as usual), although I've finally learnt not to hold my breath for these things.