Re: [MLUG] Up against the wall with LAMP...

[McIntosh Jason <EMAIL:PROTECTED>]

I'd second that motion.  I've got an app I'm working on right now, where I essentially create a number of classes.  A data class, data factory class, and a display class.  The datafactory is all I'd need to change if I had to change databases.  It's the only thing that knows anything about the database.  Now, related to that, to really be abstract I'd have to have another layer which talks to the database, i.e. data factory database.  The problem is that after a certain point, abstraction is too much abstraction :)  In other words, for the java app I'm working on, it isn't worth my time to try and set another level of abstraction - what I've got works well.  

Now, I could use other components for abstract database calls, but for optimization issues, that's far less efficient.  Further, when you consider things like record locking (in a stateless web environment, VERY tricky), having a class which talks to the database directly is handy.  I haven't found a decent way other than the 3-class method which works well for programming.  I tried once to do a more dynamic object loading system, but found in some ways it was more work than it was worth.

Hmm, wish there was a "programmers" emailing list to discuss stuff like this.  I've got a few forums I talk on, but it's mostly bug discussions there, not "concepts" - i.e. how to do db row locking in a stateless environment.

Oh, let me finish off by one last comment - it IS good to use classes and includes in PHP rather than have the calls in the php file directly.  Do an include on your database handler code, so you've got one place to make changes to the database calls - makes the code a lot cleaner, IMHO.  Classes - i.e. object oriented programming - makes application design a LOT easier too.

Jason

  

--

/--------------------------------------|---------------------------\

| Jason McIntosh                       | CELL: 573-424-7612        |

| Webmaster, thinker, programmer, etc. | WORK: 573-884-3865        |

| http://poetshome.com/                |                           |

|------------------------------------------------------------------|

|"How should I know if it works?  That's what beta testers are     |

|for.  I only coded it."                                           |

|(Attributed to Linus Torvalds, somewhere in a posting)            |

\--------------------------------------|---------------------------/

GnuPG Key:  http://poetshome.com/about/jmcintosh_mlug.missouri.edu.gpgkey

On Mar 28, 2006, at 11:46 PM, Michael wrote:

The reason for using the PEAR DB abstraction class rather than

mysql_pconnect() is the very fact that it offers database abstraction.

Code which operates correctly using PEAR::DB should work equally well

using MySQL, Oracle, PostgreSQL or SQL Server. Obviously for portable

code this is a boon.

Of course you can easily lose your portability by using implementation

specific SQL...

  

DB abstraction really isn't that useful. I tried it for a while and found it to be a big pain in the arse with very little return on effort. It's better to abstract you're whole data storage layer and then you can change anything you want as needed even to not storing data in usual ways. Separating programs into services makes more sense I think if you're in search of abstraction.

--

Michael McGlothlin, tech monkey

Tub Monkey

http://www.tubmonkey.com/

_______________________________________________

members mailing list

EMAIL:PROTECTED

http://mlug.missouri.edu/mailman/listinfo/members

_______________________________________________
members mailing list
EMAIL:PROTECTED
http://mlug.missouri.edu/mailman/listinfo/members