Я решил полностью переписать старый проект PHP с нуля. Раньше у меня был один файл для каждой страницы, и теперь я хотел бы использовать подход с шаблоном MVC с одной точкой ввода. Сам проект довольно большой, и я пытаюсь создать свою собственную фреймворк, чтобы я мог хорошо интегрировать все.
Я искал stackoverflow для подобных вопросов, и я нашел некоторые, но у них были совершенно разные структуры папок, поэтому я решил опубликовать свои собственные.
/applications /administration /private /controllers /models /views configuration.php /public /ajax /fonts /icons /images /stylesheets index.php /website /private /controllers /models /views configuration.php /public /ajax /fonts /icons /images /stylesheets index.php /backups /library /helpers datetime.php text.php controller.php model.php Является ли это хорошим способом структурирования моего сайта или вы делаете что-то по-другому? Есть ли какие-то подводные камни, с которыми я могу столкнуться с этой структурой? Есть что-то, чего я не хватает?
Вся помощь очень ценится!
Я использую подобную структуру (с самодельной структурой, но с резервным копированием из webroot). Возможно, вы можете добавить папку «form» в личной папке.
Я использую это, чтобы сделать контроллер более читаемым. Формы – это общая стена объектного кода. Хорошая идея – включить их в внешний файл, включенный в контроллер.
Не забудьте исключить общедоступную папку из правил переписывания, и все должно быть в порядке 🙂
Другое решение – поместить index.php в вашу общую папку и определить эту папку как ваш webroot в nginx. Это предотвращает удаленный доступ ко всему другому файлу (например, файл резервной копии), который должен использоваться только каркасом.
/applications /administration /private /controllers /models /views configuration.php /public <---- Vhost WebRoot /ajax /fonts /icons /images /stylesheets index.php /website /private /controllers /models /views configuration.php /public <---- Vhost WebRoot /ajax /fonts /icons /images /stylesheets index.php /backups /library /helpers datetime.php text.php controller.php model.php
Шаблон MVC не имеет ничего общего с макетом вашего приложения.
Будете ли вы помещать все свои файлы в одну папку или использовать макет, как показано в вашем вопросе, совершенно не имеет значения. Он не получает от MVC больше или меньше, потому что MVC – это не папки, а разделение взаимодействия интерфейса пользователя на три разные роли .
Если вы не следуете кодовому соглашению, которое требует определенной схемы именования файлов (например, PEAR), единственное, что важно для вашего приложения, это то, что ваш автозагрузчик может каким-то образом найти файлы во время выполнения. Поэтому, если вы считаете, что макет, показанный выше, хорош для вас, пойдите с ним.
Роберт «Дядя Боб» Мартин предполагает, что макет папки должен выражать то, о чем идет речь. :
Ваши архитектуры должны сообщать читателям о системе, а не о структурах, которые вы использовали в своей системе. Если вы строите систему здравоохранения, то, когда новые программисты смотрят на исходный репозиторий, их первое впечатление должно быть: «О, это система ухода за больными». Эти новые программисты должны уметь изучать все варианты использования системы и до сих пор не знать, как система поставляется. Они могут прийти к вам и сказать: «Мы видим некоторые вещи, которые выглядят как модели, но где находятся взгляды и контроллеры», и вы должны сказать: «О, это детали, которые вам не нужны сейчас, мы «Покажи им их позже».
Быстрое замечание: я бы держался подальше от общедоступных / частных папок, поскольку вы по существу запираете себя на две роли. Реализация ACL будет сложной / запутанной в этой ситуации.
Я предполагаю, что администрация и веб-сайт – это разные модули веб-сайта.
Почему у вас нет папки общих или основных модулей. Например, у вас есть модель базы данных с именем «Пользователь» и методы с именем createUser (), editUser (), listUsers (), changeRightsOfUser () и т. Д. С этой структурой вам нужно написать и отринуть эту модель для всех модулей.
Ваши контроллеры должны быть уникальными, это okey. Но модели могут использоваться или расширяться для каждого модуля.