Жив ли еще классический ASP.NET MVC?

Всем доброго времени суток.

Я веб-разработчик, и в данный момент работаю над проектом не совсем новым (6+) и понятно что в ходе разработки уже сменилось не одно поколение девелоперов и не одна технология разработки.

И после довольно современного подхода разработки веба(npm, gulp, SPA, с крассивым и удобным роутинком у ServiceStack) я столкнулся с классическим ASP.NET MVC — aspx страницами, бандл конфигами, роут тайблами и другими не совсем удобными вещами.

Интересует, использует ли кто-то еще классический ASP.NET MVC со статическими страницами, возвращением вьюх и т.п. в относительно новых проектах.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
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

Мені здається що тренд вже давно рухається від asp.net mvc/java spring до SPA.
Там і розділити можна на фронт-енд/бек-енд; i код без цих всіх using(Html.BeginForm()) { ... } ;і не треба шукати девів які в розуміють всі ці хелпери;
І на великому ентерпрайзі дуже навіть використовується. Є досвід написання великої репорт тулзи на Java + Angular для великої компанії.

Да, месяц назад лично стартовал на довольно крупном финансовом проекте в галере компании из первой 10-ки. Чистый ASP.NET MVC 5 + прослойка Web API для последующих возможностей интеграции с мобильными нативными клиентами.
Вокруг почти все дотнетчики тоже пишут на MVC.

Поциент скорее мертв чем жив.

В большом интерпрайзе SPA почти не приживаются по мнигим причинам.
Вот несколько причин :
1 секюрити- в больших конторах — есть отдельные отделы информационной безопасности- они почти всегда заварачивают любые проекты у которых бизнес логика доступна на клиенте.
2 Сложность разработки и поддержки по сравнению с классическим сервер сайд
3 Ну и разработка и поддержка на JavaScript- это для очень сильных духом.

Так что если это какой то интерпрайз со сложной логикой- то там будет сервер сайд. В большинстве случае это либо asp.net mvc, либо Java Spring.

Брал участие в разработке финансовых приложениях, которые реализовывали функционал работы с ценными бумагами и мы использовали SPA, и секьюрити тоже было на высоте, и тоже отдельные люди этим занимались. Девелоперы, кастомеры были довольны.На JS никто не жаловался и нормаьлно его было поддерживать — это больше зависит от того как построен рабочий процесс.
А БЛ на клиентской стороне может быть и у MVC приложения, а у SPA ее(БЛ) может и не быть, думаю это больше зависит от разработчиков и архитекторов приложения.
Не совсем согласен с вашим мнением.

никто не жаловался
Да кто же будет жаловаться- когда логика обработки финансовой транзакции у всех на виду. со всеми секрет мерчант аккаунтами паролями и тд.

Я бы таких разработчиков только бы «поблагодарил» =)

финансовых приложениях, которые реализовывали функционал работы с ценными бумагами и мы использовали SPA
Подозреваю что если это True SPA — то вся логика обработки тоже на клиенте.
А на сервер вы только данные гоняете по сокетам?
Есть подозрение что это все же был не SPA- a так — UI на JavaScript- c json ajax requests.

SPA запрещает иметь бизнес-логику на сервере? SPA не о том, где логика выполняется, а о том, как UI работает.

С чего вы взяли, что если это спа то вся бл на клиенте?!

Немного не согласен с такими утверждениями.

1)По сути все секьюрити на клиенте — REST интерфейс должен быть подобно пользовательскому, все чеки на сервере, а вспомогательная логика клиентская это ок, разные пре-валидации, к примеру.
2)Не знаю в каком энтерпрайзе вы работали, но в тех, что брал участие я — при смешении ответственностей степень хаоса очень сильно растет. Разделив фронт и бек жить проще, фронт-енд код чище и пишется в основном профильными фронт-ендерами, хотя и бекендеры могут.
Возможно сложней начать, но когда инфраструктура написана — все идет как по маслу.
3) А кто сейчас пишет на JS ? Пишут на ES6, TS — в современных IDE нет проблем ни с дебагом ни с интелли-сенсом, все как на беке, а то и лучше.

