Розумні структури організації додатків PHP?

10

Існує мільйон і одна структура файлової системи, які входять до безлічі доступних проектів з відкритим кодом. Такі речі, як модулі, мовні файли, домени, сторонні бібліотеки, міграції, інтернаціоналізація, резервні копії та посилання на інші частини системи породили багато підходів до організації файлової системи проекту.

Як розробника PHP мені цікаво, чи не починає з'являтися якийсь тип стандартизації серед проектів. З PSR-0 ми, нарешті, маємо стандарт для іменування та завантаження файлів, але це, наскільки я не знаю, щодо решти компонентів, що входять до системи, або про те, як з ними можна обробляти розумним чином.

Ми маємо справу з набагато більшим, ніж просто MVC, тож які приклади є великих проектів, які правильно впорядковують усі ці речі?

— Ксеонкросс
джерело

3

Як інший розробник PHP, я не очікував би

— розуму

2

@CamelBlues На основі чистого шансу, якийсь розробник PHP повинен врешті-решт зіпсуватись і зробити щось правильно.

— Xeoncross

Я не бачив багато що стосується стандартизації. До останніх кількох років у вас були папки для речей (js, css), а потім у вас були включені або libs, а потім шаблони або теми, і це було все. Останнім часом, коли рамки MVC набирають популярності, все незрозуміло. Я б сказав, що не переживайте за використання стандарту на даний момент, а просто нехай буде зрозуміло, що йде у вашій конкретній програмі.

— Джейсон

3

Неможливо насправді стандартизувати, як мають бути розроблені проекти, оскільки "це залежить".

Якщо ви введете стандартну структуру, але частина її не відповідає вимогам, що розробляються, ви можете отримати додатковий шум, який вам не потрібен. Так само, якщо стандарти повинні працювати для широкого кола проектів, вони повинні включати занадто багато розрізнених сценаріїв.

Наша робота як розробників - шукати шаблони та найкращі практики та застосовувати їх до завдання. Ми використовуємо наш досвід та досвід, щоб вибрати правильну структуру файлової системи для проекту, над яким ми працюємо.

— Фентон
джерело

+1 В цілому я з вами згоден, це, безумовно, справедливий момент. Однак, якщо ви вилучаєте речі поза мовою (папки резервного копіювання, сценарії cron / build, статичні активи тощо) і просто зосереджуєтесь на самій мові - я не вірю, що такого ж аргументу можна зробити. На мови вже встановлено обмеження. З'ясування того, як організувати всі свої класи та блокові коди, щоб вони мали сенс для кожного проекту, є реальною і досяжною метою.

— Xeoncross

0

Мабуть, не відбувається багато заходів з стандартизації, і якщо чесно, я не бачу користі. Існує лише одне правило, якого слід дотримуватись, а саме: ніколи не слід мати під ліжкоматом речі, які там не належать (основна обережність безпеки).

Крім цього, я б просто пішов з тим, що має сенс для проекту.

Якщо ви використовуєте MVC (через рамку або спеціально), то базова структура з / моделями, / представленнями та / контролерами має сенс. Але навіть якщо ви цього не зробите, у вас зазвичай є якийсь рівень доступу до даних із класами, які відображають ваші об'єкти даних; має сенс мати для них каталог; у вас також зазвичай є маса класів бізнес-логіки та корисних функцій, тому інший каталог для них; якщо ви використовуєте систему шаблонів, шаблони переходять в інший каталог; і тоді ви, мабуть, хочете каталогу "бібліотеки", куди ви помістите всі сторонні бібліотеки. (Як тільки ви досягли цього пункту, ви все одно в основному робите MVC).

Якщо проект дійсно великий, його, ймовірно, можна розділити на функціональні підмодулі; якщо підмодулі є досить незалежними, то має сенс використовувати їх замість вашого верхнього рівня, з одним додатковим каталогом для загального коду.

— тдаммери
джерело

0

Ви можете дотримуватися макет проекту для двох найпопулярніших рамок додатків:

Zend Framework - http://www.framework.zend.com/manual/en/project-structure.project.html
Symfony - http://symfony.com/doc/current/book/installation.html

Вони забезпечать розширювану структуру, засновану на передовій практиці та досвіді користувачів

— Стівен Сенкомаго Мусоке
джерело