On 06/20/2016 02:49 PM, Stephen wrote:
I have made a number of web sites using PHP and mySQL. These included
a control panel for adding and maintaining content.
I am stepping up and creating a site that will require sessions,
private areas and user registration functions.
I have looked at samples and note that they all use many small files.
I see that as being difficult to manage.
But I have also looked at the code for a PHP bulletin board. Many,
many small files, so I see that it is a common practise. But I see it
as complicated and difficult to manage.
For my control panel code I have all the routines, about 10, to
process POSTS in one file. It works fine.
Now activity is low, but that will also be the case with my new site.
So my question: Is small, single function, files the best practise, or
I am just fine in combing many functions into larger "library" files.
Thank you for your thoughts.
If you're using a mostly procedural code base, then clustering functions
into manageable chunks makes sense. One function per file is ridiculous
and unmanageable.
If you're using a mostly OOP code base, you want to be relying on an
autoloader; the standard autoloader for PHP is one built on PSR-4, and
most people/projects are using Composer which takes care of all of that
for you. PSR-4 mandates one class per file, with a specific naming
convention, to keep the autoloader logic as simple as possible. If you
have an OOP code base, that is the only way I would recommend building
your system.
That can result in lots of disk hits, that's true. If you're not using
an Opcode cache, that can be a problem. If you are, then it's only a
small problem. (And if you're not, it means you're using PHP < 5.5,
which means an unsupported version with known security holes. UPGRADE
NOW!) You can also set your opcode cache to not check the disk for file
changes once it's parsed a file once, which can eliminate most (although
not 100%) of the remaining overhead; certainly it will bring it into an
acceptable cost, where you'd be better served worrying about your SQL
queries than the autoloader.
The downside is that you will need to flush your opcode cache (usually
by restarting the web server process) when you change code. For that
reason, you'll probably do that only on production, where if you're
updating code bouncing the web server is something you can/should do
anyway. (Or even better, have a container-based deployment where you
simply switch requests to a newly built container.)
Generally speaking, "class per file and don't sweat it" is the
conventional approach, and what I'd recommend in most cases.
--Larry Garfield
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
