Собираем базу компаний, которые сокращают штат или зарплаты из-за кризиса. Заполните анкету
×Закрыть

MVC на сервере — вчерашний день?

Наткнулся на форуме на:

современный веб такой, что mvc на сервере уже никому не нужно.

Кто что скажет на эту тему?

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

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Ещё вопрос такой:

1.Будет ли достаточно работы asp.net mvc разработчику в Украине в ближайшие 3-5 лет или применять будут серверный mvc всё реже с течением времени и всё угаснет под натиском библиотек xxx.js ?
2.Стартуют ли у нас сейчас новые проекты на asp.net MVC или у нас в аутсорсе почти всё — поддержка старых?
3.Какого типа эти проекты?

стартуют, фронтовые mvc js расширения сейчас очень удачно уживаются дотнетовскими RESTful WebApi контроллерами. Рзвитие asp происходит с учетом новомодных трендов. Активно используеться в аутсорсе в качестве сервеной части и для мобильных решений и для веб сайтов на ваших mvvm js фреймворках.

Если речь идет об «отдать клиенту чистые данные и пусть он из них сам строит таблицу», то это разумно. Юзер купил железо, которое во много раз перекрывает потребности браузинга, так пусть оно работает вместо _далеко не_ бесплатной процессорной утилизации на сервере, которому пришлось бы заниматься monkey business, генерируя одни и те же страницы (с разными данными) по тысяче раз в секунду.
Но впасть в крайность и перенести вообще всю логику на клиента, общаясь с сервером как с репозиторием — это путь неискушенных разработчиков, которые представляют интернет сияющим облаком без хакеров и размножающихся багов. )))
Вобщем, мое мнение такое, что решать, что принимать и что отдавать должен сервер в любом случае. Рендерить представления — однозначно клиент.
Могу «гарантировать», что потратив месяц плотной работы с любым из современных фреймворков (нокаут, бекбонмарионет, энгулар...), любой разработчик будет с легкостью представлять клиента неотъемлимой частью системы. А код обработки данных на клиенте вылетать как из пулемета. Там нет ничего сложного (есть «ньюансы», но где их нет?). И простого функционального джаваскрипта за глаза хватает для реализации любых идей. Практически любой паттерн может быть реализован. Жизнь есть и вне ООП -)
Это если кто-то боится, что без его любимого С#/Java ничего не получится.
Мало того, осознавая в этом потребность, MVC 4 «из коробки» идет с минимальным набором компонентов. По желанию они доустанавливаются из репозитория.
node.js — это просто тренд. Нет, ну, может, он идеален в связке с nginx, не знаю... Но отдать json данные может любая тулза... Тот же python, например.
И потом, если вашему клиенту нужен только json, то это съэкономит _массу_ времени и денег, если прийдется мигрировать со, скажем, ColdFusion, на ASP.NET (как это было актуальным лет 7 назад), переписывая вообще все!
Хотя... Если хотите привязать кастомера к своим скилам, то — пожалуйста )))

Начнем с «далеко не бесплатной процессорной утилизации на сервере». Это настолько абсурдно противоречит реальности, насколько это вообще возможно. Для начала — генерить html дешево, во вторых генерить JSON не всегда дешевле, и в третьих — чтобы нагрузить генерацией темплейтов (не базой, не расчетами, а именно шаблонами) 100 долларовый дедик, надо столько трафа, что он монетизируется в космические деньги, плюс к этому наработанный инструментарий кэширования на нескольких слоях.

Бэкбонмарионеты, ангуляры и нокауты СЫРЫЕ почти все, ДОРОЖЕ в разработке и генерят трэш гораздо чаще ибо область молода.

Перфоманс клиент сайд рендера это тот же миф

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

При этом я с большим интересом наблюдаю за прогрессом клиент сайд аппов, но браццы прогресс не в том чтобы закрывать глаза на недостатки, а в том что бы их разруливать (для этого не помешает их признать для начала)

Приправим это все мобилизацией интернета и отсутствием предпосылок к существенному росту JS-performance на мобильных процессорах.

