Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community!
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.Start your free trial
Robert Walker16,514 Points
PDO and building your own framework
Ive asked a couple of questions about PDO before and got a little feedback but im currently trying to build my own framework just as a lesson in learning what goes into it and the problems you face, as I say this is more a way for me to learn about things that I normally wouldnt.
Ive read a lot about PDO but when it comes to how I should best use PDO in a large project things become very unclear, should I just write a database class for the connection only and then use PDO methods directly in the classes that use them or do I have a database class with CRUD.
From looking at other peoples projects, a lot of them use a database class to build the connection then have a few methods like insertRow, lastInsertedRow or deleteRow.
Then there are some I see where the database class is just the connection and their classes use PDO methods in them directly to perform tasks.
I sort of like the idea of both but still totally confused on which would be best if either at all, some people say you should only use PDO and not build any wrapper for it.
Ive tried both ways and as I say i like both, most of the time these things I find come down to what you want to do or how you like to work best but on this I would really like to know more about the upsides and downsides before just going with what feels better for me.
I really would love some input on this, links to articles you may have of read before, just a general discussion on what other students or teachers think about it.
I would suggest thinking about what to do referencing SOLID. SOLID is a group of principles for object oriented architecture.
The 'S' in solid stands for "Single Responsibility Principle". It says that an object should only be responsible for handling one (single) thing.
So in your case, I'd suggest making several objects that are responsible for all your steps. Should the connection object also handle interactions (In other words, should the thing that's making the connection also be responsible for adding and deleting rows)? Probably not.
Maybe start by identifying all the base tasks that need to be completed and structure your design around those jobs. Then you can go as simple/complex as you like.
E.g. you might have
- Something that does connecting (connecting to a database type)
- Another thing that does interacting (adding and removing rows)
- Another thing that handles CRUD (which you could put in a controller or model)
So your CRUD/controller level object will say "I want to delete this!", then you're interacting object will "Do the deleting" after asking the connection object to "make a connection".
I would 100% create a wrapper around PDO. Imagine if PDO was deprecated? You would have to go around updating your whole application! Also what if you change to, say, SQLITE instead of MySQL?
It's tricky to get right without building a full ORM (Object Relational Mapper), it might take a few goes!