BTW, we are in full agreement on your statements. As this is a public
forum, however, it is a great discussion to have the full pros and cons
outlined. That is why I like the fact you are here in this group. ;-)
//I use the RAPID approach and then scrap the bindings.//
That's the key.
You will actually pull the trigger and do the scrap(ing).
Some people don't. They start with it, and keep going with it.
That quick prototype all the sudden is a working application.
I am under the impression that you should learn what things are doing
before you can call yourself a professional. ;-)
That being said ... there are people who are not interested in web
development as a profession who build websites.
So if you're wise/mature enough to do the scrapping at later point,
then yes ... RAPID is ok.
But if you're (somebody out there in internet land, not you Gregory)
are reading this and are not following the conversation, then I
wouldn't go RAPID.
As in, if your prototype becomes your product/production code, don't
start down that path to begin with.
RAPID is great for prototyping, but it throws you in a box. And I agree
that if you don't know how to get out of the box, you should scrap the box.
RAPID can save you time. But you have to realize its limitations before
investing in it. The same is true for ideas like code generation (which
Kathleen Dollard is the goddess of). They are all great tools if you
understand their limitations.
Microsoft is lowering the bar for entry. That is a good thing, overall. But
the bar being lowered means the box is smaller. And, if you accept the box,
that is fine. Once the box no longer fits your stuff, you need to move on.
The RAPID stuff works fine for experts, as we use it and then throw away
the garbage thaat comes with it. It also works fine for Joe family business
with small needs in scale, etc. It often traps the "Enterprise developer"
who has not examined what all it does.
This is changing, however, as even Microsoft devs are learning how to
expand the plumbing box. But, anything you do not hand code comes with some
type of limitation. This is true of DataSet designers, LINQ, EF, etc. If
you drag and drop, some assumptions are made that MAY NOT apply to you. If
they don't you either edit, scrap the whole drag and drop, or you are
stuck.
I agree with you that a developer that does not have time to figure out the
system is better using a system where the box he is climbing in is big
enough. Unfortunately, there are precious few sites showing what that is. I
am not sure completely going the non RAPID route is the best idea, but if
you cannot figure a way out of the box, it is wise to not get in to start
with.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
Twitter: @gbworld
Blog:
http://gregorybeamer.spaces.live.com
*******************************************
| Think outside the box! |
*******************************************