чуть не забыл — вспомним еще и pjax, который дает снижение трафика, времени рендера, и имеет все шансы откусить у SPA жирный кусок

Для начала — генерить html дешево, во вторых генерить JSON не всегда дешевле

Только с тем отличием что клиент может загрузить JSON один раз, а потом нажимать 10 окошек, панелей и подобного, который потом закончится еще одним POST JSON напиример. На практике в SPA просто меньше интеракций с сервером.

Перфоманс клиент сайд рендера это тот же миф

Что видим непосредственно у себя на компьютере, то и говорим. Достаточно часто отзывчивость как у десктопного на С++.

Потом появляются темы на доу, как сделать пополняшку из базы счетов на своем андроиде.
А, вообще, скоро будет обязаловом свободное владение English & JS, т.к. халявные чужие ресурсы жиреющих гаджетов никому покоя не дают.

Так и вижу загаловки вакансий: fluent javascript, senior english speaker.

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

Альтернативный вариант комментария:
вброс защитан.

json определенно лучше чем хтмл возвращать на клиент, но все же из-за открытости фронтенд кода и того обстоятельства, что более менее нормально js начал работать только в 9-ой версии IE, сегодня пока не стало вчера, а завтра сегодня.

энтерпрайз к этому совершенно не готов само собой)

Какое там мвц, вы шо? Это уже прошлый век, ретроградство и анархия. Сейчас нормальные пацаны (в очках, с айфончиком, зеркалочкой и аккаунтом в инстаграмме) ставят ноду c редисом и пишут свой тёплый и ламповый коллбек-хелл и угорают по хардкору в start.js, прописывая в крон ребут сервера раз в сутки.

То есть? В node.js утечки памяти, что приходится сервер перезагружать так часто?

Утечка пряморукости тех, кто узнал jquery и возомнил себя гуру js, даже не подозревая, что такое контроль памяти и череда выполнения обратных вызовов, что кстати в той-же ноде ещё более усложняет работу приложения, чем, например, в java.

В node.js утечки памяти, что приходится сервер перезагружать так часто?
ага. из того что лично меня коснулось — у пацанов из ноды отличное от пацанов из linux понимание стека тсп, поэтому хэндлы текут (пинками в либах можно немного полечить, но не всегда)
пинками в либах можно немного полечить

Можно для неграмотных ни в linux, ни в node.js пояснить, что это значит?

Колбек-хелл это вчерашний день. Промисы ж.

Прально, hmvc же есть.

єм. а чем заменить mvc ? если кашей , то лучше пусть mvc

Просто сейчас очень модными стали Single Page Application. Когда весь UI генерится на клиенте джаваскриптом. Т.е. MVC на клиенте, а не на сервере.
Но это не от хорошей жизни, а в попытках «выкрутиться». Ведь разных мобильных устройств сейчас тува хуча, и писать под каждый нативное UI приложение — накладно. А так: вроде как приложение, но на HTML5 — поэтому плюс-минус везде работает.

всё не очень секьюрное можно отдать клиенту
Только потом юзеры начинают жаловаться что у них на телефоне сие приложение тормозит, постепенно сжирает всю память и батарею и т.д. И начинаются шаманские пляски с минификацией, оптимизацией, «урезанием», попытками угадать что у юзера за девайс и что он потянет и «впихнуть невпихуемое».
Весь идиотизм этой ситуации в том, что уйдя от вебформ, которые напрягали мобилы вьюстейтом, следующим шагом ушли от серверного MVC в сторону «все запихать на клиента».
При этом MVC на клиенте делать намного дольше, сложнее и выходит глючнее, чем MVC на сервере с шаблонами под разные устройства.
Поэтому если у вас нет жесткого требования делать SPA с запретом на навигацию то смело делайте MVC на сервере. И если даже нужно SPA то вполне может оказаться что качать с сервера готовый HTML и вставлять в ДОМ будет работать проще и быстрее чем MVC библиотеки на джаваскрипте.

