MVC как лучшая практика для программирования на профессиональном уровне?

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

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

Все это говорит о том, что если вы хотите писать самостоятельно в свободное время, в качестве хобби, чтобы не тратить впустую деньги своего босса, тогда во что бы то ни стало. Существует огромное разнообразие интерпретаций MVC. Некоторые фреймворки рассматривают представления в основном как шаблоны. Лично я считаю, что вы можете добавить туда столько сырого PHP, сколько захотите, если его целью является отображение, и вы делаете обычные умные вещи, такие как преобразование общего кода в функции. Некоторые фреймворки практически не имеют бизнес-логики в моделях (где она принадлежит IMO), но имеют очень тяжелые контроллеры. Лучшее, что вы можете сделать, это попробовать другие фреймворки и посмотреть, как они работают и какие вам больше всего нравятся, и решить, что бы вы хотели изменить. Затем, намеревайтесь изменить его в своем собственном.

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

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

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

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

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

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

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

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

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

Если вы хотите получить больше идей о шаблонах проектирования, вы можете использовать шаблон проектирования Google MVP и/или шаблон проектирования MVVM.

Я написал свой собственный фреймворк. Создание архитектуры и сырого кода не требует времени. Здорово, если кто-то напишет там собственный фреймворк. Но если документация неправильная, то определенно боль в задницах. Полностью зависит от вас самих. Я тоже свою написал. Проверка качества фреймворка заняла почти 7 дней :). но главная проблема заключается в том, чтобы получить удовлетворение от фрагмента кода, который вы пишете в своем фреймворке. Вы всегда хотели импровизировать свой фреймворк и хотели, чтобы он был лучшим. БЛА! БЛА! Если вы хотите написать свой собственный, и вы достаточно уверены в себе для пропитания. Действуй.

Любой MVC — самодельный или нет — обеспечит вам гибкость и возможность повторного использования кода.

Вызовы ob_start() / ob_* не проблема, они входят в вашу модель и вызываются из вашего шаблона, например:

Hello <?php echo $this->getFormattedName(); ?>

где твоя модель

function getFormattedName() {
    ob_start();
    echo '<a href="/profile/' . $this->getName() . '">' . $this->getName() . '</a>';
    $return = ob_end_clean();
    return $return;
}

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

Возможно, вы захотите рассмотреть возможность использования чего-то вроде Zend Framework — хотя это сама по себе библиотека MVC, вы можете очень легко использовать отдельные компоненты (например, вы можете использовать Zend_Form и Zend_Mail для своих контактных форм и форм обратной связи, проверки и используйте свои собственные модели для всего остального). Это также даст вам дополнительное преимущество в виде запасного варианта, когда/если придет время, когда ваш доморощенный фреймворк MVC начнет перерастать свой первоначальный дизайн. Или, по крайней мере, ускорьте время разработки, чтобы не задерживаться на несколько дней из-за того, что внезапно осознаете, что вам нужна модель электронной почты.