As a personal side project, I am converting a bunch of PHP developer tools that I made for myself (To Do list,
Task Timer, Appointment Scheduler, Client Manager etc) into a PHP OOP application, and I am trying to streamline my code.
If I use * in all my SELECT statements, I can use the same class method over and over again in different circumstances and just use the fields that I am interested in. But popular consensus seems to be that this is the lazy way to do it.
I am not worried about its inefficiency because obvously my database tables will not ever be nearly large enough for it to make a difference. But if I use specific SELECT statements depending on what I need, I will have to write all sorts of tiny methods in my classes, one for each situation.
My third choice is to write the queries in the page files, and pass them in to the SELECT method of the class as a parameter.
Which would be the best way to go? I’m trying to settle on good practices right at the beginning so I’m not always refactoring my code every time I come across something that seems to be a better way.
I would just tell you to use composer with doctrine or propel and not worry about any of that. Better yet rewrite the applications on a proven framework like Symfony or Laravel which have all that low level crap already done for you. You could also cherry pick over Symfony components as you need them. With something like this I would rather spend my time building the application rather than dealing with low level details like routing, data persistence, templating, dependency management, etc. However, I know there are people out there who love wasting time reinventing the wheel so to each their own.
It’s a learning experience for me. I am also working on learning the different frameworks, but this particular project I would like to build from scratch. I’m looking for efficiency and speed in the making of this project, I’m looking to deepen my understanding of what is the best way to code applications so that I can understand better the inner workings of the frameworks and other applications.
So when I come across something that I am puzzling about, I don’t want to just avoid it and use the most efficient method. I want to solve my puzzle.
I think I would be able to make better use of the frameworks, if understood thoroughly and could work with all that “low-level crap” too.
Nah, you would be better served in the trenches of a framework off the bat. I know it can be tough because of the lack of ownership of what you’re creating. However, focus on making a kick ass application not the low level technologies. If you do that than you will not only build something great but also indirectly learn about all the latest and greatest design patterns, etc.
Years ago, I also built a framework or two from scratch. And now, looking back, I don’t think it’s nearly as much of a learning experience as we assumed it would be. Mostly you end up just rehashing ideas already in your head rather than learning something truly new. Later I started learning Symfony, both how to use it and how its internals work, and that exercise furthered my knowledge by leaps and bounds.
I’m with oddz. You’ll be better off learning other frameworks and how they work. And as a bonus, when you’re done, you’ll have a marketable skill.
Okay, so I have a client project waiting in the wings for them to nail down the specs. They want a simple CRM and nothing ready-made fits the bill for them. Which framework do you think I should use for this - because that will be my choice of frameworks for learning thoroughly at this time and I will use my project to learn it. Up to this point I have just been dabbling in them.
By the way, I still want an answer to my question.
What’s the reasoning against select *? Someone may have said it’s lazy, but that doesn’t tell us why the alternative is better. The only rationale I can think of is efficiency, but I think you’re right to not worry about that here. Assuming you don’t have an obscene number of columns, then this isn’t a significant optimization.
I would recommend Laravel since it provides better ground-work for building a complete application. Symfony is a little lack luster in that regards and leaves it to the developer to fill in many gaps that Laravel fills for you. Also Laravel favors code over configuration defining all “configuration” in plain jane PHP rather than YAML which can sometimes be a little cryptic to understand. As far as a database persistence layer goes I’m partial to ActiveRecord myself so I use the internal library Eloquent but would probably recommend using Doctrine :/. I just think Eloquent is pretty cool with it’s support polymorphic relationships and what not but probably Doctrine is the more “concrete” choice.
with * if you change your DB (layout/columns), the SQL code keeps working and the PHP code keeps failing for no obvious reason. if you have written down every column, once such a column does not exist any more, SQL itself will throw an error at you.
I’d second what @oddz said about learning Laravel. If you do decide to go down that route, I’d definitely suggest checking out Laracasts - it’s full of video tutorials that cover not just the various aspects of building apps in Laravel, but also other useful topics like unit testing and design patterns etc. It’s a subscription-based site, but there are some videos you can watch for free to get a flavor of it.
in that case I would question if the approach is—design-wise—a good decision. what good does reusability do if it compensates it with error susceptibility?
Laravel strengh lies in bringing together a bunch of different projects in unity to provide a mostly none proprietary ecosystem of tools to accomplish common development tasks. While also making it possible to swap out those tools for your own through providers and contracts. Nearly everything in Laravel is interchangeable and replaceable. Furthermore, the advantage using outside resources has an added benefit of avoiding learning only proprietary ways of doing things that can transition to other frameworks and projects which may use those libraries even though they don’t use Laravel itself. You really get the most bang for your buck in terms of learning using a system like Laravel that doesn’t attempt to reinvent wheels that don’t need to be reinvented.
Where the structure of the table is changed the fields returned may no longer be what the subsequent code expects (depending on how the subsequent code is written)
Where the different fields have different security access so that which fields are returned depends on who makes the request.
The first of these would only occur if the subsequent code is written to depend on fields being in a particular order rather than accessing them by their field names and so can be resolved by writing the subsequent code to get the fields needed without worrying about their order or whatever other fields are there that are not needed.
The second of these never occurs in small applications. In the situations where it does occur the person writing the SQL would be in a different department from the person writing the application code and so how the SQL is written would be irrelevant to the person working on the application.
