A non OO programmers approach....

[Guest]

Hi,

I have been building asp.net 2.0 apps now for a few years. In general I use
MS Ajax and the MS Data Enterprise Application Block to manage the connecting
and getting data from the database.

My apps work very well espiecially with the introduction of MS Ajax.
However, I dont take the normal OO approach. Obviously the .Net framework is
OO based but when writing apps I take a different approach to what is the
norm I'd imagine....

I would create a number of classes to handle the calls to the SQL stored
procedures in the database. For example I would have a Person class with
public shared subs such as Person_Create or Person_Delete. These just call
stored procedures to execute the sql. I may have a Customer class with public
shared subs to Customer_Create etc etc

The rest of the code behind pages would typically have a lot of event
handlers and they would call the classes above (all of which are in the same
namespace) as needed.

So I have a lot of business logic in the stored procedures but I find this
approach very manageable for small applications. Most of my apps would not
have more than 30 tables so we are not talking about enterprise level
applications.

Anyone take this approach, maybe you think its a terrible approach and I
need to learn OO?

I find it very maintainable and logical, but maybe thats just me!

 

[kpg*]

Anyone take this approach, maybe you think its a terrible approach and

I need to learn OO?

The rise of the OO culture and its emphasis on object-oriented design has
caused many procedural programmers to feel like they are somehow doing
something wrong, myself included. I love objects, and I use them as you
do, but not in a "pure" OO manner, but more as components and a convenient
way to encapsulate code and realize all those nice object benefits.

I'm currently reading "Object Thinking" by David West and I HIGHLY
recommend if for all programmers, OO or not. He reveals that, as I long
suspected, even ardent OO enthusiasts seldom practice pure OOD. He also
makes persuasive arguments of why we should try, however.

As for your coding style, it is my opinion that a program is a good program
if it does what it is supposed to do AND it is maintainable - meaning both
that bugs can be fixed easily and without introducing new bugs, and
extensible - new functionality can be added, again, without creating bugs.
From your description it sounds like you are there.

To try and change your style for style sake alone would be a mistake.

kpg