Какое разделение каталогов должно иметь мой фреймворк?

Я пробовал использовать кучу различных структур каталогов для моей среды PHP MVC. При этом я придумал несколько причин, чтобы отделить разные части приложения друг от друга.

Например, допустим, это моя текущая структура:

- index.php
- private/
    - application/
        - ... (MVC stuff. Irrelevant I think...)
    - config/
        - config.php
    - framework/
        - bootstrap.php
        - includes/
        - library/
            - ... (Framework classes)
    - libraries/
        - Zend/
        - PEAR/
 - public/
     - css/
     - images/

Я могу обновить фреймворк, просто перезаписав каталог / private / framework /, что не повлияет на конфигурацию фреймворка пользователя в / private / config / или сторонние библиотеки в / private / libraries /.

Файл /index.php используется почти исключительно для загрузки файла /private/framework/bootstrap.php, что означает обновление файла / private / framework / каталог также обновит основной файл начальной загрузки (избавляя меня от необходимости обновлять файл /index.php, который останется как есть, так как в нем совсем немногое).

Кроме того, приложение также отделено от всего, что связано с фреймворком, поэтому пользователь может переключать / изменять / обновлять свои приложения при необходимости, не беспокоясь о других каталогах.

На правильном ли я здесь пути в отношении разделения каталогов друг от друга, чтобы упростить их обновление?

Я видел в некоторых фреймворках, что у них есть каталоги / private / libraries / и / private / application / внутри их каталога фреймворка ... но мне это кажется как будто при необходимости будет сложно обновить фреймворк до более новой версии. Или я неправильно об этом думаю?

Вы можете увидеть мою предыдущую структуру директорий здесь, если вам интересно. Мой новый немного отличается (надеюсь, лучше ...), как и мой вопрос, поэтому я подумал, что это оправдывает публикацию нового вопроса.

Это не такой маленький вопрос, как я бы надеялся, но ну ладно! ;)

Заранее спасибо =)


person manbeardpig    schedule 05.07.2010    source источник


Ответы (1)


Я бы предложил отделить код фреймворка от кода приложения. Платформа должна находиться в одном каталоге верхнего уровня, а приложение - в другом.

Собственно ... Я предлагаю вам взглянуть на структуру каталогов, используемую CakePHP.

person Kalium    schedule 05.07.2010
comment
Собственно, Cake - одна из тех фреймворков, которые я изучал в последнее время. Вы имеете в виду, что моя структура dir выше не показывает такого же разделения, как Cake? За исключением того, что мои основные каталоги находятся внутри каталога 'private /', эти две структуры на самом деле очень похожи на меня. Кроме того, в их структуре есть каталог «Cake / config /», что означает, что если вы когда-либо обновляете каталог «Cake /», «Cake / config /» будет перезаписан .. не так ли? Но я полагаю, что это не сильно повлияет на Cake, поскольку в этом файле, кажется, установлена ​​только одна переменная, и сам фреймворк, а не пользователь. - person manbeardpig; 06.07.2010
comment
Да вот что я имею в виду. Однако в Cake есть два набора файлов конфигурации. Есть app / config и cake / config. Первый - это конфигурация приложения - база данных, кеш, соли и тому подобное. Последний содержит идентификатор версии, конфигурацию структуры каталогов и некоторые вещи для обработки Unicode. Существует огромная разница между конфигурацией приложения и конфигурацией фреймворка. Я думаю, что «framework» и «application» должны быть каталогами верхнего уровня с «public» где-то под «application». Это обеспечивает лучшее разделение кода фреймворка и кода приложения. - person Kalium; 06.07.2010
comment
У меня было ощущение, что это так, поскольку одна переменная, определенная в файле cake / config, предназначена для версии Cake. Хорошо, если бы я сделал то, что вы только что предложили, и 'public /' помещен в 'application /', я бы использовал свой фреймворк для представления всех файлов css / js / img или htaccess для маршрутизации вызовов css / js / img на каталог / application / public /? - person manbeardpig; 06.07.2010
comment
Ресурсы, такие как CSS, JS и изображения, принадлежат приложению. Таким образом, они должны находиться в каталоге приложения. Возможно, какой-то каталог с общедоступными ресурсами, или, может быть, просто общие css, js и изображения под общедоступными. Я бы сказал, что фреймворк должен знать о расположении активов по умолчанию в структуре каталогов, но ваше приложение в конечном итоге несет ответственность за любые отклонения от установленного соглашения. Таким образом вы можете поместить в представление «$ js-› link ('jquery.js') », и оно будет знать, где искать. - person Kalium; 06.07.2010
comment
Поэтому, когда представления моего приложения вызывают $ js- ›link ('jquery.js'), результирующая ссылка будет примерно такой:‹ script src = site.com / application / assets / js / jquery.js ›‹/script› .. . правильно? это не похоже на ссылку, которой я бы хотел поделиться со всем миром. Если они будут находиться в «общедоступном» или основном общедоступном каталоге сервера, URL-адрес будет более чистым ... например, site.com/public/js/jquery.js или site.com/js/jquery.js. Мне это кажется более понятным, но я могу ошибаться ... - person manbeardpig; 06.07.2010
comment
Корневой каталог вашего сервера не обязательно должен быть корневым каталогом всего вашего фреймворка и установленного приложения. Фактически, я предлагаю использовать public under application в качестве docroot. В результате URL-адреса, созданные для публичного использования, будут относиться к корневому каталогу, и утечки информации, о которой вы боитесь, не произойдет. - person Kalium; 06.07.2010
comment
Да, я понимаю это ... но что, если изменение корневого каталога документов находится вне контроля моих пользователей? Например, на некоторых дешевых веб-хостах они разрешают доступ только к каталогу public_html. Я надеялся создать структуру, чтобы она хорошо работала в нескольких настройках, поэтому я подумал, что наличие общедоступного каталога в отдельном месте будет означать, что пользователь может указать его местоположение в Framework, и Framework соответственно создаст правильные ссылки. Это не так хорошо при обновлении приложения, но это означает, что оно должно работать более безопасно на дешевых хостах. Это ситуация «одна или другая»? - person manbeardpig; 06.07.2010
comment
Да, это возможно. Я бы также посоветовал поработать с mod_rewrite. Такой гибкий дизайн возможен. Один из вариантов - свести к минимуму объем работы по загрузке самого фреймворка с фронтального контроллера - в идеале «включить PATH / TO / boot.php». - person Kalium; 06.07.2010
comment
Проблема с mod_rewrite заключается в том, что мне нужно знать возможные «активы», которые может использовать приложение ... то есть для маршрутизации вызовов на site.com/css и т. Д. Но я бы хотел, чтобы мое приложение решало, какие возможные сценарии могут произойти, возможно, в файле конфигурации. С этой второй частью вы имеете в виду, что мой /index.php должен содержать только сценарий include 'framework / bootstrap.php' ;? В настоящее время он определяет расположение каталога фреймворка, затем файла начальной загрузки фреймворка, а затем проверяет наличие этого файла, загружает его, если это возможно, или выдает ошибку, если это не так. Я думаю это довольно просто - person manbeardpig; 06.07.2010