и в заключение — пакеты готовых UI контролов это очень удобный способ организовтаь UI и интегрировать его с беком — для типичных случаев типа пейджинации, сортировки, фильтрации есть готовые интерфейсы с возможностями делать это на клиенте и на сервере, так же это упрощает написание интеграционных тестов на rest ендпойнты, к примеру.

Там, где необходим серверный рендеринг — почему бы и нет ? SPA конечно же удобней делать с разделением на front и webapi часть, используя либо mvvm-фрейморки или react/redux для достаточно запутанной и нешаблонной front-end логики, либо KendoUI + еще что-то, если это более-менее тривиальный энтерпрайз, это удобней и предсказуемей, чем веб-формы, хотя до эпохи развитого front-end’a веб-формы выполняли свою роль отлично.

а с чего бы ему не жить? В SPA страницах нет никакого преимущества ни для девелопера ни для пользака.

Если бы у SPA не было никаких преимуществ, то было бы оно таким популярным и кроме него фреймворки как ангуляр, реак и т.п..

кто сказал что оно популярное? И кто сказал что популярное означает преимущества?
просто распиареная модная фишка.
Пользаку сайта пофиг как там оно сделано. А разработка с клиентскими фреймворками гораздо более трудоемкая чем рендеринг на сервере. Хотя бы потому что нужна дополнительная API прослойка.
Когда клиентский скрипт научится ходить напрямую к серверам БД без бэкэнда тогда и будете сравнивать преимущества,

Я не буду с вами спорить, но не согласен с вами.

вы и не можете спорить ввиду отсутствия достаточного (хотя бы лет 10-15) опыта разработки. А тупо не соглашаться вполне естественно — юношеский максимализм и самоуверенность — все мы такими были это нормально.

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

осваивать новое потому что оно новое как минимум глупо мало ли кто чего понапридумывал.
Это во первых. Во вторых — волею судеб я как раз сопровождаю спа сайт (написаный на флексе) после того как заказчик выгнал предыдущую команду любителей нового и модного (плюс переделка за ними nosql хранилища но нормальные реляции чтобы у заказчитка не ложились репорты а репорты на логистике это не цацки). Так что могу сравнивать.
В третьих количество вакансий на клиенские фреймворки обьясняется просто — большей трудоемкостью работы. Там где справится один програмер на пыхе надо три на яваскрипте.
В результате прогресивные манагеры начинают проект а потом набирают людей чтобы его доделать в срок. Потому как заказчик платит за результат - то есть работающий продукт а не за девелоперские понты и осваивание всего что в инете надыбал.
Есть конечно проекты где клиентские решения асинхронка и прочее оправданы — например соцсети. Но какой процент подобных проектов?

Теперь пошёл конструктив и это уже интересно. За такой коммент спасибо. Но все равно это ваше субъективное мнение.

а у вас оно надо полагать исключительно обьективное.

Это во первых. Во вторых — волею судеб я как раз сопровождаю спа сайт (написаный на флексе) после того как заказчик выгнал предыдущую команду любителей нового и модного (плюс переделка за ними nosql хранилища но нормальные реляции чтобы у заказчитка не ложились репорты а репорты на логистике это не цацки).
На городе бузина(SPA), а в киеве дядька(nosql). Но опустим фееричный опус про nosql и репорты.
В третьих количество вакансий на клиенские фреймворки обьясняется просто — большей трудоемкостью работы.
Это не совсем так. Точней это правда, если мы говорим о попытке сделать сложную логику на простом жаваскрипте/jquery, особенно не имея квалифицированных специалистов под рукой.
И это вообще ни разу не правда, если мы говорим о взрослом MVC фреймворке(или как минимум движка для темплетизации вьюх) аля ангуляр-реакт-ембер.
PS
Кэп мне тут подсказывает, что говнопроект можно написать на любом языке-фреймворке-технологии.

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

Ну погуглите, чтоли :)
Вот честно, не хочется писать 3 абзаца банальностей.

гугл выдаст малоубедительные посты типа ваших. То есть результат тот же.

Могу посочувствовать вашему гуглу.

