Поскольку наше приложение PHP5 OO увеличилось (как по размеру, так и по трафику), мы решили пересмотреть стратегию __autoload().
Мы всегда называем файл определением класса, который он содержит, поэтому класс Customer будет содержаться в Customer.php. Мы использовали список каталогов, в которых файл потенциально может существовать, до тех пор, пока не будет найден правильный .php файл.
Это довольно неэффективно, потому что вы потенциально проходите через несколько каталогов, которые вам не нужны, и делайте это при каждом запросе (таким образом, создавая множество вызовов stat()).
Решения, которые приходят мне на ум...
-используйте соглашение об именах, которое диктует имя каталога (аналогично PEAR). Недостатки: не слишком масштабируется, что приводит к ужасным именам классов.
-доступайте с каким-то заранее построенным массивом местоположений (propel делает это для своей __autoload). Недостаток: требуется восстановление до развертывания нового кода.
-строить массив "на лету" и кешировать его. Это, по-видимому, лучшее решение, так как оно позволяет вам использовать любые имена классов и структуру каталогов и полностью гибко в том, что новые файлы просто добавляются в список. Вызывает озабоченность: где хранить его и что делать с удаленными/перемещенными файлами. Для хранения мы выбрали APC, поскольку у него нет служебных данных ввода-вывода на диске. Что касается удаления файлов, это не имеет значения, так как вы, вероятно, не захотите их нигде в любом случае. Что касается движений... это нерешенное (мы игнорируем его, поскольку исторически это не случалось очень часто для нас).
Любые другие решения?