Я создаю инфраструктуру веб-приложений PHP (MVC). Я бы предпочел не использовать внешние библиотеки или компоненты (поскольку я хочу, чтобы это было чисто моей работой на данный момент)
Можете ли вы рассказать мне несколько советов / рекомендаций, по которым каждый из моих файлов должен отвечать за выполнение? Например, что должно выполняться сценарием Framework и что должно обрабатываться скриптом приложения, используемым в рамках?
Я продолжаю меняться, когда написан код другого кода (как я думаю себе … «Должно ли это обрабатываться каркасом или каждым приложением?»), Что делает его более запутанным, когда я иду.
Я прочитал кучу (20 … 50 … 100 даже!) Учебников по MVC, фреймворкам и т. Д., Но этого мало, что объясняет идеальный «поток» структуры.
В настоящее время я работаю следующим образом:
Теперь … кажется, я направляюсь в правильном направлении? И какие вещи должен делать основной скрипт Framework, а не индекс приложения? Если главный индекс просто инициирует некоторые вещи и передаёт большую часть работы индексу приложений, который будет настраивать маршрутизаторы и т. Д., Чтобы перенаправлять URL-адреса на контроллеры и т. Д.?? Или должна ли платформа создавать маршрутизаторы и инициировать контроллеры, а приложение просто установит пути контроллера и некоторые правила и т. Д.?
Я понимаю, что делают контроллеры, и модели / представления и т. Д. (Я перейду через эти мосты, когда я приеду к ним позже), но пока я просто хочу, чтобы основные вещи текли правильно из нужных мест, поэтому в дальнейшем они будут работать Что ж.
На данный момент моя голова вот-вот взорвется! ха-ха
Возможно, это даже был очень глупый вопрос, но я просто думаю, что мне нужно какое-то прямолинейное руководство, чтобы помочь мне разобраться, прежде чем я получу все полностью из-под удара! Любой совет будет принят во внимание.
Спасибо =)
Вы должны собрать несколько приложений в популярной структуре MVC или два, прежде чем создавать свои собственные. Таким образом, у вас будет лучшее представление о том, как все должно протекать.
Помните, что вы изобретаете колесо … плохо. Но это действительно весело, а? 😉
Мне очень не нравится, когда люди просто указывают вам на существующие рамки и заявляют, что вы не должны изобретать велосипед.
MVC, как и другие шаблоны, являются лишь рекомендациями, не существует фиксированного способа достижения результата. Это теория, которая может быть реализована несколькими способами для достижения желаемого результата.
Действительно, аналогия колеса ошибочна, и это как сказать автопроизводителю, чтобы не сделать новый автомобиль, потому что автомобиль уже существует.
Некоторые колеса сделаны из дерева, в то время как другие сделаны из металла, ни одна из популярных фреймворков PHP MVC не соответствует той же структуре или функциональности, они тоже очень разные.
У вас может быть тысяча различных фреймворков, все из которых следуют шаблону MVC, более или менее, но не два идентичны.
Одна структура чрезмерно сложна и требует навсегда понимания того, как она работает, другая обеспечивает очень конкретный рабочий поток, который позволяет очень мало места для свободы, а другой слишком упрощен и не имеет даже базовых функций.
Существует очень веская причина для разработки вашей собственной структуры, так как это то, что она есть, т.е. ваши рамки для ваших проектов. Никто не понимает ваш код лучше, чем вы сами (надеюсь), и если вы создадите хорошую инфраструктуру, которая позволит вам легко и эффективно разрабатывать проекты, то непременно заново изобрести колесо!
Джон Сквибб имеет хороший учебник на одном пути для создания простой среды MVC. http://johnsquibb.com/tutorials/mvc-framework-in-1-hour-part-one
О, да и другое, не заманивайте в общую конструкцию новичков, в которой единственная точка входа сделана обязательной, заставляя вас полагаться на mod_rewrite или аналогичные подходы Apache. MVC можно построить с одной точкой входа или несколькими.
Вместо того, чтобы создавать фреймворк, вы можете просто создать красивую библиотеку, которую вы можете использовать во всех своих проектах.
Существует большой учебник по написанию собственной структуры mvc, однако, как сказал Байрон, вы будете изобретать колесо. Я думаю, что стоит начать писать свой собственный, но в качестве отличного учебного опыта, и в отличие от большой инфраструктуры mvc ( symfony или zend ) вы будете знать, что делает каждая часть кода. Этот учебник – это тот, который я использовал, чтобы узнать о mvc, прежде чем переходить на использование Symfony, и он очень помог мне понять, как работает symfony. После обучения Anant Garg я перешел на учебник Jobeet Symfony, который действительно помогает объяснить symfony 1.4.
Надеюсь это поможет
Люк
Одна вещь, которую следует помнить, это то, что MVC – всего лишь шаблон, и поэтому он не должен быть на 100% строгим, а скорее ориентиром для реализации, который может быть изменен в соответствии с вашими конкретными потребностями. Так, как предложили другие, попробуйте то, что у вас есть, и вы увидите, что работает для вас, а что нет.