Имеет ли смысл избегать фреймворка при создании большого веб-приложения с PHP?

Будучи разработчиком веб-приложений на PHP уже несколько лет, я получил свою долю MVC и фреймворков. Сначала я думал, что они были лучшими, так как нарезанный хлеб; казалось, что все очень легко реализовать.

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

Например, в одном из моих проектов, где я использую Slim (C) + Idiorm (M) + Twig (V) (который я считаю очень гибким), я должен создать собственную функцию для отображения динамических данных в родительских шаблонах; без фреймворка я мог бы просто выполнить mysql_query () во включенном файле.

Хорошо, фреймворки - это круто, если я создаю простой сайт с профилем компании; Я могу просто взбить какой-нибудь код за одну ночь, и они обычно готовы к утру, и количество хорошей практики кодирования и шаблонов проектирования, которые я извлек из них, очень ценно.

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

Поэтому мой вопрос: можно ли вернуться к основам и использовать стандартный PHP-код и библиотеки для выполнения моего следующего проекта, где могут быть gazillion фреймворки и библиотеки, при условии, что я смогу в достаточной мере использовать хорошие методы кодирования и следовать разумным шаблонам проектирования? как MVC? Моя команда разработчиков довольно маленькая: всего 2 программиста и 1 дизайнер. Другой программист согласен с моими мыслями выше.

Мой опыт в значительной степени противоположен вашему. При выполнении небольших быстрых действий фреймворк может немного «мешать», так как вам нужно определенным образом выложить свой код и тщательно обдумать все перед тем, как продолжить. Просто прыгнув прямо к mysql_queryвам, вы можете получить и запустить свой прототип гораздо быстрее.

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

В частности, добавление mysql_queryвызовов в случайные части цикла страницы, как правило, очень плохая идея. У вас может быть один здесь и один там для начала, и это не так уж и страшно, но вскоре вы получили дюжину распространения по всему месту, и вы удивляетесь, почему ваши страницы занимают 3 секунды только для рендеринга. Или вы изменяете свою схему и, казалось бы, не связанные разделы сайта ломаются по неизвестным причинам.

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

Очевидно, вам все равно придется обратить внимание на аспекты структуры и безопасности, но, учитывая, что вы уже давно используете фреймворки, вы, вероятно, уже знаете эти аспекты наизнанку.

Для более крупных проектов я согласен с другими, имея в виду, что использование фреймворка, вероятно, будет лучшим вариантом в долгосрочной перспективе.

Мой опыт работы с серверными "фреймворками" был довольно неприятным, например:

A) Ад Jar-файлов, где фреймворки конфликтуют друг с другом или с сервером приложений для несовместимых друг с другом версий вещей, о которых вы не хотите и о которых ничего не знаете, и не в состоянии диктовать их, так как это будет препятствовать развертыванию на несколько серверов.

Б) Катастрофический взрыв создания самого простого объекта в тысячи ненужных SQL-исполнений.

C) Странное представление о том, что кодирование 100 строк XML-кода проще или надежнее, чем кодирование двух строк Java.

D) Необходимость написания сотен строк совершенно ненужных серверных POJOS для сопоставления с объектами на стороне клиента на другом или иногда на нескольких других языках (C # JS и т. Д.)

E) Понятия не имею, что на самом деле произошло, когда вы получили 30-уровневую трассировку стека, которая даже не включает строку кода, которую вы использовали для вызова фреймворка.

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

Попробуйте подумать так: "Зачем мне это нужно ... это просто для того, чтобы поддерживать структуру в хорошем состоянии?" .. Если мне это не нужно, то что еще мне не нужно?

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

Предполагая, что вы не знаете основы, когда начинаете проект, ваша производительность изначально будет очень низкой - вы будете изучать соглашение структуры, а не язык языка (который, мы надеемся, вы уже знаете).

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

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

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

Таким образом, для небольших проектов (по моему опыту, что-то до ~ 500 часов) ваша эффективность с фреймворком будет, вероятно, выше, чем ваша эффективность без. Как только вы попадаете в определенный порог (между 500 и 800 часами, IME), вы начинаете понимать, что существуют ограничения на то, что может предложить фреймворк.

