> Why not? Why can't you replace a call to a mysqli function with a call > to a > PDO function? It's not just a simple replacement - I need to add bindparam, prepare, execute, placeholders and fetchObject. But I will give it a try... > > Also, I also intend to use fetchObject method instead of fetchAssoc > quite > > often, > > Why? What's the benefit? The fetchAssoc method gives you an array of > values, while the fetchObject method gives you a container for an array > of > values. You still still have to work with an array of values. FetchObject maps the field names from the database as object properties with the values stored in the database. Seems quite nice. Then, to access a specific column data I just needed to: $myhandler->my_database_column_name (it seems quite nice to me) :) > Why don't you learn how to use the mysqli functions before you handle > the > switch to PDO? What do you have to lose? I already work with PDO so, no need to switch. :-) > If you read my tutorial you should see that building a SELECT statement > is > nothing more than combining several small strings into a larger single > string. String manipulation is simple in PHP. Using this technique I > can > create very complex SQL statements, so don't tell me that it can't be > done. I was not talking about your tutorial. I was talking about those two links, mainly the first one where, unfortunately, the difference between the code and the sql sintax is that we don't have the word SELECT and WHERE. :s However, as a positive point, this class uses BindParam and ? placeholders. But I get your point, we can cut it into smaller strings. > Because you have less code to maintain. If you look carefully you > should see > that the only difference between the DAO for TableA and the DAO for > TableB > is the table name and the table structure. If you could pass these as > arguments into a generic DAO then you would not need a separate DAO for > each > table. Yes. But you still need, for each table, to fill one or several (depending on what mysql connection method we use) arrays with values. So that "less code" maybe isn't that much in a way where you *significantly* reduce your maintenance burden, if you take into consideration that we take the queries for each table, but a) we add arrays and b) use a less intuitive way to add/remove/delete values to the database. As an example I have give link 1, where the difference was more or less two or three words - and the way to use the arrays where far more complicated to understand then a simple Select Sintax - hence, not that relevant. > OOP is about creating reusable code to reduce the maintenance burden, > so if > you insist that a separate DAO for each individual table is the way to > go > then you don't understand how to apply the principles of OOP correctly. I will never insist just because some silly reason comes to my mind. I will however not follow a method without knowing the reasons and be convinced of them. I'm not 100% convinced of the reducing benefits for the reasons a) and b) stated above, still, maybe I get more benefits the more I add methods to the DAOs. In the next few days I will try to, based on your code, create a general DAO class that deals with PDO. And post back my frustrations back here. :D Please have patience. :D Regards, Márcio -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
