контроллер представления модели — разделение PHP и MVC
Для начала я не совсем уверен, подойдет ли этот вопрос к модели вопросов SO, поэтому, пожалуйста, закройте его, если он не подходит …
В последнее время я много читал о MVC и SoC и о том, как они связаны с программированием на PHP, и мне трудно понять, как эти концепции отличаются от моего нынешнего стиля программирования. Любое приложение, которое я пишу, использует маршруты url_rewrite, причем маршрутизация обрабатывается одним файлом, который выбирает соответствующий файл controller.php на основе запрошенной подсистемы. Затем в этом файле контроллера назначается окончательный файл шаблона smarty, и файл PHP, который содержит бизнес-логику рассматриваемой страницы, включается в стек.
Проблема, с которой я сталкиваюсь, заключается в том, что в то время как я рассматриваю информацию о MVC и SoC, все примеры, которые я вижу, написаны как обширные взаимозависимые классы и некоторые довольно глубокие пространства имен, но когда я кодирую, я использую объекты только там, где мне нужен объект для многократного использования, но различный код (в соответствии с примерами объектов на самом сайте PHP), и, таким образом, в результате некоторого кода, классифицируемого и пространств имен, почти 70% моего приложения остается в глобальном пространстве имен без классификации. Мне кажется, что этот метод кодирования по-прежнему отвечает принципу разделения интересов, хотя я не настолько уверен в том, чтобы быть MVC, поскольку каждый пример MVC, который я могу найти, построен исключительно из очень большого числа классов.
Может ли кто-нибудь объяснить, если я здесь далеко от базы или я достигаю SoC и, возможно, даже MVC с моим текущим кодированием, и объясните мне, если встраивание всего приложения в диапазон классов является требованием для SoC и MVC.
Спасибо
Решение
ОК, я обычно беру на эти открытые вопросы: P
Позвольте мне перефразировать все ваше дело к новому вопросу — и не стесняйтесь сказать мне, что я не прав!
Я думаю, вы спрашиваете: «Соответствует ли мой стиль кодирования лучшей практике для x y z?»
Теперь посмотрите — я был на разных должностях, и я твердо верю, что никто никогда не взламывал полную архитектуру SoC — в какой-то момент всегда есть компромисс между предоставлением возможности кому-то на стороне представления выполнять свою работу, и кто-то вверх по течению принимает входные данные и заставляет их работать так, чтобы они связывались с базой данных и логикой.
Например, я сейчас создаю систему, которая принимает файлы HTML в качестве входных данных, читает их через PHP. PHP преобразует элементы HTML в группу JSON и добавляет логику к этому JSON на основе x, y и z, а затем отправляет их в компоненты Facebook React — которые преобразуют все обратно в HTML / DOM — когда вы объясняете кому-то, что это колбасная машина, которая принимает, как ввод, HTML, и вывод HTML, вы можете понять, почему они могут пойти — черт возьми, что вы делаете !!
Теперь — почему мы это сделали? Потому что это имело смысл для проекта, и это имело смысл для команды. Мы могли бы в равной степени использовать некоторые заранее определенные рамки и бла-бла-бла — однако это сработало для нас.
(здесь следует предостеречь: если вам нужно высокопроизводительное приложение, это может быть неправильным подходом, однако имейте в виду, что то, что вы читаете (взаимозависимые классы и т. д.) также может быть неэффективным — оптимизация кода PHP трудна работа — мой совет здесь, сначала запустите его, затем, если продукт успешен, заплатите кому-нибудь, чтобы он исправил ваш дерьмовый код — серверное время дешево — ваше время нет)
Мое утверждение для вас было бы без конкретных примеров и вариантов использования — люди будут изо всех сил комментировать ваш подход — но понимают, что есть много разных способов сделать что-то, и вы можете увидеть много открытого исходного кода, написанного так или иначе, но если вы пишете что-то, что достигает цели, ваша единственная забота должна заключаться в том, чтобы она была производительной и имела «достаточное» разделение, чтобы ваш дизайнер мог работать над дизайном, ваш кодер мог работать над кодом, а ваш генеральный директор мог смотреть на цифры продаж.
Надеюсь это поможет.
Другие решения
Судя по предоставленной вами информации, вы делаете хорошую работу. Я думаю, что вы разбираетесь в разделении проблем и, возможно, MVC. Я думаю, что вы должны присмотреться, как обстоят дела рассеянный в других кодах, как дела модульный, и подумайте, как бы вы справились с вещами, которые потенциально могут возникнуть в веб-разработке.
Что если я хочу, чтобы какой-нибудь код запускался перед каждым контроллером? Или промежуточное ПО, которое работает между запросом и контроллером? Или внедрить переменную в представление после обработки каждого контроллера? Как вы разделяете логику POST, GET, PUT, DELETE, но все же группируете их внутри ресурса? Некоторые из них могут быть достигнуты с вашей архитектурой, но я думаю, что многие решения были бы более чистыми с тяжелой архитектурой. Конечно, что-то более чистое в глазах смотрящего.
Фреймворки, представленные публике, стараются быть универсальными и охватывают как можно больше вариантов использования. Одна проблема, которую я вижу, заключается в том, что вы предполагаете, что файл контроллера будет вызываться последним, а затем настраиваете представление. Таким образом, хотя логика находится в глобальном состоянии, она существует только в этом файле. По сути, файл действует как пространство имен. Я не думаю, что это допущение, которое должен сделать общий веб-фреймворк, но это то, с чем вы можете сойти, когда пишете что-то для себя.