On Tuesday, July 2, 2002, at 04:31  PM, Richard Lynch wrote:

> Well, yeah, at that point all you have is SQL and Result, because the
> function has no idea what that SQL is about in any given call...
> But, personally, I just don't see the point to having a function/class 
> do my
> database work when it simply:
> Increases lines of code
> Increases debugging/maintenance time
> Decreases clarity of code
> Reduces performance
> Reduces flexibility
> Increases overhead

Hm.  Could be.  I haven't benchmarked it for performance, since in this 
case there will probably never be more than 20 simultaneous page 
requests at any given time considering the small number of users.  In 
fact, I'm sure you're right, that performance and overhead are 
definitely affected.

But I think you're mistaking what I said -- I don't necessarily write a 
function/class specifically to handle my DB work.  I write my classes 
and methods to manipulate objects easily and organize the data, and if 
maintaining state by doing a database insert (or resuming state by doing 
a database query) is necessary, well then that gets incorporated into 
the class.  It's not specifically a database abstraction layer, it's 
just an object, and most of my objects happen to get built from or 
stored in a database at some point within their lives.

And I write a function when I find that I am executing the same code all 
over again in various places -- like generating a date listbox or 

The effect is that debugging/maintenance time and lines of code are 
decreased, not increased, and clarity of code and flexibility are IMHO 
much better when they are safely constrained to class definitions rather 
than all being in one giant script.

But one thing I have learned is that everyone has a different approach 
to writing code, and objects may not be your thing -- that's okay.



Erik Price
Web Developer Temp
Media Lab, H.H. Brown

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to