лол. ну сингл spa предполагает всё-таки только логику представления на клиенте.
ну то-есть если у вас MVP — то рестфул апи вместе с сущностью вроде model в backbonejs — это презентер, то что rest api врапит — это модель.
если у вас какой-нибудь mvvm — то на клиенте только view model и model.

с другой стороны вы можете рассматривать restful api как mvc приложение с вырожденной вью в виде json

Спорить что есть SPA: MVC, MVP, MVVM и что в них модели а что вью не вижу смысла.
Вот здесь это все называют MVC:
todomvc.com
На мой взгляд сделать сайт на любом из этих фреймвоков минимум в 2 раза сложнее чем на чистом ASP.Net MVC.

с одинаковым функционалом RIA проще всё-таки сделать проще без серверных view engine.
ну еще можно списать сложность на отсутствие опытных людей на рынке + на костыльность жаваскрипта

с запретом на навигацию

Такое бывает?

Поясню в чем «трюк с SPA»:

On iOS, as part of optimizing your web application, have it use the standalone mode to look more like a native application.
developer.apple.com/...0002051-CH3-SW3
На практике это выглядит так: юзер заходит на первую страницу приложения, делает себе иконку на десктопе (можно подсунуть свою) и следующий раз страница открывается как приложение: без обрамления окна браузера. НО — только пока вся страница не перегружается. Переход по любому линку (не «закладке» с # а именно другому URL) вызывает «переоткрытие» страницы уже в браузере и с потерей сессии. Поэтому и приходится все делать через джаваскрипт.
По мне — так куча ненужной работы ради «прогиба» под айпады. Но «клиент всегда прав», а айпады сейчас у многих клиентов.

А, не знал, спасибо

Переход по любому линку (не «закладке» с # а именно другому URL) вызывает «переоткрытие» страницы уже в браузере
Ну не всегда, если переход выполнить с помощью js, даже на другой домен, то переход осуществляется в рамках приложения.

Тут смотря для какого проекта. Иногда нужно отдавать разный ХТМЛ, под ПК один, под мобайл более упрощенный. Ещё, к примеру, интернет-магазины отдают брендированые страницы для определенных товаров. А ещё — поисковики пока больше любят ходить по отдельным страницам. И наконец — ИЕ 6/7/8 все ещё жив и это не малая часть аудитории, которая будет страдать от обилия скриптов на клиенте .

ИЕ 6 — МЕРТВ!
Забудьте о нем.. как и о юзерах без js!
Это не пользователи, это боты и идиоты)

з.ы. лучшее вообще о ИЕ забыть =) но пока не выйдет...

Забудьте о нем.. как и о юзерах без js!
Это не пользователи, это боты и идиоты
без заигрывания з гуглеботом популярности не будет
Он же умеет JS
я не заметил , может в каких-то редких случаях гуглебот может «прокликать» все кнопки в тех же одноклассниках :)

Доля правды тут мааааааааааленькая есть, конечно, с позиции asp.net: mvc framework в Microsoft начали разрабатывать потому, что вебформы просто загибались под своей тяжестью, что давало лишний трафик, и порой это было критично, особенно тогда, когда трафик — платный. А mvc framework — это просто надстроечка, торчащая в asp.net pipeline, и позволяющая очень красиво делать кристально чистый html.
p.s. Так можно дойти до того, что «современные сервера такие, что можно гвнокодить как угодно, и не следить за утечками памяти — ее там хоть ж... ешь» :)

Я бы перефразировал:
«современный веб такой, что <название любого шаблона проектирования> уже никому не нужно»

Судя по топику «трезвая работа», это состояние не только веба...

«Современный X такой, что Y уже никому не нужно» — от создателей «А вот мы в ваши годы Ооо!»

современный веб такой, что mvc на сервере уже никому не нужно.
Если под МВЦ подразумевают формирование ХТМЛ, то скорее не нужен чем нужен.
Исключение разве что «мобильный интернет», но тут речь скорее пойдет о формировании кусков ХТМЛ, чем о странице целиком.
Суть простая: как можно больше засовываем в статику, потом пытаемся отрисовывать на клиенте, если тормозит думаем что можно перенести на сервер.
Если речь идет о паттерне в целом, то это брехня!
ПК становятся ведь всё мощнее, всё не очень секьюрное можно отдать клиенту, пусть компьютер греет комнату, тем более отопительный сезон ещё не начался.

