# [EMAIL PROTECTED] / 2007-04-19 10:50:19 +0200:
> Roman Neuhauser wrote:
> >>> I wouldn't do it that way. A single class should not be a database
> >>> driver *and* manage connections.
> >> fair enough, although personally I find that going a bit far, I don't
> >> see the win in splitting up the 'driver' and 'connection manager'. not
> >> that this is the problem in this case.
> >
> > You wouldn't be having this upgrade problem if static DB::query(...)
> > wasn't there, and it's there because class DB is a client library *and*
> > a connection manager. So I'd say this design mistake (and the fact that
> > PHP allowed you to have almostatic methods) are the problem in this case.
> >
>
> I might plead with internals for: ;-)
>
> class DB {
> almostatic function query() { /*existence of $this is MY problem */ }
> }
Existence of $this is YOUR problem only as long as you don't share the
code with anybody else. At that moment, you have made life harder for
someone else.
> though I can't see atm how the connection management is the problem,
> I assume you think this because of the way connection ids and transaction ids
> in
> ibase are interchangable.
No, I've had virtually zero exposure to Interbase/Firebird, and have had
no idea about the phenomenon you mention. I think it's a problem
because of the ways it reduces quality of the code.
Or does DB not handle database connections? If not, how come the static
call DB::query("SELECT fubar FROM snafu") works? Guess it does things
besides querying (probably why it's a generic "DB" in the first place).
> regardless I have a problem, I'll keep looking at the code until a clean
> solution
> presents itself, it's in/out there somewhere.
>
> >> I could easily split out the actual connection management into a
> >> seperate object but I'd still be stuck with the problem described
> >> above (which is not actually related to connection management).
> >
> > Not if you make the separation visible to the client code, which, as you
>
> I don't follow you here. could you try an explain it in idiot language? :-P
Split the two functions, and don't try to hide the fact that they're two
functions; after all, if you do it correctly, the static one will
probably end in a different class.
> > write below, is actually only a fraction of those "10000's of lines of
> > code".
> >
> >>> Do those 10000's of lines of code concern you? rlynch says indirection
> >>> and separation of concerns are useless, you either have decent
> >>> programmers and global search & replace, or you don't.
> >> yes & no. I don't have an endless budget or legions of world-class
> >> analysts, designers and programmers at my disposal for building
> >> megabucks codebases that implement near-on perfect loosely-coupled
> >> application designs, and I don't have the same legion to do search and
> >> replace.
> >
> > I'm at a complete loss then. Richard, what would you advise to someone
> > in such a messy situation?
>
> my advice to myself is "find a way to fix it, and then do it" - not sure
> what exactly that means in terms of design or code but I figure that has to be
> an answer/solution somewhere :-)
Don't try to cram connection management into a db client driver class.
The rest will just fall out of it.
--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
