OOP PHP with MySQLi

[Citrus]

Hey, i'm looking for the best possible way for connecting to my database
without too much of an effort.

The example works fine and fast. What i need to know is if it's safe, stable
and the way to go. If anyone has a better way for connecting side-wide to
something i'd like you to show me. I've had it working before using 'global'
but people told me 'global' is bad programming.

One of the possibilities would be to make the link and pass it on to every
function and object but this is NOT an option because it makes my script
less transparant and easy to read.


<?php

class My {
private static $connection;

function SQL() {
if(empty(self:: $connection)) {
self::$connecti on = new mysqli("localho st", "user", "password", "db");
}
return self::$connecti on;
}
}

class User {
function __construct() {
echo "user init<p>";
}

public function show() {
$query = My::SQL()->query("SELEC T * FROM user");
while($row = $query->fetch_object() ) {
echo $row->login."<p>";
}
}
}

$user = new User();
$user->show();

//Works here too
$query = My::SQL()->query("SELEC T * FROM user");
while($row = $query->fetch_object() ) {
echo $row->login."<p>";
}


?>

[Erwin Moller]

Re: OOP PHP with MySQLi

Citrus wrote:
[color=blue]
> Hey, i'm looking for the best possible way for connecting to my database
> without too much of an effort.
>
> The example works fine and fast. What i need to know is if it's safe,
> stable and the way to go. If anyone has a better way for connecting
> side-wide to something i'd like you to show me. I've had it working before
> using 'global' but people told me 'global' is bad programming.
>
> One of the possibilities would be to make the link and pass it on to every
> function and object but this is NOT an option because it makes my script
> less transparant and easy to read.
>
>
> <?php
>
> class My {
> private static $connection;
>
> function SQL() {
> if(empty(self:: $connection)) {
> self::$connecti on = new mysqli("localho st", "user", "password",
> "db");
> }
> return self::$connecti on;
> }
> }
>
> class User {
> function __construct() {
> echo "user init<p>";
> }
>
> public function show() {
> $query = My::SQL()->query("SELEC T * FROM user");
> while($row = $query->fetch_object() ) {
> echo $row->login."<p>";
> }
> }
> }
>
> $user = new User();
> $user->show();
>
> //Works here too
> $query = My::SQL()->query("SELEC T * FROM user");
> while($row = $query->fetch_object() ) {
> echo $row->login."<p>";
> }
>
>
> ?>[/color]


What a lot of overhead and such.
I am glad I just use global $connection; whereever I need it.

begining of every script that need a db:
<? require_once('d nconnect.php'); ?>

then from a function:
function leaveThingsSimp le(){
global $connection;
// do stuff here
}

Bad programming?
Says who?
And why?

Only use Objects if they add something to your code or structure somehow.
(Like PEAR:DB)
I really don't see the problem with making $connection global...

Regards,
Erwin Moller

[Citrus]

Re: OOP PHP with MySQLi

> What a lot of overhead and such.[color=blue]
> I am glad I just use global $connection; whereever I need it.[/color]

Where exactly do you find any overhead ? My project will consist out of 15
or more objects with each over 20 or 30 functions. Almost every function
will need to use a database connection. Calling global $connection at the
start of every script and function.. THAT is overhead.

I'm happy with my solution and it's a joy to work with. Currently i'm
working on the foundations wich I feel is very important (i've done 2 major
projects before) and with the upcoming PHP6 i want everything to be done by
the (right) book.


In the meanwhile i've had confirmation that this IS a good way and there
should only be a 'public' statement before function SQL.
So if any people are interested:

<?php

