Организация и создание правильных PHP-проектов среднего размера

Question

Я написал в PHP систему управления обучением для небольшой частной школы.Это началось некоторое время назад, когда для меня было много нового в программировании.Это в основном сценарии и включает в себя на основе и не содержит классов или какой-либо организации в стиле MVC, но он стал большим.То, что я пытаюсь сделать, - это организовать текущий код без переписывания, чтобы он пригодился для быстрых итераций.

Пока что я изменил его так, чтобы у каждой роли была своя папка / индекс / действия и всеони используют один общий файл lib.php для выполнения SQL-запросов и других связанных с этим действий.

Я говорил с несколькими людьми из MVC и рассматривал PHPCake и Tonic как вариант, но они, похоже, кардинально меняют то, что у меня уже есть.Я не уверен, что это просто в моей практике, но я просто не понимаю, как MVC облегчит мне разработку быстрее.Может ли кто-то дать советы или опыт советы / мнения или, может быть, некоторые полезные ссылки.Спасибо.

Answer 1

MVC может быть полезной средой для разработки приложений в логически разделенные компоненты несколько «естественным» способом.Это может повысить вашу способность к быстрой разработке, основываясь главным образом на том факте, что некоторые части платформы будут использоваться повторно, и вы сможете использовать этот факт для быстрой разработки новых представлений и аналогичных элементов.Тем не менее, нет необходимости использовать какую-либо конкретную структуру или схему для быстрой разработки, поскольку это можно сделать с помощью правильно разработанного приложения любого характера.

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

Что касается модификации существующего приложения, я бы сосредоточился на попытках централизовать компоненты, на которые вы способны, и на дальнейшем использовании этих компонентов.Это также упрощает изменение подпрограмм, поскольку вместо того, чтобы потенциально изменять функциональность во многих областях кодовой базы, вы можете изменить ее в одном месте и воздействовать на приложение в целом.

Answer 2

Поместите тестируемый код, который вы пишете.Так как старый код не так, тестируйте его по частям.В тот момент, когда вы все протестировали, у вас все будет в порядке для более быстрых итераций.

Answer 3

Попытка привести модель в соответствие с проблемой - очень глупый подход.Шаблоны - это то, что код равен , а не то, каким должен быть код.В любом объектно-ориентированном проекте, представляющем пользовательский интерфейс, будут экземпляры моделей, представлений и контроллеров, но в коде также будет много других шаблонов - наблюдатели, декораторы, итераторы и многое другое.Это полезные обучающие конструкции (например, «Вот как реализовать фабрику для построения объектов из реляционных данных») и (человеческие) языковые конструкции (например, «Этот класс соединения с базой данных должен быть реализован как одноэлементный»).Они не являются конструктивными конструкциями.

, поэтому каждая роль имеет свою собственную папку / index / actions

Если у вас нет довольно необычного определения «роли»,эта архитектура не имеет смысла.Наиболее распространенными критериями разделения функций высокого уровня являются разделение задач и группировка вокруг общих источников данных.

Вы упомянули фреймворки - попытка адаптировать существующий код для встраивания в фреймворк, как правило, плохая идея - она ​​не подходит.Они могут быть полезны для структурирования вашего приложения и уменьшения количества усилий, если вы используете их с самого начала проекта.Не с середины / конца.