С учетом вышесказанного, фреймворки предлагают гораздо большую выгоду, чем просто эффективность - фреймворк, такой как Symfony или Django или (я предполагаю) Rails, предоставляет соглашение, которое позволяет команде динамически сгибаться, а также позволяет клиентам или владельцам продуктов менять свой штат без необходимости новый ресурс, чтобы полностью переучить новую систему - если они знакомы с соглашением структуры, и это соглашение было соблюдено, они будут намного более производительными первоначально, чем иначе.

Хорошо спроектированная структура должна помочь программисту, а не помешать. Если используемая вами среда слишком мешает вам, я бы посоветовала взглянуть на другую. У каждого свой стиль кодирования, свои плюсы и минусы.

Сказав это, фреймворк Zend кажется невероятно популярным в наши дни, и если честно? Я изо всех сил пытаюсь понять, почему иногда. Мне приходилось работать с ним в прошлом, и мне немного не понравилась его архитектура. Класс Zend_Form до смешного перепроектирован, его система декораторов чрезвычайно ужасна в использовании, а декораторы связывают формы с представлениями, нарушая основную концепцию ООП, утверждающую, что объекты должны быть слабо связаны. В нем также много кода, реализованного в виде синглтонов (что плохо по причинам, которые хорошо документированы, поэтому я не буду повторять), а объект Registry также способствует поощрению неаккуратного стиля кодирования.

Я слышал, что Zend Framework 2 (в настоящее время находится в бета-версии) является гораздо лучшим продуктом, но неприятный вкус Zend 1, оставшийся у меня во рту, означает, что я не спешу его опробовать.

Тем не менее, на данный момент я просто ругаю. :) Существует множество рамок, каждая со своими плюсами и минусами, я бы посоветовал оценить некоторые из них.

То, что вы описываете, в прошлом называлось «сложность, вызванная абстракцией». Единственный документ по управлению им: « Управление сложностью, вызванной абстракцией » Дэвида Кеппела. Кеппел предположил бы, что у структур есть дизайн, который вызывает сложность, вызванную абстракцией.

Работа с фреймворком помогает ускорить разработку, не изобретая велосипед . Framework также предоставляет вам инструменты, которые помогут вам правильно спроектировать ваше приложение (но это не мешает вам принимать неправильные проектные решения, например, обращаться к базе данных непосредственно из представления).

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

Суть в том, что использование большого каркаса для простых проектов (например, отображение нескольких полей из базы данных) иногда может быть излишним. Для больших или сложных проектов используйте каркас.

Есть несколько сторон для написания собственного кода по сравнению с использованием Framework:

Размер, базовые знания и опыт команды, с которой вы работаете : если они никогда не использовали фреймворк или у вас есть представление о том, как создать приложение, вам лучше иметь хорошо документированный фреймворк с множеством примеров и увидеть, что вы их ускоряете вверх.

Размер приложения : вы никогда не знаете заранее, как оно будет использоваться. Так что вам лучше быть готовым к росту и изменению. Может ли ваш фреймворк, который вы хотите закодировать за одну ночь, расти вместе с потребностями руководства? Измените типы полей в БД, и на это уйдет минута или день, вот моя точка зрения.

Подготовка : Если вы используете инфраструктуру, вы можете начать разработку приложения вместо того, чтобы кодировать ядро ​​приложения, используйте такую, где безопасность и развертывание являются важными частями, а это то, что отнимает так много времени. Каждый раз.

Я всегда спорю с «менеджментом», чтобы использовать Symfony2, так как он является основой для веб-разработки. Руководство считает, что это слишком дорого, это будет стоить денег и уклоняться от программистов, поскольку кривая обучения крутая.

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

Необходимо выбрать среду, которая соответствует проекту, хотя для корпоративного решения требуется корпоративная структура. Это проблема, с которой вы столкнетесь при использовании PHP. Многие (большинство) фреймворки не предназначены для использования в больших масштабах, они отлично работают для небольших персональных сайтов. Для чего-то вроде школьной системы управления, о которой вы упомянули, потребуется более надежная структура, и может потребоваться некоторое время, чтобы найти подходящую структуру в PHP.