Рендеринг на ASP.NET MVC это классический cross-unit coupling, ад из которого мы пытались вылезти со времен классического ASP. Не даром на каждому углу кричат про isomorphic development и как это здорово. Это и есть основное преимущество SPA.

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

Я могу и умно не согласится, но тратить на это время, как-то мне не хочется.

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

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

Это очень смелое утверждение.
Т.е. даже если мы опустим такие мелочи как:
1. Вынос бизнес логики на клиента.
2. Отказ от статической типизации- в жертву моде. Да — знаю про TypeScript и его плюшки.
3. А так же отказ от проверенных временем инструментов и фреймфорков (привет Java, Spring, Hibernate)- и перепрыгивание на новомодные Angular, потом не забудьте выделить время и деньги что переписать на Angular 2 (который походу просто не имеет обратной совместимости) Ну или выбрать еще из целого зоопарка Ember, React, vue, JQuery и тд.
4. И при всем при этом от серверсайда никуда не денешься. Все также нужен кто то — кто пойдет сходит в базу или отправить запрос на сторонний сервис или подпишет запрос сертификатом или поставит транзакцию в очедь на исполнение или запустит генерацию кубов, репортов или .... да много чего.

Так в чем же смысл размызывать логику по UI???

1. Вынос бизнес логики на клиента.
А вот не неадо выносить бизнес логику на клиента. Презентационную, валидацию — сколько угодно, но не более. Возьми тот же gmail — сколько там бизнес логики на клиенте?
2. Отказ от статической типизации- в жертву моде. Да — знаю про TypeScript и его плюшки.
Я тоже считаю что js это ужас-ужас. С другой стороны, с нормальными фреймворками, с jslint, юнит тестами, запускающимися на Ctrl-S, c ним можно нормально жить. А с тайпскриптом так вообще про этот недостаток можно забыть.
3. А так же отказ от проверенных временем инструментов и фреймфорков
Это происходит постоянно :)
Отказ от кзассического, проверенного временем ASP в пользу ASP.NET. Отказ от проверенного временем ASP.NET в пользу ASP.NET MVC....
В js мире конечно дурдома побольше, но тот же первый ангуляр уже 6 лет в релизе.
4. И при всем при этом от серверсайда никуда не денешься.
А я где нить говорил что надо отказываться от бекенда? Просто педалить Web API проще, быстрей, юзабельней, тестируемей, переносимей(на мобильные платформы) чем полноценно рендерить страницы.

Пардон- сударь, не правильно вас понял.

Презентационную, валидацию — сколько угодно, но не более

Согласен UI слой+ валидация данных =современный SPA.

Балин, а кто вообще утверждал и где вообще написано что бизнес логику надо выносить в спа на клиентскую сторону?! И кто говорит что нужно отказаться от работы с проверенными фреймворками, nhibernate или entity framework точно также успешно используются в спа приложениях.

для засирания интернета существуют соцсети. Незачем это делать на доу.
Потрудитесь в следующий раз написать что нибудь по существу.

Извините — не удержался.
По делу могу сказать — Вы взяли свой конкретный случай неудачно выбранной технологии и спроецировали эту проблему на весь стек front-end технологий (да еще и NoSql в придачу) что не есть корректно.

пока что я не услышал ни одного коректного обьяснения преимущества спа страниц и клиенских фреймворков.
Недостатки очевидны — бОльшая трудоемкость — хотя бы потому что все равно надо писать бэкенд (какой бы он ни был). И бэкенда этого будет до хрена по сути за каждым sql запросом будет своя API или soap функция — простые линейные выборки с фильтрацией по параметрам существуют только на курсах програмирования. Выгребать все хранилище на клиента думаю не придет в голову даже фанатам ангуляров и реактов.
.
Плюс гемор с дебагом этого добра, плюс неочевидный и запутаный код — фиг его знает где в каком месте был повешен ивент или биндинг.

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

Тогда с какого перепугу логика сайта перетаскивается с бекенда на фронтэнд
А не надо перетаскивать логику на фронтенд. Оставьте бизнес логику(обработку данных) бекенду, а презентационную логику — фронтенду.

