""MEM"" <talofo@xxxxxxxxx> wrote in message 002001ca0898$5d183840$1748a8c0$@com">news:002001ca0898$5d183840$1748a8c0$@com... > > As for (1) even in my pre-OO days I was used to using a single > > generic DAO for all database access. The only time that more > > than one DAO existed was for a different DBMS engine. This > > is why I have one DAO class for MySQL, one for PostgreSQL > > and another for Oracle. If you are incapable of writing a > > single generic DAO then it just shows that you still have a lot to > > learn. For an idea on how this works take a look at > > http://www.tonymarston.net/php-mysql/databaseobjects.html > > I'm absolutly sure that I have a lot to learn. Really a lot. :-) > I have post some days ago, a way for using a generic CRUD class and DAO, > but I get no replys so I wrongly suppose that my question was a > nonsense question, and that CRUD and DAO would be a nonsense. > > I'm trying to use PDO with prepare statements and BindParam, so I'm afraid > that my "newbility" doesn't allow me to pass directly from your example to > one that uses PDO. Why not? Why can't you replace a call to a mysqli function with a call to a PDO function? > 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. > with also puts your tutorial far away from my capacities. Because of > this, I'm trying to follow what I can get on the web, using PDO and > general > CRUD operations: Why don't you learn how to use the mysqli functions before you handle the switch to PDO? What do you have to lose? > BUT: > > Here: > 1) http://oopgarden.richardknop.com/index/view/1 > > or Here: > 2) http://phpro.org/tutorials/Easy-Access-With-PDO-CRUD.html > > when we have to create complex querys by using limits, order, etc... > either > they are inexistent possibilities (like on the link 2), 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. > or, like on link 1 > they are so close to the equivalent sql sintax that I'm questioning the > advantage of having a general DAO CRUD class at all (supposing that the > only > advantage is that we write less words on the code). Having less code to maintain is *precisely* the advantage of having a single DAO. If you design it correctly then you can switch from one DAO class to another in order to switch from one DBMS engine to aother. > Please advice, besides the fact that we "never have to code any of the SQL > SELECT, INSERT, UPDATE or DELETE statements for any table as they will be > generated at runtime.", is there any other advantage on using a general > DAO > class instead of one DAO class for each table? 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. 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. -- Tony Marston http://www.tonymarston.net http://www.radicore.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