class My {
private static $connection;

public function SQL() {
if(empty(self:: $connection)) {
self::$connecti on = new mysqli("localho st", "login", "password",
"database") ;
if(mysqli_conne ct_errno()) {
trigger_error(" Could not connect to database !
".mysqli_connec t_error()."", E_USER_ERROR);
}
}
return self::$connecti on;
}
}

?>

If you load the upper code in every script you can easily comunicate with
your database using
My::SQL()->query();

Best thing is that you can use this in every function or object without
having the need to call anything else.

[Erwin Moller]

Re: OOP PHP with MySQLi

Citrus wrote:
[color=blue][color=green]
>> What a lot of overhead and such.
>> I am glad I just use global $connection; whereever I need it.[/color]
>
> Where exactly do you find any overhead ? My project will consist out of 15
> or more objects with each over 20 or 30 functions. Almost every function
> will need to use a database connection. Calling global $connection at the
> start of every script and function.. THAT is overhead.[/color]

No it is not.
That is just an opinion.
How do you want to compare? Counting?

But all is fine with me: Code whatever way feels good and structured to you.

I just do not see the advantage, but that is not important.

Don't get me wrong: I come from a Java (J2EE) background so I know my way
just fine with objects.
That is also why I like PHP so much: I can throw in objects when I need
them, where Java made me use objects for even the most simplest
functionality.
I often see people getting all happy and joyous about objects, while object
are just another way of doing what you were doing before without objects.
Smart designed functions can give you almost the same flexibility.
I just had the impression you wanted to use objects for your connection,
because that sounded cool, and I just wanted to tell you there is nothing
wrong with global $connection.

But I still wonder why you said that global $connection is bad programming.
Care to explain that?
I am just curious what made you claim that.

Regards,
Erwin Moller

[Jerry Stuckle]

Re: OOP PHP with MySQLi

Erwin Moller wrote:[color=blue]
> Citrus wrote:
>
>[color=green]
>>Hey, i'm looking for the best possible way for connecting to my database
>>without too much of an effort.
>>
>>The example works fine and fast. What i need to know is if it's safe,
>>stable and the way to go. If anyone has a better way for connecting
>>side-wide to something i'd like you to show me. I've had it working before
>>using 'global' but people told me 'global' is bad programming.
>>
>>One of the possibilities would be to make the link and pass it on to every
>>function and object but this is NOT an option because it makes my script
>>less transparant and easy to read.
>>
>>
>><?php
>>
>>class My {
>> private static $connection;
>>
>> function SQL() {
>> if(empty(self:: $connection)) {
>> self::$connecti on = new mysqli("localho st", "user", "password",
>> "db");
>> }
>> return self::$connecti on;
>> }
>>}
>>
>>class User {
>> function __construct() {
>> echo "user init<p>";
>> }
>>
>> public function show() {
>> $query = My::SQL()->query("SELEC T * FROM user");
>> while($row = $query->fetch_object() ) {
>> echo $row->login."<p>";
>> }
>> }
>>}
>>
>>$user = new User();
>>$user->show();
>>
>>//Works here too
>>$query = My::SQL()->query("SELEC T * FROM user");
>>while($row = $query->fetch_object() ) {
>> echo $row->login."<p>";
>>}
>>
>>
>>?>[/color]
>
>
>
> What a lot of overhead and such.
> I am glad I just use global $connection; whereever I need it.
>
> begining of every script that need a db:
> <? require_once('d nconnect.php'); ?>
>
> then from a function:
> function leaveThingsSimp le(){
> global $connection;
> // do stuff here
> }
>
> Bad programming?
> Says who?
> And why?
>
> Only use Objects if they add something to your code or structure somehow.
> (Like PEAR:DB)
> I really don't see the problem with making $connection global...
>
> Regards,
> Erwin Moller[/color]


Yes, bad programming. It binds all of your code to the variable
$connection, among other things. If you need to change that you have a
huge amount of code to change. It also makes the code less portable.
Also, if $connection gets changed someplace, you'll have a hell of a
time trying to debug it.

Globals in general are bad ideas.

Citrus's design is much better. There is a little overhead - but not
all that much.

And I find objects almost always improve the structure of my code. It
also makes it more flexible and configurable. For instance - I can
easily change databases simply by changing the database object. No
changes in my code are necessary. Heck - I can even use flat files when
necessary!

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[Erwin Moller]

Re: OOP PHP with MySQLi

Jerry Stuckle wrote:
[color=blue]
> Erwin Moller wrote:[/color]

<snip>
[color=blue][color=green]
>>
>> Bad programming?
>> Says who?
>> And why?
>>
>> Only use Objects if they add something to your code or structure somehow.
>> (Like PEAR:DB)
>> I really don't see the problem with making $connection global...
>>
>> Regards,
>> Erwin Moller[/color]
>
>
> Yes, bad programming. It binds all of your code to the variable
> $connection, among other things.[/color]

No, I use it only in functions that need the connection.
If a script needs the connection it gets the connection by means of a
include at top of the script.


If you need to change that you have a[color=blue]
> huge amount of code to change.[/color]

Why should somebody want to change the connection-object?
It is needed for database-access.
If I need to change that I am really making a new program.


It also makes the code less portable.[color=blue]
> Also, if $connection gets changed someplace, you'll have a hell of a
> time trying to debug it.[/color]

Sorry, thanks for replying, and I do not want to pick a fight with you, but
this doesn't make sense.
I can say the same for your object-oriented approach, look:

- If you use an (singleton) Object to deliver the connection, you bind all
your code to that object.
and
- If the connection in the object somehow get changed, all code breaks.
and

Does that make sense to you?
Of course not!
You know where you need a databaseconnect ion and get it delivered somehow,
singleton Object or global connection.
Both are lines of code, and both deliver the same in the end: a working
connection.
[color=blue]
>
> Globals in general are bad ideas.[/color]

Not if you need an outside variable inside a function.
It is perfectly legal.

I could also deliver the connection by refrence every call to every function
that needs the connection.

No big diff.

Please remember that we are NOT talking about globals as in ASP
(Application), but just globals for the duration of the script.


[color=blue]
>
> Citrus's design is much better. There is a little overhead - but not
> all that much.[/color]

Yes, Citrus claimed the same.
Also without any argumentation that made any sense.

If you are so sure of the superiority of the Object approach, why can you
not tell us why?

[color=blue]
>
> And I find objects almost always improve the structure of my code. It
> also makes it more flexible and configurable. For instance - I can
> easily change databases simply by changing the database object. No
> changes in my code are necessary.[/color]

No changes in your code needed?
Of course you need to change something in your code, the Object that makes
the connection is changed by you.

Now compare this to an include that delivers the connection: I also have 1
place to change the connection, and it is included everywhere.
Then everywhere where 'global $connection;' is used, the connection is
up-to-date.

Don't try to sell nonsense to me.
I developed years and years in Java, and do not fall for laymans arguments.

Please give me a serious response that dives into the issue instead of
claims that are clearly not true.


Another thing: In PHP Objects are only halfhearted and last only for the
duration of the script. They are not persistent. (Unless of course you
serialize and deserialize them from script to script, but that is not
exactly persistent.)
Object in PHP are nothing more than a bundling of some functions together,
and their own namespace. Really that is all there is to it.

Don't try to make more of it than that.


Heck - I can even use flat files when[color=blue]
> necessary!
>[/color]

So can I, but what has that to do with this issue?
Are you suggesting that Objects are the next step in evolution of the
$connection in scripts? Haha.


Regards,
Erwin Moller

[Jerry Stuckle]

Re: OOP PHP with MySQLi

Erwin Moller wrote:[color=blue]
> Jerry Stuckle wrote:
>
>[color=green]
>>
>>Yes, bad programming. It binds all of your code to the variable
>>$connection , among other things.[/color]
>
>
> No, I use it only in functions that need the connection.
> If a script needs the connection it gets the connection by means of a
> include at top of the script.
>[/color]

Yes, and declaring something global has its own overhead.
[color=blue]
>
> If you need to change that you have a
>[color=green]
>>huge amount of code to change.[/color]
>
>
> Why should somebody want to change the connection-object?
> It is needed for database-access.
> If I need to change that I am really making a new program.
>[/color]

Well, lets say you change hosting companies - and the new one uses
PostGres. Or you want to use the code on something which requires
Oracle access. Or any number of things.
[color=blue]
>
> It also makes the code less portable.
>[color=green]
>>Also, if $connection gets changed someplace, you'll have a hell of a
>>time trying to debug it.[/color]
>
>
> Sorry, thanks for replying, and I do not want to pick a fight with you, but
> this doesn't make sense.
> I can say the same for your object-oriented approach, look:
>
> - If you use an (singleton) Object to deliver the connection, you bind all
> your code to that object.
> and
> - If the connection in the object somehow get changed, all code breaks.
> and
>[/color]

First of all, it was not MY singleton object. But it's a heck of a lot
more portable than yours is.

Yes, you bind your code to that object. But that object itself can
change. Right now it uses MySQL. Later it can use Postgres, Oracle or
even flat files. No change to the code using it.
[color=blue]
> Does that make sense to you?
> Of course not![/color]

Of course it does!
[color=blue]
> You know where you need a databaseconnect ion and get it delivered somehow,
> singleton Object or global connection.
> Both are lines of code, and both deliver the same in the end: a working
> connection.
>[/color]

But an object is a lot more than a line of code.
[color=blue]
>[color=green]
>>Globals in general are bad ideas.[/color]
>
>
> Not if you need an outside variable inside a function.
> It is perfectly legal.
>[/color]

And this one statement tells me that you've never worked in a commercial
programming environment. What's "legal" is not necessarily "good
programming practice".
[color=blue]
> I could also deliver the connection by refrence every call to every function
> that needs the connection.
>
> No big diff.
>[/color]

Huge difference. But you obviously have made your mind up. Just please
- don't promote your poor programming practices on naive new programmers!
[color=blue]
> Please remember that we are NOT talking about globals as in ASP
> (Application), but just globals for the duration of the script.
>[/color]

Yes, I know EXACTLY what we're talking about!
[color=blue]
>
>
>[color=green]
>>Citrus's design is much better. There is a little overhead - but not
>>all that much.[/color]
>
>
> Yes, Citrus claimed the same.
> Also without any argumentation that made any sense.
>
> If you are so sure of the superiority of the Object approach, why can you
> not tell us why?
>[/color]

I tried. You obviously aren't listening![color=blue]
>
>[color=green]
>>And I find objects almost always improve the structure of my code. It
>>also makes it more flexible and configurable. For instance - I can
>>easily change databases simply by changing the database object. No
>>changes in my code are necessary.[/color]
>
>
> No changes in your code needed?
> Of course you need to change something in your code, the Object that makes
> the connection is changed by you.
>[/color]

No, the OBJECT code changes. MY CODE does not!
[color=blue]
> Now compare this to an include that delivers the connection: I also have 1
> place to change the connection, and it is included everywhere.
> Then everywhere where 'global $connection;' is used, the connection is
> up-to-date.
>
> Don't try to sell nonsense to me.
> I developed years and years in Java, and do not fall for laymans arguments.
>[/color]

I've been programming since 1967 (in Fortran I). I've written C++ for 18
years, some of them as a programmer for IBM. I've been writing Java for
over 10 years. And since then I've been a successful consultant,
writing code and managing projects.

Hardly a layman.
[color=blue]
> Please give me a serious response that dives into the issue instead of
> claims that are clearly not true.
>[/color]

I have, but you obviously have made up your mind.
[color=blue]
>
> Another thing: In PHP Objects are only halfhearted and last only for the
> duration of the script. They are not persistent. (Unless of course you
> serialize and deserialize them from script to script, but that is not
> exactly persistent.)[/color]

So? The same is true for any program!
[color=blue]
> Object in PHP are nothing more than a bundling of some functions together,
> and their own namespace. Really that is all there is to it.
>[/color]

And you obviously don't want to understand.
[color=blue]
> Don't try to make more of it than that.
>
>
> Heck - I can even use flat files when
>[color=green]
>>necessary!
>>[/color]
>
>
> So can I, but what has that to do with this issue?
> Are you suggesting that Objects are the next step in evolution of the
> $connection in scripts? Haha.
>[/color]

The fact is - I can do it without any changes to my code!
[color=blue]
>
> Regards,
> Erwin Moller
>[/color]

But this conversation is at an end. I don't argue with close-minded idiots.

Here's a tag line for you:

"My mind is made up. Don't confuse me with the facts!"

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[Erwin Moller]

Re: OOP PHP with MySQLi

Jerry Stuckle wrote:
[color=blue]
> Erwin Moller wrote:[color=green]
>> Jerry Stuckle wrote:
>>
>>[color=darkred]
>>>
>>>Yes, bad programming. It binds all of your code to the variable
>>>$connectio n, among other things.[/color]
>>
>>
>> No, I use it only in functions that need the connection.
>> If a script needs the connection it gets the connection by means of a
>> include at top of the script.
>>[/color]
>
> Yes, and declaring something global has its own overhead.[/color]

Like putting the reference into the global-array?
Wow, THAT is overhead.

Let's double the memory in the server right away!
[color=blue]
>[color=green]
>>
>> If you need to change that you have a
>>[color=darkred]
>>>huge amount of code to change.[/color]
>>
>>
>> Why should somebody want to change the connection-object?
>> It is needed for database-access.
>> If I need to change that I am really making a new program.
>>[/color]
>
> Well, lets say you change hosting companies - and the new one uses
> PostGres. Or you want to use the code on something which requires
> Oracle access. Or any number of things.[/color]

In that case I change my connectstring IN ONE PLACE.

Just as you do in your connection-object.

Your point being?

[color=blue]
>[color=green]
>>
>> It also makes the code less portable.
>>[color=darkred]
>>>Also, if $connection gets changed someplace, you'll have a hell of a
>>>time trying to debug it.[/color]
>>
>>
>> Sorry, thanks for replying, and I do not want to pick a fight with you,
>> but this doesn't make sense.
>> I can say the same for your object-oriented approach, look:
>>
>> - If you use an (singleton) Object to deliver the connection, you bind
>> all your code to that object.
>> and
>> - If the connection in the object somehow get changed, all code breaks.
>> and
>>[/color]
>
> First of all, it was not MY singleton object. But it's a heck of a lot
> more portable than yours is.[/color]

That is what you keep claiming.
Now give some argumentation please, because I know what your opinion is, and
honestly, it is NOT getting any more convincing by repeating it.

[color=blue]
>
> Yes, you bind your code to that object. But that object itself can
> change. Right now it uses MySQL. Later it can use Postgres, Oracle or
> even flat files. No change to the code using it.[/color]

That depends solely on the fact if you use a databaseabstrac tionlayer or
not.
You cannot just 'change database' without one, and you know that.
A lot of SQL-functionality is implemented differently on different
databases.

You need some ODBC or ADODB or another approach to reach that flexibility,
and it has zero to do with how some connection-object is found in a script.

If you do not agree, tell me why.

[color=blue]
>[color=green]
>> You know where you need a databaseconnect ion and get it delivered
>> somehow, singleton Object or global connection.
>> Both are lines of code, and both deliver the same in the end: a working
>> connection.
>>[/color]
>
> But an object is a lot more than a line of code.[/color]

Really?

My eyes are opening....

[color=blue]
>[color=green]
>>[color=darkred]
>>>Globals in general are bad ideas.[/color]
>>
>>
>> Not if you need an outside variable inside a function.
>> It is perfectly legal.
>>[/color]
>
> And this one statement tells me that you've never worked in a commercial
> programming environment. What's "legal" is not necessarily "good
> programming practice".[/color]

I think you don't see the difference between a global in PHP and a global in
other many other languages.

Globals in PHP last for the duration of the script whereas the more usual
global means something is available to all processes running.
for example: In J2EE you can store stuff in ServletContext, In IIS/ASP in
Application, and that is where they stay, can get corrupted, etc.
But that is not how things work in PHP.

Go study the subject a bit more, then come back and try to insult me.
Ok?

About the commercial programming environment: Don't worry. Been there.
Did that. They pay me well. :P
I run my own softwarecompany now for years.
Mainly so I do not have to cooperate with zealots with low coding-experience
that resonate with each and every hype they hear about.

OOP?
Learned it, liked it, use it when appropriate.

Once again: I have 0 problems with somebody using a singleton database
connection design. 0 problems.

I DO have problems with your arrogant attitude.

If you were speaking with any authority, I might learn a thing or two, but
so you only repeated your invalid arguments.
Back them up.
[color=blue]
>[color=green]
>> I could also deliver the connection by refrence every call to every
>> function that needs the connection.
>>
>> No big diff.
>>[/color]
>
> Huge difference. But you obviously have made your mind up. Just please
> - don't promote your poor programming practices on naive new programmers![/color]

I haven't made my mind up.
I can live easily with both approaches as I told you.
The problem is you seem to think for some reason the object-oriented
approach of delivering a connection is superior, which is not true.

[color=blue]
>[color=green]
>> Please remember that we are NOT talking about globals as in ASP
>> (Application), but just globals for the duration of the script.
>>[/color]
>
> Yes, I know EXACTLY what we're talking about![/color]

So please explain all the fuss you make.
I haven't seen any argument yet.
(I am serious)
[color=blue]
>[color=green]
>>
>>
>>[color=darkred]
>>>Citrus's design is much better. There is a little overhead - but not
>>>all that much.[/color]
>>
>>
>> Yes, Citrus claimed the same.
>> Also without any argumentation that made any sense.
>>
>> If you are so sure of the superiority of the Object approach, why can you
>> not tell us why?
>>[/color]
>
> I tried. You obviously aren't listening![/color]

I responded in the earlier thread with to your and citrus' claims, but you
didn't bother to respond yourself.
Get a mirror man.
It is you who isn't listening.

[color=blue][color=green]
>>
>>[color=darkred]
>>>And I find objects almost always improve the structure of my code. It
>>>also makes it more flexible and configurable. For instance - I can
>>>easily change databases simply by changing the database object. No
>>>changes in my code are necessary.[/color]
>>
>>
>> No changes in your code needed?
>> Of course you need to change something in your code, the Object that
>> makes the connection is changed by you.
>>[/color]
>
> No, the OBJECT code changes. MY CODE does not![/color]

Aha, now I get it.
The Objectcode is not part of the application in your view?

Get real.

[color=blue]
>[color=green]
>> Now compare this to an include that delivers the connection: I also have
>> 1 place to change the connection, and it is included everywhere.
>> Then everywhere where 'global $connection;' is used, the connection is
>> up-to-date.
>>
>> Don't try to sell nonsense to me.
>> I developed years and years in Java, and do not fall for laymans
>> arguments.
>>[/color]
>
> I've been programming since 1967 (in Fortran I). I've written C++ for 18
> years, some of them as a programmer for IBM. I've been writing Java for
> over 10 years. And since then I've been a successful consultant,
> writing code and managing projects.
>
> Hardly a layman.[/color]

Ok, great credentials.

Now show them off and write a decent response.
[color=blue][color=green]
>>
>> Another thing: In PHP Objects are only halfhearted and last only for the
>> duration of the script. They are not persistent. (Unless of course you
>> serialize and deserialize them from script to script, but that is not
>> exactly persistent.)[/color]
>
> So? The same is true for any program![/color]

Nonsense.
In Java Objects happily exist in memory (or swapped for that matter) for
months and months.
If memory servers me well I have a few around for some years now.

PHP has to serialize them, generating a string, and revive them where
needed.
Really, that IS something else than being in memory and in-process.
PHP is not really OOP. They just added the possibility to use objects. Good
move by the way.

[color=blue]
>[color=green]
>> Object in PHP are nothing more than a bundling of some functions
>> together, and their own namespace. Really that is all there is to it.
>>[/color]
>
> And you obviously don't want to understand.[/color]

Well....

Where did I hear that before?
Hmm, let me see....
I remember! It was some guy telling me I could find peace if I followed his
God. Yeah that was it.
I asked him why I should follow his God while so many others are around too.
I didn't want to listen, so he told me.

Well, I DO listen. Give me something reasonably to think about!
[color=blue]
>[color=green]
>> Don't try to make more of it than that.
>>
>>
>> Heck - I can even use flat files when
>>[color=darkred]
>>>necessary!
>>>[/color]
>>
>>
>> So can I, but what has that to do with this issue?
>> Are you suggesting that Objects are the next step in evolution of the
>> $connection in scripts? Haha.
>>[/color]
>
> The fact is - I can do it without any changes to my code!
>[/color]

We have been over that before.
You DO have to change your code, how else will the object know its
connectstring or databaseserver or whatever changed?

When using a connection that is included above every php-script you also
have only 1 place to change that.

Really, I do not see any advantage here.
If you do, tell me.
[color=blue][color=green]
>>
>> Regards,
>> Erwin Moller
>>[/color]
>
> But this conversation is at an end. I don't argue with close-minded
> idiots.[/color]

As you can see: I DO agrue with idiots.
[color=blue]
>
> Here's a tag line for you:
>
> "My mind is made up. Don't confuse me with the facts!"
>[/color]

Sounds very kinky and cool, really!
The kind of line you can use everywhere to make your argument sound more
worthwhile. Readers Digest?

Erwin