Jump to content
#StayAtHome ×
phppup

procedural versus object oriented

Recommended Posts

Trying to get my head wrapped around the new MySQLi (versus PDO which looks a bit more intimidating for a newbie.. or am I wrong??)

and have found that W3schools.com has samples of both procedural and object-oriented code.

 

They seem very similar, but there are differences.

 

Is one more prefered to the other?  Is the code interchangeable within a script?  Is the code interchangeable at all?

 

Pros/Cons and necessities, requirements, expectations would be helpful.

 

Thanks.

 

 

Share this post


Link to post
Share on other sites

you don't have to understand object oriented programming (OOP) concepts in order to use OOP style notation for a preexisting class/object.

 

the base variable holds an instance of a class. you reference properties (variables) and methods (functions) of that class, referencing/calling a class method is not really any different from calling a procedural function. the PDO extension mainly has methods, making it simpler and more consistent in its usage than the mysqli class. there are only three PDO classes to deal with - PDO, PDOException, and PDOStatement. using OOP style notation is shorter than the equivalent procedural style (if using the mysqli extension.) 

 

here is a current thread concerning using/converting to PDO - https://forums.phpfreaks.com/topic/306282-to-convert-or-to-not-convert-to-pdo/ you will note that using the PDO extension will result in simpler code and has other benefits over trying to use the msyqli extension.

Share this post


Link to post
Share on other sites

converting existing msyql_ code to use the PDO extension is straight forward -

 

1. make a database connection using the PDO extension and store that instance of the PDO class in a php variable, such as $pdo. the connection should set the character set to match your database tables (UTF-8 is usually the best choice.) you should also set the error mode to exceptions, turn off emulated prepared queries, and set the default fetch mode to assoc (so that you don't have to specify it in each fetch statement.)

 

2.a.) if the sql query does not have any data values being supplied to it, just use the PDO ->query() method to execute the query. this returns a PDOStatement object for referencing the result from the query.

 

at this point you can test or fetch the result from the query.

 

2.b.) if the sql query does have data values being supplied to it, you would remove any existing php variables, quotes around the variables, any concatenation dots, and replace each value with a simple ? place-holder.

 

call the PDO ->prepare() method to prepare the query. this returns a PDOStatement object for calling other methods, including referencing the result from the query.

 

call the PDOStatement ->execute() method with a php array containing the php variables that were removed from the sql query statement.

 

at this point you can test or fetch the result from the query.

 

----

 

if you are going to the trouble of converting existing code, this would be a good time to implement a programming practice called 'separation of concerns'. what this means is to separate code that has different meaning/purpose. the database specific code, that knows how to query for and fetch the data, is a different concern from the code that knows how produce the output from the data. the way to accomplish this is to simply fetch the data (or other result from the query) into a php variable named for the meaning of the data, then just use that php variable as the input to the code that knows how to produce the output from the data.

 

if your existing code was already doing this, converting to a different database extension (or getting the data from some other data source) would have been simple. you would just fetch the data into whatever php variable has been defined for that purpose. however, your existing code probably has various fetch and num_rows statements embedded in the code that's responsible for producing the output from the data. since you will need to find and change this code as part of the current conversion, if you change it to use a php variable as the input, you won't ever have to change it again if you have to convert the code to use a database type that PDO doesn't have a driver for or for a different data source, such as an API that returns json/xml encoded data.

Share this post


Link to post
Share on other sites

Is one more prefered to the other?

OOP code is generally considered to be "better" than procedural code by the programming community.

 

Is the code interchangeable within a script?  Is the code interchangeable at all?

Absolutely. The OOP methods and the regular functions are the same things, just usable in two different (but similar) ways.

Share this post


Link to post
Share on other sites

Given that the procedural versions are wrappers for the object versions

 

eg

function mysqli_query ($conn, $query)
{
    return $conn->query($query);
}
then calling the object version is always going to be marginally more efficient as it avois the intermediate function call.

Share this post


Link to post
Share on other sites

Given that the procedural versions are wrappers for the object versions

Actually it's the same code for both. Internally the function and method are both mapped to the same implementation and the $link parameter is automagically filled in using $this if the code was invoked during a method call.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.