Очень часто в книгах о хорошем тоне в программировании можно увидеть термин Decoupling в отношении кода. Смысл в том, что ваши классы не должны быть жёстко привязаны к определённой реализации другого класса (внешней зависимости). И я иногда вижу, что народ следует этой рекомендации в своём коде.
Но почему при этом все так жёстко привязываются к определённому фреймворку в представлениях (View)?
Я ненавижу использовать различные хелперы в виде Html.BeginForm в представлениях. От того, что это превращается во время выполнения в <html> выгоды ноль. Проще же сразу написать HTML тэги и отвязаться от абсолютно ненужно помощи фреймворка.
Я понимаю, зачем создатели фреймворков создают подобные хелперы - они выглядят круто и привязывают человека именно к этому фреймворку. Попробуйте потом перейти на другой, если там подобные вещи не реализованы? Придется переписывать все представления view или хакать фреймворк и реализовывать свой парсер для представлений. Да это столько гемора, что вы окажитесь жестко привязанными и не захотите переходить на что-то новое. На лицо явная проблема жесткой привязанности, все говорят, что это зло, но продолжают использовать.
Еще очень много компаний, которые застряли в первоначальной реализации MVC, потому что у них нет времени и денег переписывать все на Razer.
Мое мнение тут - самый лучший способ писать непривязанные к фреймворку представления - это писать их на чистом HTML. Он жив уже очень много лет и будет жить еще долго. Как тогда передавать данные в такие view? С помощью JavaScript и jQuery например, который так же живет уже долго. Запускаем просто запросы на сервер, он возвращает JSON и на клиенте уже создаем данные накладываем на страницу. Если использовать такие вещи как React или Angular, то там для таких вещей уже есть все на блюдечке. В этом случае UI оказывается совершенно независим от backend-в.
Я не люблю Angular, потому что он хорошо подходит для одностраничных приложений, и именно отсюда идет моя нелюбовь. Но если у вас нет такой нелюбви, я рекомендую использовать его. Пишите UI на Angular, а задний план на MS MVC или Symfony или что хотите. Не нужно использовать фишки фреймворка, который у вас выбран в качестве заднего плана на UI. Если это делать, то в случае попытки замены этого фреймворка придется переписывать не только задний план, но и весь UI.
Если UI и задний план используют свои фреймворки и они никак не пересекаются, то в случае попытки смены технологии, придется обновлять что-то одно - UI или задний план, а не то и другое одновременно.
Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым
ненеенене!
задний план на питоне как минимум
А чем не устраивают одностраничные приложения?
Ничего не имею против, когда они реально нужны. Но далеко не всегда это необходимо. Я бы даже сказал я редко вижу ,когда это необходимо.
Я тоже за независимость бекенда от фронта. Для небольших/несложных приложений мне лично отлично подходит связка Node.js + MongoDB (можно любую базу взять в зависимости от конкретных нужд, мои монга на 200% покрывает) + GraphQL на беке и React на фронте и даже можно еще React Native для мобильных приложений, а для статической типизации можно прикрутить TypeScript.
Получается довольно гибко, а главное все можно писать на одном языке и не надо переключаться, а экосистема джаваскриптовая в целом очень интересная и богатая, куча библиотек тулинга и прочего.
Хотите найти еще что-то интересное почитать? Можно попробовать отфильтровать заметки на блоге по категориям.
Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю
Copyright © 2024 Михаил Флёнов. Тираж 1 штука. Отпечатано на ноутбуке. А за права отвечаю, или постараюсь.
А здесь еще и копирайт поставлю: Professional Web Development.
На сайте используются Cookie. Если вы из ЕС или Калифорнии США, то вы должны согласиться с их использованием - Согласен. Если вы из нормальной страны, то вам пох.