Нужно учитывать mobile (он очень быстро растет и по некоторым параметрам обогнал уже ПК), а также специфику этого mobile:
sealedabstract.com/...-apps-are-slow

Нужно учитывать mobile
А тут так же зачастую формирование ХТМЛ на клиенте может быть эффективнее, ибо:
— меньше объем передаваемых байтов (ДжСОН + шаблон часто сильно меньше целого ХТМЛ);
— больше возможностей для кшировани;
— меньше проблем с «позним флашем»
— надо помнить что рендеринг небольших куском не занимает много времени, поэтому производительность джаваскрипта — это проблема если только вы все отрисовываете в одной непрерывной нити.

Да, мой комментарий больше к тому, чтобы не злоупотреблять этим «ПК становятся ведь всё мощнее» и «пусть компьютер греет комнату».

Остальное можно померять, быстрее или нет (или даже «достаточно ли быстро и хорошо работает»).

Twitter вот по разному пробовал:
blog.twitter.com/...ance-twittercom

А может быть и не эффективнее, ибо:
— Вся подгонка под экран девайса происходит на клиенте (медиаселекторы, расчет ширины элементов скриптом и т.д.).
— Десяток параллельных конекшинов к серверу за данными может быть хуже чем одна загрузка HTML.
— Рендеринг статического HTML с сервера происходит быстрее, чем рендеринг десятка «кусочков» вставленных в ДОМ скриптом.
— Все нарисованное скриптом надо не забывать «чистить» перед показом нового.
— Джаваскипт однопоточный, в то время как загрузка и рендеринг асинхронные. Поэтому при простой перегрузке страницы даже отлаженное приложение будет давать ошибку 1 раз из 100 (в лучшем случае) — просто из-за другого порядка вызова функций.
— Обновление страницы или переход по ссылке убивает все загруженное и нарисованное. А кнопочку «назад» надо поддерживать самому.

— Вся подгонка под экран девайса происходит на клиенте (медиаселекторы, расчет ширины элементов скриптом и т.д.).
А на сервере вы ее (подгонку) сделать просто не можете :)
— Десяток параллельных конекшинов к серверу за данными может быть хуже чем одна загрузка HTML.
Не десяток, а 2 — данные + шаблон. При том шаблон кешируется, поэтому не 2n, а (n+1), для n __уникальных__ сущностей.
— Рендеринг статического HTML с сервера происходит быстрее, чем рендеринг десятка «кусочков» вставленных в ДОМ скриптом.
Рендеринг 1-го большого куска далеко не всегда лучше чем несколько маленьких, для медленных устройств часто таки хуже. Надо помнить что важным тут является не полное время (от начала загрузки до рендеринга последнего куска), а время до начала работы и отзывчивость интерфейса. Помимо того подход с маенькими кусками лучше масштабируется и проще поддержывать.
— Все нарисованное скриптом надо не забывать «чистить» перед показом нового.
А на сервере криворукость программистов не влияет на результат?
— Джаваскипт однопоточный, в то время как загрузка и рендеринг асинхронные. Поэтому при простой перегрузке страницы даже отлаженное приложение будет давать ошибку 1 раз из 100 (в лучшем случае) — просто из-за другого порядка вызова функций.
И снова же, проблема кривых рук.
— Обновление страницы или переход по ссылке убивает все загруженное и нарисованное. А кнопочку «назад» надо поддерживать самому.
Если я вас правильно понял, то это уже давно не проблема (Банальный backbonejs.org/#Router или его аналоги). К слову, кнопку «Назад» и на сервере поддерживать надо.
А может быть и не эффективнее
Это таки правда: __может__ быть все что угодно. Но в 2013-м году неэффективность формирования УИ на клиенте — это скорее проблема отсутствия навыков у конкретных программистов, чем проблема технической части.

Подписаться на комментарии