Procedural ["bare ASP.NET"] versus OOPy ASP.NET

  • Thread starter Thread starter parley
  • Start date Start date
P

parley

After several years of programming WWW applications in ASP.NET (and
several other frameworks) our division has come to what might seem a
counterintiutive conclusion:

Writing ASP.NET code in a "procedural" manner (without webcontrols and
without utilizing OOP concepts in general) produces code that is
remarkably faster and more scalable. In general a "bare ASP.NET"
application outruns it's OOPy counterpart by factors of 2 to 10.

Surprising side-effects are that the procedural version has reduced
memory requirements, is easier to maintain and it is easier to explain
and debug. While reusability was a goal in the OOPy versions, that
goal proved elusive, since a developer must be taught the intricacies
of any new reusable component he is given (he can't merely plug it
into an application without understanding it fully) and because, to
design a reusable component one must know beforehand all the ways it
will be used in the future, something that is difficult if not
impossible.

If our programmers _were_ inexperienced, I would chalk this up to
inexperience. But this is the conclusion of our programming group,
which has written software on many platforms using various languages
(OOP, procedural, and functional) over many years. While OOP certainly
has it's place (e.g., it is particularly useful in writing real-time
telecommunications software), that place does not seem to be WWW
applications. I might add that our developers are very familiar with
Internet standards and protocols, something that may not be true of
developers in general.

Our productivity on WWW apps has increased significantly since we
accepted this surprising conclusion. Have other shops concluded the
same? What are the experiences of other ASP.NET developers?

Bob
 
I won't comment on the speed, as I do not know. But I guess the overhead
involved with using a control, that's not just bare bones.

Now, by procedural code, do you mean Response.Write'ing everything out? If
so, I can't imagine anything that would make a web app more difficult to
maintain, extend or reuse, then that. Once the learning curve associated
with learning how to use the server side web controls is taken care of (and
by the way, this is not that huge a learning curve), development becomes
easier. Once reusable controls that include code, etc are created,
development becomes even faster. Yes, no one can know how to do it right
100% the first time - but every control gets refined and has new features
added over time.
 
The clue as to your developer's conclusions can be found in your message:
inexperience. But this is the conclusion of our programming group,
which has written software on many platforms using various languages
(OOP, procedural, and functional) over many years. While OOP certainly
Click to expand...

Probably too many years, and not willing to keep up.

Here's the thing. Take DOS for example. No doubt you can write a program for
DOS that runs much faster than one written for Windows XP. There's a heck of
a lot of overhead in creating a multitasking, multiuser, network Operating
System. But there are many good reasons why nobody uses DOS any more. There
are many good reasons for making ASP.net object-oriented. Too many, in fact,
to enumerate here. And sure, it's uncomfortable to keep up with the latest
programming technologies. But if you don't, you'll be out of business if a
few short years.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.
 
Well, I know that I use some OOP features (inheritance) for my pages and I
know that makes things MUUUUCCCCHHH faster to develop and test. As far as
performance, I've not tested it both way so I can't say. My way seems
pretty darn fast as it is. Any performance loss that I'm taking I'm willing
to take so that it takes me just a few minutes to throw a new page together
and test it.

Michael
 
Not to mention, the developers will quickly learn they are technologically
stagnant and falling rapidly behind the curve and will jump ship at the
first opportunity. Yes, even in this crappy economy, it just may take them a
little longer to find something new.

As word spreads, and it ** will ** spread like wildfire, it will become
ever-increasingly difficult to find quality developers/engineers that are
willing to work for such a company.

I've seen it happen, quite often. Hell, I've even been the "ship-jumper"
once or twice myself ;)

My $.02


Brian W
 
Why don't you guys try COBOL.NET?

I can't tell if this is serious or not, but It's not April 1st, so I assume
it is. Based on your statements, I'd recommend tossing ASP.NET completely
and using either ISAPI or implement your own handlers. I still can't figure
out how you've determined that it's easier to maintain, though. Also, you
ought to consider marketability of yuor skillset if/when something bad
happens to your current business.

I'd be willing to bet that given a few years of this behavior, you will have
reinvented just about every useful feature of the framework, and written
mounds of unmanagable "spaghetti-code".

Good luck.

Oh, to answer your "query", I'd have to say that you're the only "shop" that
I've heard of that has decided not to use OO with .NET.

Michael Earls
http://www.cerkit.com/
 
Answers for those who responded:
To Marina's statement:
M> Now, by procedural code, do you mean
M> Response.Write'ing everything out?
Yes.
M> I can't imagine anything that would make
M> a web app more difficult to maintain,
M> extend or reuse, then that.
So we also thought it might be. But our experience did not confirm our
expectations.
That something like 99% of current successful web applications already
written were written in procedural form should have tipped us off that
a procedural methodology may be more natural to HTTP-based WWW
applications than is OOP. Only a fraction of such apps are written in
an OOP framework (e.g., Java, .NET) and of that the .NET fraction is
very small. But we ignored that fact when we began.

To Kevin's statement:
K> Probably too many years, and not willing to keep up.
Our division has deep experience in OOP and is very current!-)

to Brian W:
B> the developers will quickly learn they
B> are technologically stagnant and falling
B> rapidly behind the curve and will jump
B> ship at the first opportunity.
You misunderstand how our division came to these conclusions. These
conclusions were not forced on us: we discovered them. (read more
below)

to Michael Earls:
E> Based on your statements, I'd recommend
E> tossing ASP.NET completely
We decided that would be "throwing the baby out with the bath water":
there's much marketing advantage to running on the IIS platform under
..NET. But to continue the metaphor(perhaps poorly), we found that
Webcontrols and other more developed aspects of NET's OOP framework
were much like a Rubber Ducky: while pretty, they were unnecessary,
caused us to splash lots of water around and remain in the tub longer
than necessary.

E> I still can't figure out how you've
E> determined that it's easier to maintain,
E> though.
We tried it both ways over an extended period of time.

E> Also, you ought to consider
E> marketability of yuor skillset if/when
E> something bad happens to your current business.
There is no possibility of something bad happening to our current
business, but if our company went bankrupt tomorrow, each of our
developers would be eagerly snapped up by excellent companies.

The responses so far seem to be individual's gut reactions (which I
understand) to my initial post rather than the findings of groups who
have done experiments, as we have.

Surely there are other large groups out there who have benchmarked
ASP.NET WWW applications in various modes:
- cookieless execution
- JavaScript-less execution
- use of Response.Write
- webcontrols vs htmlcontrols
- overhead of various .NET objects and design patterns
- home-grown objects vs .NET's default objects
etc.

Scales of interest include performance, memory footprint, scalability,
cost and effort of initial development, cost and effort of
maintenance.

Please share your experiences.
Bob
 
I stand by what I said.

I would be willing to bet there is more than one person in your shop that is
[at least] secretly saying, regardless of your, so called, "findings",
"this is f**king b**lls**t!" (unless it is a 1 or 2 person shop) Even if
they are content with it now, see what they are doing after a year or so.
For that matter, try to hire a qualified ASP.NET developer or 2 and see how
long they stay.

Perhaps if your findings are so "groundbreaking" you should publish. I
doubt you could back all your findings consistently.

IMO you will be hard-pressed to convince anyone that frequents this NG that
"your way" is better.

Please enlighten us, tell us what company this is so that we can all avoid
it.


Regards
Brian W



[snip]
 
To Kevin's statement:
K> Probably too many years, and not willing to keep up.
Our division has deep experience in OOP and is very current!-)
Click to expand...

If that was so, your group wouldn't be recommending a proprietary,
procedural, non-extensible approach. Best of luck to them.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.
 
Back
Top