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

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

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

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

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

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

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

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

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

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

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

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

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

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

Любой 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-фреймворк начнет перерастать свой оригинальный дизайн. Или, по крайней мере, ускорить время разработки, чтобы не задерживаться на несколько дней, потому что вы вдруг поймете, что вам нужна модель для работы с электронной почтой.