It has recently been highlighted (in my previous questions) that the way I have designed web applications is not ideal.
Consider the following. I am working on a multi-user website with lots of different sections including profiles and forums and support tickets. The structure is as follows:
A main page in which all the other pages are included or *required_once* we'll call it home.php.
In home.php, one of the first things loaded is router.php, this handles every single $_GET and $_POST that the user could possibly produce, and every form and process is sorted via a main variable called $data_process. Router.php is essentially just one giant switch() statement for $data_process. This parses all the data and gives a result.
Next included is header.php, which will not only process the neccessary variables for the page that will be loaded but also set up the header and decided exactly what is going to be shown there, e.g. menu, user info, and information about the page currently viewing (i.e. Home > Support > View Ticket).
Then the page is loaded according to $page variable. A simple include.
Then footer.php, then close.
And so the dynamic website is created. I was told this is bad practice by a user named #HorusKol. I am very pleased with this website as it is the most streamlined and easy to write website I have ever used. If this is still bad code design? What is perfect code design?
PS - can anyone recommend any good easy to read books that explain PHP, MySQL and design structure for me?
It is bad design because you process a lot of data that is perhaps not necessary in the rest of the process. The router should only process the url, processing of post data is handled somewhere else. Only include what you need, including everything makes things slow.
A better way is to structure you app more in different parts. A router that is processing the url, a controller that runs a action based on a routed request, a view that processes all html and pages, a model for accessing data. MVC is what comes in mind.
There is no such thing is the perfect code design.
There's no canonical definition of "good design" - the best you can hope for is that your design balances the various forces on your project in the optimum way, Forces on your project might be maintainability, performance, scalability, extensibility - classic non-functional requirements - but also things like search engine optimization, standards compliance and accessibility (things that apply to web projects in particular).
If all your URLS are of the form "www.mysite.com/home.php?action=getDetails&productID=123", your search engine friendliness is pretty low. It's far better to have semantic URLs - "www.mysite.com/products/DesktopPc/details.php". You can achieve this through cunning .htaccess trickery in your current design.
From a maintainability point of view, your design has some issues. If I've understood it correctly, adding a new page to the site requires you to modify the code in several different source files - router.php (your giant switch statement), the page itself, and probably the header.php as well. That indicates that the code is tightly coupled. Modifying the giant switch statement sounds like a likely source of entertaining bugs, and the combination of the router and the header, manipulating the variables, plus the actual page itself seems a little fragile. This is okay if you're the only person working on the project, and you're going to be around for the long term; if that's not the case, it's better to use an off-the-shelf framework (MVC is the current favourite; Zend, Symphony and Cake all do this well in PHP) because you can point new developers at the documentation and expect them to get up to speed.
One of the biggest enemies of maintainability is complexity - complex code is harder to work with, and harbours more bugs. There's a formal metric for complexity, and I'm pretty sure your switch statement scores very highly on that metric - in itself not necessarily a huge problem, but definitely something to keep an eye on. Lots of MVC frameworks avoid this by having the routing defined as data rather than code (i.e. have the routes in a configuration file), and/or by using convention over configuration (i.e. if the request is for page "productDetails", include the file "/inc/productDetails.inc").
Extensibility could be another concern - imagine having to expose your site content as JSON or XML as well as HTML; in your current design, that would require a lot of change, because every single item in your page processing pipeline cares and needs to know. The home.php needs to know not to send HTML, the header and footer need to know, the router needs to understand how to handle the additional data type, almost certainly making the switch statement even bigger. This again may not be a big deal.
Both extensiblity and maintainability are helped by being able to unit test your code. Test Driven Development turns this into a whole routine in its own right; I'm guessing that testing your application is hard - but that's just a guess; it depends more on how you've factored the individual lumps of code than what you've described above. However, another benefit of MVC is that it makes it easy to write unit tests for key parts of your system.
So, if the forces on your project don't include an emphasis on maintainability or extensibility, and you can handle the SEO aspect, I don't think your design is necessarily "bad"; even if you do care about those things, there are other things you can do to accommodate those forces - write documentation, hire lots of cheap coders.
The best way to get up to speed with these design topics are not books on PHP or MySQL; I'd recommend "Refactoring" and "Patterns of enterprise application architecture" by Martin Fowler, "Design Patterns" by Gamma et al. and Code Complete by McConnell (though that's a touch out of date by now).
Related
To start with I'm not exactly sure if this question will fit the question model of SO so moderators please close it if it doesn't fit...
I have been reading a lot on MVC and SoC lately and how they relate to programming in PHP and am having some difficulty grasping how the concepts differ to my current programming style. Any application I write uses url_rewrite routes, with the routing handled by a single file which selects the appropriate controller.php file based on the sub system requested. Then within that controller file the final smarty template file is assigned and the PHP file which contains the business logic of the page in question is included into the stack.
The issue I am having is that while I review MVC and SoC information all the examples I see are written as extensive inter-dependant classes and some rather deep namespaces, but when I code I only use objects where I need an object for reusable but distinct code (in line with object examples on the PHP site itself), and so wind up with some code being classed and namespaced nearly 70% of my application remains in the global namespace with no classing. It seems to me that this coding technique still meets the design principal of separation of concerns, though i'm not so sure about being MVC as every example of MVC I can find is built solely out of a very large number of classes.
Could someone please explain if I am way off base here or if I am achieving SoC and possibly even MVC with my current coding and explain to me if embedding the entire application within a range of classes is a requirement for SoC and MVC.
Thanks
OK I usually take on these open ended questions :P
Let me rephrase your whole thing to a new question – and feel free to tell me I am wrong!
I think you are asking - “Is my coding style in-line with best practice for x y z?”
Now look – i have been in a variety of roles, and I strongly believe that no one has ever cracked a complete SoC architecture – at some point there is always a trade-off between enabling someone at the view end to do their job, and someone upstream ingesting the input and making it work such that it ties to the database and logic.
For example - I am actually right now building a system that takes HTML files as input, reads them via PHP. PHP converts the HTML elements to a bunch of JSON and adds logic to that JSON based on x, y and z, then shoves it out to Facebook React components – which converts it all back to HTML / DOM – when you explain to someone that there is a sausage machine that takes, as input, HTML, and outputs HTML, you can see why they might go – holy shit what are you doing!!
Now – why did we do this? Because it made sense for the project, and it made sense for the team. We could have equally used some pre-defined framework and blah blah blah – however this worked for us.
(a caveat here would be, if you need a highly performant application, this might be the wrong approach, however – bear in mind that what you read (inter dependant classes etc.) may also not be performant – optimisation of PHP code is hard work – my advice here is, get it working first, then if the product is successful, pay someone to fix your shitty code – server time is cheap – your time is not)
My statement for you would be, without concrete examples and use cases – people will struggle to comment on your approach – but understand that there are many different ways of doing things and you may see much open source code written in one way or another, but if you write something that achieves a goal, your only concern should be that it is performant and that it has ‘enough’ separation such that your designer can work on design, your coder can work on code and your CEO can look at sales figures.
Hope this helps.
From the information you've given, you're doing a good job. I think you have a grasp at Separation of Concerns and probably MVC. I think you should take a closer look at how things are abstracted in other codebases, how things are modularized, and think about how you would handle things that potentially come up in web development.
What if I want to have some code run before every controller? Or middleware that runs between the request and the controller? Or inject a variable into the view after every controller is processed? How are you separating POST, GET, PUT, DELETE logic but still grouping them within a resource? Some of these can be achieved with your architecture but I think many of the solutions would be cleaner with a class-heavy architecture. Of course, something being cleaner is in the eye of the beholder.
Frameworks released to the public try to be generic and tackle as many use cases as possible. One issue I see is that you make the assumption that the controller file would be called last and then setup the view. So, even though the logic in there is in the global state, it only exists within that file. In essence, the file acts as a namespace. I don't think that's an assumption a generic web framework should make, but it's something you can get away with when writing something for yourself.
There is a lot of good content on SO about MVC and getting started with MVC, but I'm having trouble finding anything about how best to implement MVC structure on a pre-existing, live website.
My site is a nasty mishmash of echos and concatenated HTML that would make any professional programmer throw-up, but it works.
I'd like to spend some time tackling the mounting technical debt, however, and that means moving to a much more sane MVC structure.
If at all possible, I'd like to avoid a let 'er rip! 100% rewrite and launch approach, and instead take it a section at a time. But it seems the basic controller's centralized structure is not suitable for such an approach?
If i understand what is the overall level of quality for that codebase , then there is no way to move to MVC in one step. It is just impossible. Another bad news is that frameworks will not help. They cannot magically transform a bad codebase into something resembling MVCish architecture.
Instead you should focus on incremental refactoring. Your goal should be code that is mostly following SOLID principles and LoD. And while you refactor your code , the architecture will emerge by itself. MVC has many variants and flavors.
One definite thing you might want to look at are the ways of using templates in php. Examine the code, and see what you has to change to fit your needs (it is more of a direction, not a complete solution). And remember that in MVC-like structures View is not a template, but it View uses multiple templates.
Another thing you might benefit from is learning more about datamappers. Implementing them would be a good step in direction of creating model layer.
Oh .. and then there are few general lectures you could take a look at ( all are 30min+ ):
Advanced OO Patterns
Clean Code I: Arguments
Clean Code III: Functions
Don't Look For Things!
Global State and Singletons
Inheritance, Polymorphism, & Testing
Oh , and this book has some insights into refactoring large php projects. Could be useful for you.
i agree with the other suggestions here, a framework isn't going to be a magic fix.
however it can help in the long run.
i have converted a number of mishmash sites to kohana framework now, and have had the following experiences.
initially i didn't know kohana well enough, so i was learning that while recoding mysite. I ended up stopping the rewrite and coding a completely new project from scratch to learn kohana, then went back to the rewrite project, now that i understood the framework better.
if you don't understand the framework, it is going to be a steep learning curve trying to use it to convert an old project
first step in the rewrite was to pull all the business/database logic embedded into the pages up to the top of each page (prior to the html output). So that i wasn't changing the flow/structure of the website, just separating business logic from display logic.
After that i had a site that had easily readable business logic, just in the old structure, and i had familiarised myself with the old codebase at the same time.
next step i did was to fix any database structure issues so that everything was in 3rd normal form (if possible).
i found it easier to modify the old code to the new database structure, then to work around and old database structure in the new framework. (kohana is largely a convention based framework, rather then configuration, so it was nice to follow those conventions, to ease long term maintenance)
having a good database structure makes life easier regardless of framework
next step was to pick a part of the website to replace. set up the routes in kohana and let kohana serve that part of the project. kohana (and other frameworks no doubt) have a fallback, if a file being requested via a url already exists on the site, then kohana won't handle that request
since you have separated the business logic from the display logic in your php files, it is a simple matter of splitting the code into a controller and a view. make the changes to both parts to suit the framework. you can split the business logic into model/controller after you have the controller/view working as expected
work your way through that part of the site, until complete. then test/launch/bugfix etc
then start again on the next part of the site.
eventually you will get there...
although it took a lot of time to rewrite, for me it was worthwhile, as the sites are far easier to maintain now. (obviously the amount of gain will be dependant on the quality of the original codebase)
good luck
it is possible to do. you can write your mod rewrites to only redirect to boot.php or whatever if no actual file is found at the requested path. this would allow you to do a section at a time. making sure all of your links are in order will be a nightmare however.
may wan to do a rewrite, and copy and paste peices you need out of the old application as you go.
This question can be applied to any programming language, but as I am thinking of PHP, I will phrase it accordingly...
I'm wondering if it is considered bad design/architecture if a web application uses action parameters, versus seperate files for each action.
For example:
/index.php?action=edit
Versus
/edit.php or /index/edit.php
I know mod_rewrite can translate a pretty-url to a parametrized url, but I try to avoid uneeded complexity when not necessary.
Thanks.
Quite often, for big applications, (especially with Frameworks, such as symfony, Zend Framework, ...) we tend to use one entry point : index.php.
That entry point will receive some informations (like your action parameter), that will allow it to route the request to the correct controller (or any equivalent you might have).
So, to make things short : no, using action parameters is not bad design / architecture.
Of course, this depends on the kind of application -- but, generally speaking, have a unique entry-point is quite a good idea.
Well I don't think it is a bad design - of course there is other possibilities - but overall it is about your in-house agreements between the programmers how you do it. As much as you can you should split the PHP and HTML code to make the development easier further on.
I prefer the MVC-coding style, which splits the PHP and HTML from each other as much as you "want it to".
Hope this is helpful :)
I would call both your examples at least outdated or short of best practice.
/index.php?action=edit
Doesn't look good and is therefore not user friendly and isn't SE friendly either.
/edit.php
Means that there is indeed a single file for each action which clearly is bad practice in the 21st century where we have great MVC frameworks which enable us to get rid of this clutter and keep the concerns separated.
A good URL looks for example like that:
mysite.com/user/profile/edit
meaning where in the user module, the user-profile controller and the edit action.
There is nothing actually bad in either, both can be used all right
Separate files considered to be better for the small application, to avoid unnecessary complexity as you said.
Action way is considered better to serve complex applications featuring single entry-point working as a boot-strap, initializing all the site features first and then calling appropriate module.
I just have to warn you against using such action in silly way, doing include $_GET['action'] in the middle of main 'design' file. it's both insecure and unreliable.
It depends on your requirements and scale.
Using separate files is ok. However, you will probably find yourself copying code and not properly reusing code and techniques. It's easier to do this with small, ad hoc applications, but could very well turn into spaghetti code or a jungle nest over time.
If you use a single point of entry (class loading with url handlers), you do have to learn how that works (CodeIgniter and ExpressionEngine are good MVC systems to use if you're not real good at it yet), but it's more consistent in coding practice, and scales better than a bunch of separate pages or a switch() statement you pass everything through.
It's not a panacea, either way, but most professional operations use something like an entry point with a class loading system (such as MVC).
About using mod_rewrite: mod_rewrite was not created and should not be used as part of your PHP architecture.
About having one file per logical element. This is a very good and practical way of separating logical units in your app. It way better than creating huge files with a lot of mixed logic inside, which will become unmaintainable as the app grows. This has no contradiction on having one point of entry and an MVC architecture.
Having action parameters is the most normal approach for CRUD controllers for example where makes a lot of sense to group actions to a common controller
// blog controller
-> create blog entry
-> edit
-> view
-> delete
-> list ( this is a very common addition to CRUD
all this have a common architecture in the sense that almost all accept an id and do related thing.
If you are talking strictly about GET parameters than you'll see that creating medium/large application where you direct everything from a file and the only thing changing is the get parameters will outgrow you very fast. Computer architecture is like real architecture, try to split thing in small, simple (maybe reusable) units.
I am creating the cms for a relatively simple site - portfolio, some general content pages, custom blog etc.
What are some of the best patterns to consider before diving into the design.
I want the system to be as flexible as possible without being too complex.
I have looked for some good resources that discus cms and blog design but can't find anything too good.
My language is php but I suppose I am looking for more language independent advice.
Flexibility without complexity... nice program.
Maybe you're a genius and you will make something that feet your needs. But I think the biggest problem you will face is security and robustness. So really, take other advices on this page and have a look at wordpress, drupal, joomla and ezpublish. A lot of security stuff is already done. And not only security...
So, study some of these tools, track their flaws, check their security policy. Study how they handle caching, sessions, bootstrap, absolute & relative url managment, documents (images, videos, etc), ajax, authentification, identification, acl, user interfaces, rich-text editing, migrations, templating, page composition, content filtering (I try to remove the things you won't need, plugins, database abstraction, fine caching, css and js minification, all the extra-complex stuff not needed for a single instance simple CMS). Soon you'll have a 'picture' of the stuff they've done.
By doing this work, you'll certainly notice some big differences, and mistakes. You'll start going on irc and flaming developpers, telling them that others have done better choices. You'll start forgetting to shave. You'll maybe do some contributions. Some will be accepted, others won't. Old core devs doesn't like when someone explain why they made mistakes (and they make mistakes).
Now, comes the day you have a beard. Some of your contributions will start looking like forks. You will have ennemies, and friends, or followers. And you will start feeling the force.
And you will go on irc and tell god that the world is ugly and that you'll make the first CMS which will be flexible without being complex. And people will cry. And birds will run in circles. And you will be able to explain what are the design pattern of a CMS.
I am a user. I know what I want. Doing what I want will make user happy. I'm happy.
You shall not trust code from people with glasses
"MVC MVC MVC" : and the people responds 'that shall be done'
Seriously, There's still a place for a good CMS with disruptive innovation, the fork history has started long time ago with phpNuke (as far as I can remember). But some of the actual products are really fine for most tasks.
I'm probably risking the reputation here, but my experience shows that building your own CMS can be a very justified decision, especially when you get familiar with current opensource systems and understand what exactly they lack in terms of features, security or what not. Open-source often means a lot of backward-compatibility concerns and bad architecture decisions that cannot be easily changed.
I strongly suggest that instead of just taking on MVC you take a look at ideas that make it attractive.
One main problem with CMSes is the range of technologies involved in driving dynamic web-sites: imperative php for logic, declarative SQL for data queries, markup HTML for interface, imperative/functional javascript for dynamic interface, JSON for ajax calls etc. To keep the system manageable you have to keep these technologies in a controlled and understandable environment, but yet allow for smooth integration. Knowledge and best practices are out there. MVC is but one approach to manage this problem.
My choice at the time was to use the following principles:
Object-oriented code with static calling (php is a one-run thing, many instances of code objects are rarely justified), nothing except for one line of init code in global context
100% code-design separation with the use of XSLT and custom content processor
Custom router that can take any http request and reroute it to registered methods
Custom content processor that can take arbitrary method output and convert it into any usable format such as xhtml, xml, json etc. based on the request parameters (i.e. http://local/class/method.xhtml, http://local/class/method.json)
One copy of code for as many virtual web servers as necessary
SQL query builder (chosen for flexibility over ORM) for all database queries
Mandatory filtering of method input with filter_* functions
I believe you can choose a few that you like :) And good luck!
A good pattern to start with is the Model View Controller pattern, or MVC.
This pattern suggests to seperate your application's logic in the following layers: data logic(model), manipulation or business logic (controller) and display logic (view).
This is a good pattern to start with as you'll run into other problems (and thus patterns) along the way.
The following website explains the MVC concept quite well: MVC Principles
There is no point reinventing the wheel unless you are trying to better it in anyway.
THere are a lot of CMS available already. I personally have worked with ezpublish. There are other options such as drupal etc. This is the list of all open source cms avaliable - Click here
If you are just trying to learn then you can perhaps pick any one of the popular opensource and work on them to find its architecture and design.
Besides, I dont think anyone can give you a list of design patterns that would be best for a CMS tool. Because each design pattern solves some particular problem. And, you just have to choose a design pattern depending on a specific problem you want to solve in your project.
These days, writing your own CMS is a horrible waste of time. The usual open source solutions -- these days Joomla, WordPress and Drupal are popular -- are written by thousands of people and while you might loose a little flexibility by using on that's ready made this is by far offset by not needing to redo everything from scratch. If you go with Drupal, you can also enjoy high quality, massively scalable etc code :)
If Your rquiremnt is portfolio, some general content pages, custom blog only, Wordpress will be simple and Better.
In PHP so many CMS available , most popular one is Joomla.
I'm building a PHP site, but for now the only PHP I'm using is a half-dozen or so includes on certain pages. (I will probably use some database queries eventually.)
Are simple include() statements a concern for speed or scaling, as opposed to static HTML? What kinds of things tend to cause a site to bog down?
Certainly include() is slower than static pages. However, with modern systems you're not likely to see this as a bottleneck for a long time - if ever. The benefits of using includes to keep common parts of your site up to date outweigh the tiny performance hit, in my opinion (having different navigation on one page because you forgot to update it leads to a bad user experience, and thus bad feelings about your site/company/whatever).
Using caching will really not help either - caching code is going to be slower than just an include(). The only time caching will benefit you is if you're doing computationally-intensive calculations (very rare, on web pages), or grabbing data from a database.
Sounds like you are participating in a bit of premature optimization. If the application is not built, while performance concerns are good to be aware of, your primary concern should be getting the app written.
Includes are a fact of life. Don't worry about number, worry about keeping your code well organized (PEAR folder structure is a lovely thing, if you don't know what I'm talking about look at the structure of the Zend Framework class files).
Focus on getting the application written with a reasonable amount of abstraction. Group all of your DB calls into a class (or classes) so that you minimize code duplication (KISS principles and all) and when it comes time to refactor and optimize your queries they are centrally located. Also get started on some unit testing to prevent regression.
Once the application is up and running, don't ask us what is faster or better since it depends on each application what your bottleneck will be. It may turn out that even though you have lots of includes, your loops are eating up your time, or whatever. Use XDebug and profile your code once its up and running. Look for the segments of code that are eating up a disproportionate amount of time then refactor. If you focus too much now on the performance hit between include and include_once you'll end up chasing a ghost when those curl requests running in sync are eating your breakfast.
Though in the mean time, the best suggestions are look through the php.net manual and make sure if there's a built in function doing something you are trying to do, use it! PHP's C-based extensions will always be faster than any PHP code that you could write, and you'll be surprised how much of what you are trying to do is done already.
But again, I cannot stress this enough, premature optimization is BAD!!! Just get your application up off the ground with good levels of abstraction, profile it, then fix what actually is eating up your time rather than fixing what you think might eat up your time.
Strictly speaking, straight HTML will always serve faster than a server-side approach since the server doesn't have to do any interpretation of the code.
To answer the bigger question, there are a number of things that will cause your site to bog down; there's just no specific threshold for when your code is causing the problem vs. PHP. (keep in mind that many of Yahoo's sites are PHP-driven, so don't think that PHP can't scale).
One thing I've noticed is that the PHP-driven sites that are the slowest are the ones that include more than is necessary to display a specific page. OSCommerce (oscommerce.com) is one of the most popular PHP-driven shopping carts. It has a bad habit, however, of including all of their core functionality (just in case it's needed) on every single page. So even if you don't need to display an 'info box', the function is loaded.
On the other hand, there are many PHP frameworks out there (such as CakePHP, Symfony, and CodeIgniter) that take a 'load it as you need it' approach.
I would advise the following:
Don't include more functionality than you need for a specific page
Keep base functions separate (use an MVC approach when possible)
Use require_once instead of include if you think you'll have nested includes (e.g. page A includes file B which includes file C). This will avoid including the same file more than once. It will also stop the process if a file can't be found; thus helping your troubleshooting process ;)
Cache static pages as HTML if possible - to avoid having to reparse when things don't change
Nah includes are fine, nothing to worry about there.
You might want to think about tweaking your caching headers a bit at some point, but unless you're getting significant hits it should be no problem. Assuming this is all static data, you could even consider converting the whole site to static HTML (easiest way: write a script that grabs every page via the webserver and dumps it out in a matching dir structure)
Most web applications are limited by the speed of their database (or whatever their external storage is, but 9/10 times that'll be a database), the application code is rarely cause for concern, and it doesn't sound like you're doing anything you need to worry about yet.
Before you make any long-lasting decisions about how to structure the code for your site, I would recommend that you do some reading on the Model-View-Controller design pattern. While there are others this one appears to be gaining a great deal of ground in web development circles and certainly will be around for a while. You might want to take a look at some of the other design patterns suggested by Martin Fowler in his Patterns of Enterprise Application Architecture before making any final decisions about what sort of design will best fit your needs.
Depending on the size and scope of your project, you may want to go with a ready-made framework for PHP like Zend Framework or PHP On Trax or you may decide to build your own solution.
Specifically regarding the rendering of HTML content I would strongly recommend that you use some form of templating in order to keep your business logic separate from your display logic. I've found that this one simple rule in my development has saved me hours of work when one or the other needed to be changed. I've used http://www.smarty.net/">Smarty and I know that most of the frameworks out there either have a template system of their own or provide a plug-in architecture that allows you to use your own preferred method. As you look at possible solutions, I would recommend that you look for one that is capable of creating cached versions.
Lastly, if you're concerned about speed on the back-end then I would highly recommend that you look at ways to minimize your calls your back-end data store (whether it be a database or just system files). Try to avoid loading and rendering too much content (say a large report stored in a table that contains hundreds of records) all at once. If possible look for ways to make the user interface load smaller bits of data at a time.
And if you're specifically concerned about the actual load time of your html content and its CSS, Javascript or other dependencies I would recommend that you review these suggestions from the guys at Yahoo!.
To add on what JayTee mentioned - loading functionality when you need it. If you're not using any of the frameworks that do this automatically, you might want to look into the __autoload() functionality that was introduced in PHP5 - basically, your own logic can be invoked when you instantiate a particular class if it's not already loaded. This gives you a chance to include() a file that defines that class on-demand.
The biggest thing you can do to speed up your application is to use an Opcode cache, like APC. There's an excellent list and description available on Wikipedia.
As far as simple includes are concerned, be careful not to include too many files on each request as the disk I/O can cause your application not to scale well. A few dozen includes should be fine, but it's generally a good idea to package your most commonly included files into a single script so you only have one include. The cost in memory of having a few classes here and there you don't need loaded will be better than the cost of disk I/O for including hundreds of smaller files.