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

Question

Долгое время скрывался, первый постер ...

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

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

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

Или у меня возникнут проблемы, когда я хочу гибкости кодирования, например

• используя что-то вроде PHPthumb для галереи, где я хочу другой вывод размеры на разных страницах и текущие параметры в голове страницы
• форма контакта с полями x и форма обратной связи с полями y - потребуются ли для этого две разные модели, а не универсальный класс формы снова с некоторыми параметрами, установленными в заголовке страницы
• некоторые страницы, требующие ob_start () и ob_flush (), но не другие?

Пожалуйста, не говорите мне, чтобы я не строил свою собственную платформу - я бы лучше знал, как работает каждый маленький кусочек, чем использовал бы кусок кода, о котором я ничего не знаю - мне действительно интересно мнение людей, которые ушли этот маршрут и строить сайты каждый день. Каковы реальные плюсы и минусы этого по сравнению с простым (но хорошо структурированным) ООП и набором страниц на сайте, в отличие от 1 страницы index.php и отдельных файлов.

Cheers, Придирается

Answer 1

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

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

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

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

Answer 2

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

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

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

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

Answer 3

Я написал свой собственный фреймворк. Для создания архитектуры и исходного кода не требуется времени. Здорово, если кто-то напишет там свой фреймворк. Но если документация не является надлежащей, то определенно боль в задницах. Полностью зависит от вас самих. Я тоже написал свой. Потребовалось почти 7 дней, чтобы сделать готовый каркас QA :). но главная проблема заключается в том, чтобы быть удовлетворенным фрагментом кода, который вы пишете в своей среде. Вы всегда хотели импровизировать свои рамки и хотели, чтобы это было лучше всего. BLAH! BLAH! Если вы хотите написать свое собственное, и вы достаточно уверены, чтобы пропитать. ПОЙДИТЕ за это.

Answer 4

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

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

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

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

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

Answer 5

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