Yeah, basically if you're using PDO for dbs, and you're using a framework which uses MVC, how would you change the code?
I was assuming you would just use the classes in the MVC but then you wouldn't be using the benefits of PDO?
Does that make sense?
PDO is a consistent interface for accessing databases in PHP while MVC is a software design pattern. Stating that , I believe that is clear that you can have MVC without the use of PDO or with it , and of course the use of PDO in a MVC or outside it.
I strongly believe that PDO (with prepared statements) is the best way PHP has to connect and make requests to a DB. Also I believe that MVC and its variations is still the cleanest way to build a web application and more over in the OOP world it is now a common ground. So using PDO in a PHP project that is build in MCV design pattern is obvious to me.
One of your phrases me really puzzled me “I was assuming you would just use the classes in the MVC but then you wouldn't be using the benefits of PDO?” what do you really mean? In what classes are you referring to?
There are many ways to use PDO in a MVC architecture, it all have to do of how you define the Model and it’s db layer (Of course some may have use a db layer in the Controller but I really think that this eliminate some major benefits of MVC). What I think as the logical way to go (without canceling other approaches) is having your DB object (that is a child of PDO) instantiating in the Controller (or in the Front Controller) and pass it to the Model where it will be used to return results (objects or list of objects) or to make modifications to the DB.
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.