Задать вопрос

Как часто нужна модель MVC?

Привет! Я полгода изучаю PHP и сейчас ощущаю себя в нём более-менее комфортно. Владею им и Laravel на сносном уровне (Могу сделать pet-проект, где логика не располагается на 1000 строк в одном файле). Сейчас я делаю себе портфолио и попутно рефакторю свой проект трехмесячной давности, переводя его на MVC (Проект на чистом PHP). И во время этого процесса у меня возникла вот какая мысль:
По-сути, я просто пишу своеобразный микро-фреймворк. Получается, что в моих остальных проектах, которые, скорее всего, тоже будут MVC (Я так понимаю, что почти все сайты, исключая лэндинги и ко, строятся по такой системе). И не какой-то новой MVC, а практически ровно той, что я делаю сейчас. У меня возникли вот какие вопросы к более опытным программистам:
Если я сделаю, условно, 10 таких одинаковых проектов (Не 10 магазинов по продаже базилика, а 10 сайтов, которые используют этот самописный полуфреймворк, который просто будет писаться заново каждый раз с какими-нибудь косметическими (и не очень) изменениями), будет ли от этого толк больше, чем от 10 аналогичных проектов на Ларавел? Ведь суть та же: есть +/- готовое решение, которое я кастомизирую под задачу.
Всегда ли верно использовать модель MVC, если я пока пишу всякие подобия форумов\авито\интернет-магазинов? Или, может быть, есть более современный подход?
И последнее: какова вероятность, что мои знания, полученные таким образом, окажутся чисто академическими, практически бесполезными в полевых условиях?
Спасибо за внимание:)
  • Вопрос задан
  • 920 просмотров
Подписаться 4 Простой 14 комментариев
Решения вопроса 1
Stalker_RED
@Stalker_RED
Да, это полезно - написать свой фреймворк и/или CMS.
Потом полезно сравнить его с laravel или symfony, найти чем ваш фреймворк лучше.
Если ничем не лучше - можете его смело забросить, и переходить на что-то общеизвестное, и вот почему:

Представим, что у вас заказали лендинг по заказу насосов, например, и вы сделали его на своем фреймворке. Через 5 лет вы сменили род деятельности, и водите экскурсии по Тасмании. Или вас укусил радиоактивный паук, и теперь вы спасаете мир, а поддержкой сайтов не занимаетесь.

Сервис с насосами за это время вырос, они теперь еще и бурят скважины, и фильтры устанавливают и колодцы копают, и у них филиалы в 20 городах. Им нужно доработать сайт. И при поиске разработчика выясняется, что сайт ваш доработать невозможно, т.к. документации по фреймворку нет, готовых модулей совместимых нет, интеграций с 1C, google docs, microsoft sharepoint нет, и никогда не будет. И проще переписать с нуля, чем разбираться как оно у вас там устроено.

А если бы сайт был на общеизвестном фреймворке, то гораздо проще найти и специалистов и найти готовые интеграции.

Никто не закажет сайт на самописном фреймворке если он планирует развитие своего бизнеса и понимает что он вообще делает. То есть ваши потенциальные клиенты - это только те, кто впервые заказывает себе сайт, и вы ему смогли впарить самоделку.
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
php666
@php666
PHP-макака
Если я сделаю, условно, 10 таких одинаковых проектов, будет ли от этого толк больше, чем от 10 аналогичных проектов на Ларавел?
Не будет.

Сейчас тенденция такая: работодателю НЕ НУЖНЫ теоретики, нужны практики на том, что востребовано. Точка. Я тебе это говорю как человек, писавший свой фреймворк в свободное время (по желанию от нефигделать) на протяжении нескольких лет. Это абсолютно пустая трата времени, никто это не оценит, а в некоторых случаях даже будут косо смотреть - век программистов прошёл, сейчас век знающих "либы". Лучше потратить это время на освоение того же Laravel.

который просто будет писаться заново каждый раз с какими-нибудь косметическими (и не очень) изменениями
Это у тебя будет одной из самых сложных задач - поддержка актуальности. Твое решение будет глобально переписано минимум 125 раз, тебе необходимо будет делать приложение отдельным композер-пакетом-зависимостью, это усложнит абсолютно весь процесс и ты просто не напишешь эти 10 сайтов. Никогда.

Приведу реальный пример.
У меня был фреймворк в составе проекта.
1. Принял решение вынести фреймворк в отдельную composer-зависимость, написал систему модульности, при которой отдельное приложение - просто набор модулей, а фреймворк устанавливался через композер.
1.1. В итоге получилось два репозитория: существовавший ранее проект (назовем его "А") и фрейморк.
2. Принял решение сделать т.н. skeleton (назовем его "B") для будущих задач, т.е. некую болванку для будущих проектов.
3. Возникла основная проблема - актуализация клиентского кода между проектами "А" и "В" в процессе изменения интерфейсов фреймворка. Любое изменение/дополнение/улучшение в программном коде фреймворка тянуло за собой переписывание клиентского кода в проектах "А" и "В". Не потому, что всё ломалось, а потому, что это предотвращало технический долг и влияло на банальную красоту/чистоту кода.
3.1. Возникла проблема актуализации ресурсов (css, js) и базовых модулей между проектами "А" и "В". Приложение "В" (skeleton) должно было стать эталоном. В skeleton есть некий базовый набор CSS/JS, правил верстки и готовых модулей. Всё это постоянно совершенствовалось. Эти дополнения хотелось вносить в уже действующий проект "А", но делать это приходилось с кровью и потом, т.к. это была тупая ручная работа из разряда copy-paste, т.к. skeleton ("B") по своей сути - это готовый проект, как "А". И тут это всё нельзя было никак автоматизировать.

В итоге от скелетона, который планировался как "болванка" для будущих проектов, пришлось отказаться.

Поэтому твоя идея на базе своего решения клепать 10 сайтов - нежизнеспособна. У тебя банально не хватит времени на разработку фреймворка и актуализацию клиентского кода проектов.
Ответ написан
Комментировать
profesor08
@profesor08 Куратор тега PHP
Делай и практикуйся. Для своих ламповых проектов, пиши код как угодно, так как ты прокачиваешься. Для боевых проектов используй популярные инструменты, тут ты набиваешь руку.
Ответ написан
Комментировать
iCoderXXI
@iCoderXXI
React.JS/FrontEnd engineer
Всегда полезно отделять мух от котлет.

Дело не в том, что MVC так важен. Дело в том, что данные нужно отделять от логики, а логику от представления.

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

Учитывая, что фреймворк, дословно - проволочный каркас, то это нормально изобретать своё. Порой его даже вполне достаточно.

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

А в целом те же яйки, только в профиль.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы