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 something. 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 ---- Erik Price Web Developer Temp Media Lab, H.H. Brown [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