«презентационная» логика имеет смысл только в браузерных играх где данные по сути живут тоже на клиенте.
Посмотрите на большинство сайтов (начиная с того на который ща смотрите) какая такая тут презентационная логика?
Высосать из пальца конечно можно что угодно. Но в проекте важна именно бизнес логика потому что пользак работает с информацией то есть с бизнес данными (персистентными разумеется).
лет 15 назад были в моде сайты со всякими флешами и прочими свистелками перделками. Ща рулит флет дизайи и гугл- стайл.
Что вообще делать какой то логике на клиенте в подавляющем большинстве сайтов?
На самом деле есть только одна причина для применения spa страниц, и то следствие неудачных архитектур серверной логики (таких как MVC паттерн) то есть по просту говоря костыль.. То что ее никто не назвал говорит только о том что сторонники яваскриптовых фреймворков - религиозные фанатики которые даже не понимают откуда растут ноги у их религии. А посему дискусия не имеет смысла. Удачи.

лол. Я не знаю чем вы 15 лет занимались, если не мучилась со Stateless природой Http и лепили костыли, потому что у пользовательского приложения на клиенте всегда есть состояние и его количество всегда росло прямопропорционально развитию Веба. SPA нормально решение проблемы, гонять сотни кб состояния между клиентом и сервер на каждое нажатие кнопки — вот это костыль.

Откройте gmail хотя бы и посмотрите на презентационную логику, которая там высосана из под пальца.

Я слышал упоминание слова «классический» только про Classic ASP, и он есть до сих пор, частенько на фрилансе встречаю проекты.

Service Stack не бесплатен, насколько я знаю, а используют ли его в аутсорсе? В 1 из 50 проектов наверное. Собеседовался в сотни мест, и нигде о нём не упоминали. Слышал о нём раз, в одной конторе местной юзали, занимались софтом для events, вроде нагрузка высокая была у них.

ИМХО Service Stack(SS) очень крут, в веб апи 2 они походу у него сплагиатили инициализацию роутов с помощью атрибута и все равно они работают не так круто как у SS.
Да, он не бесплатен и мы через некоторое время от него отказались, потому что они подняли цены.

Если речь идёт не об одностраничном приложении то жив конечно. А болшенство приложений как раз не одностраничные.

Більше того. Навіть класичний ASP.NET використовують. Взагалі без MVC . І дуже навіть ефективно. Бабло рубають як має бути.

Бабло рубають як має бути.
бабло рубают и на VB.NET но это ж не значит, что технология перспективна. Концептуально веб формы остались на уровне развития ВЕБ-технологий ранних 2000-ых. Для своих задач — ок, но потребности веба, да и энтерпрайза меняются и веб формы за ними уже не успевают.
веб формы
Отличная техногия. И справляется она в большинством задач, другое дело- что это больше «немодно».

Я так понял первая редакция вопроса- про статические aspx и какие то биндинги- не вызвал интерес у публики- поэтому вы немного перекрасили топик в asp.net mvc. Мне это напоминает черное сео.

Ответ:
Да

ASP.NET MVC
класический с возвращение въющек- все еще очень популярен- и на этом стартует множество проектов.

Чёрное сео...ха-ха)) посмеялся от души)

...вые кабины купить в Киеве недорого гарантия качества

Вы не совсем поняли вопрос. Меня интересуют сегодняшние реалии, а именно используют лю сейчас чистый Asp.net mvc или больше предпочтение, к примеру, в создание Spa с restful api.

Aspx точно давно сдох, Razor вместо него (cshtml)

Да, використовують. Якщо задача — корпоративна прога, адмінка і т.п. де не треба вражати кінцевого покупця дизайном і UI-плюшками то MVC (зараз на razor) — швидше, дешевше, простіше, легше і дешевше в підтримці, треба тільки c# програмер з мінімальним знанням html, css для вирішення всієї задачі.

Насчёт знания c# при работе с asp.net... ))

К сожалению приходится акцентировать на этом внимание

Возможно ли одно без другого ?)

Увы, такое встречается чаще чем хотелось бы — люди знают минимальный минимум и просто не думают о чем нить бОльшем чем if/then/else.

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