Как можно спорить на тему «ASP.NET WebForms против ASP.NET MVC»? Ведь эти технологии ПЕРЕСЕКАЮТСЯ?
Как можно спорить на тему "ASP.NET WebForms против ASP.NET MVC"? Ведь эти технологии ПЕРЕСЕКАЮТСЯ?
Будучи таким же нубом в ASP.NET, как и эти споруны, я думал, что в ASP.NET WebForms доступен только движок представлений ASPX (с кучей готовых контролов, компонентов и WYSIWYG), а в ASP.NET MVC - только новый движок представлений Razor, в котором всех этих плюшек нету.
Потом с некоторым удивлением обнаружил, что в MVC 3 и выше - на самом деле предоставляется 2 движка на выбор, а в MVC 2 и вовсе один только ASPX, т.к. Razor еще просто нет.
Сегодня я создал приложение ASP.NET MVC 2, открыл Index.aspx - и опять удивился, обнаружив там наличие вкладки "Design".
Окончательно меня добило то, что я увидел, когда ПЕРЕШЕЛ на эту вкладку! Вместо набора лишь дефолтных тэгов HTML (как я себе это представлял), я увидел там же самый набор "готовых контролов и компонентов", что и в WebForms, и вполне полноценный WYSIWYG для всего этого...
Кинул туда кнопку Button, запустил, всё работает... Попробовал добавить событие Click - тоже норм добавилось, пусть и не очень удобно, что добавилось прямо в файл aspx с помощью script runat="server", но ДОБАВИЛОСЬ же, и IntelliSense для C# там есть.
Усомнился, решил перепроверить, создал приложение ASP.NET WebForms - увы, всё то же самое: и контролы, и код, и практически никаких отличий.
Вывод: сравнивать "ASP.NET WebForms vs ASP.NET MVC" - абсурд.
Правильно - сравнивать "ASPX vs Razor". А уж MVC или не MVC - это уже архитектура. Не удивлюсь, если обнаружится, что через определенные костыли можно приспособить Razor без MVC, как штатно делается с ASPX.
Вы курнули чтоли? что за бред. Вы путаете технологии генерации страницы, цикл обработки запроса клиента , архитектуру в конце концов с одной стороны - и просто два разных шаблонизатора. Razor и ASPX - просто шаблонизаторы, вы можете и свой написать в теории. А вот WebForms и MVC в корне различные технологии. У них различно все начиная от концепции. Их можно использовать одновременно в одном приложении и на одном сайте, но это плохая практика и оправдана она только при миграции с WebForms на MVC
> Вы путаете
Одна из моих профессий - Architect, и если что и путаю, то это ненадолго, уверяю вас. Пусть я пока и новичок и в WebForms и в ASP.NET MVC, я рано или поздно разберусь во всём и буду знать всё поглубже тех, кто тут меня обвиняет в наркомании и психическом нездоровье. У меня это всегда так было. Как говорится, "где теперь я и где теперь они?".
Путают - те, кто спорит на вышеупомянутую тему. Они считают, что ASP.NET WebForms = ASPX, а ASP.NET MVC = Razor (и непременно он), откуда у них следует, что WebForms - это RAD-средство, а MVC - нет. Кстати, на тостере тоже был такой пост, может, и не один. Под словом "пересекаются" я имел в виду, что средства, применяемые под одним фреймворком, вполне могут применяться и под другим. Фреймворки не исключают друг друга, как думают многие.
Также и сам MS создает некую путаницу.
Что за дурацкие названия "ASP.NET MVC", "ASP.NET WebForms"? Обычно такие сочетания слов употребляют нубы, в вопросах типа "Пишу программу на Winforms C#, как мне сделать то-то и то-то?"
Или вот: как назвать всю эту библиотеку контролов, с которыми работает движок ASPX (которые лежат в System.Web.UI, если не ошибаюсь)? Вот люди просто не знают, и называют ее "WebForms", возможно, по аналогии с "WinForms")) Что неправильно.
> У них различно все
Не так уж и все. Это я уже говорю как Reverse-Engineer, искать сходства - одна из моих профессий.
Как от меня не скроешь, что Bolgenos - не "принципиально новая ОС", или что Edge - это тот же Trident, а не "принципиально новый" движок, вот также и не скроешь, что ASP.NET WebForms и ASP.NET MVC - имеют немало общего.
VZVZ: В концепции технологии WebForms есть фундаментальный строительный элемент - веб-форма. Страница, которая строится из различных компонентов(контролов) и имеющая длинный и скучный жизненный цикл. Вся логика приложения по факту строится на событийной модели этой страницы и имеющихся там контролов - вся технология делает вид что веб-приложение это такое же настольное приложение как и обычное приложение WinForms. У MVC этого ничего нет. Есть набор контроллеров обрабатывающих запросы. Можно писать приложение даже БЕЗ Razor, ASPX и других View-шаблонизаторов - получится что-то вроде API. И это просто первое что пришло в голову, различий масса . То что WebForms и MVC на определенной глубине начинают использовать одни и те же классы - по моему вполне очевидно, в конце концов они оба используют сессию, http-запрос и прочее. Я вот только не понимаю. Вы пишете что вы инженер, архитектор, занимаетесь исследованием кишок... но в вопросе свели достаточно большие технологии к САМЫМ ТОНКИМ И НЕЗНАЧИТЕЛЬНЫМ пунктам - клиентским представлениям. А самые большие различия кроются в жизненном цикле запроса к приложению.
VZVZ
> Что за дурацкие названия "ASP.NET MVC", "ASP.NET WebForms"?
Нормальные названия. Названия всегда создают путаницу. Просто потому, что это прежде всего маркетинг. Просто потому что их много, как и самих технологий. Технологий много, потому что мир не стоит не месте, каждый вендор хочет выпендриться и предоставить что-то простое, уникальное, но эффективное. Об этом можно поговорить, но не в рамках этого вопроса. Кстати, как вы бы назвали? Да, "ASP-" в названии - вообще скорее дань истории и, так сказать, игра на знакомых разработчикам словах. Нынешняя технология имеет мало общего с классическим ASP.
> Вот люди просто не знают, и называют ее "WebForms", возможно, по аналогии с "WinForms")) Что неправильно.
Да нет, это как раз таки правильно. А знаете почему? Потому что вся фишка WebForms - попытка затащить в веб ту же модель "форм" и "контролов", которая применяется в классических десктопных приложениях. Фреймворк пытается скрыть от вас тот факт, что часть кода исполняется на сервере, а часть - на клиенте, как будто у вас обыкновенное десктопное приложение. Удачная ли эта идея или нет - другой вопрос, но технология разрабатывалась именно с такой целью.
Дмитрий Ковальский: > Можно писать приложение даже БЕЗ Razor, ASPX и других View-шаблонизаторов - получится что-то вроде API
Я знаю. Как архитектор и инженер, при изучении любого нового фреймворка и т.д., я одним из первых пробую реализовать именно такую - наиболее низкоуровневую - архитектуру, а уже потом берусь подробно за View.
> но в вопросе свели достаточно большие технологии к САМЫМ ТОНКИМ И НЕЗНАЧИТЕЛЬНЫМ пунктам - клиентским представлениям
UI - это самый тонкий и незначительный пункт?!
Да тот C#, о котором мы говорим, в свое время достиг своих первых успехов во многом именно благодаря средствам для UI на десктопе - Winforms и WPF.
Скажем, по удобству заимодействия с БД или MS Office (тоже довольно важные области) он в свое время даже проигрывал продуктам Borland. А вот по UI - выигрывал.
wkololo_4ever: Ну, я думаю, что вам не посчастливится работать со мной, а мне - посчастливится не работать с вами.
Слишком уж специфичными направлениями я занимаюсь: боты, фреймворки, IDE...
Станислав Макаров: > Кстати, как вы бы назвали?
При моих нынешних скиллах именно в ASP.NET, рановато об этом говорить.
Но однозначно могу сказать, что прежде всего я бы ввел в обиход еще 1 название - для той самой библиотеки контролов System.Web.UI, которая входит в платформу ASP.NET (общую для обоих фреймворков).
Вот на десктопе такая библиотека называется WinForms, все знают, что это такое, и знают, что это часть .NET.
А в ASP.NET такая же библиотека почему-то вообще никак не называется. Но зато нечто совершенно другое называется словом "WebForms" (похожим на "WinForms"), откуда и путаница.
> Да, "ASP-" в названии - вообще скорее дань истории
А вот против этого я ничего не имею. С классическим ASP пока не доводилось работать. Надо будет попробовать, хоть ради истории.
VZVZ:
>UI - это самый тонкий и незначительный пункт?!
Да тот C#, о котором мы говорим, в свое время достиг своих первых успехов во многом именно благодаря средствам для UI на десктопе - Winforms и WPF.
Как бы да - UI самый тонкий и незначительный пункт. Потому что для среднестатистического серьезного приложения - доля кода UI на мой взгляд от 1% до 5%. То что Microsoft продвигала свой язык и платформу через технологии WinForms и WPF( кстати, первые версии ASP.NET появились раньше чем WPF) не отменяет этого факта, что поделать - людям надо показать красивую картинку. Основа .NET - CLR и библиотека классов. System.Web.UI как и настольный UI - это малюсенький кусочек этой библиотеки.
Дмитрий Ковальский: > людям надо показать красивую картинку
Дело в основном не в свистоперделках (каких в Winforms как-то не особо было), а в удобстве, как для разраба, так и для юзера - которые у борландовского VCL хромали (особенно для разраба, а ведь оно особенно важно для ЦА, ибо ЦА - разрабы).
> доля кода UI на мой взгляд от 1% до 5%
Мегабайтами кода пусть индусы меряются.
А у нас приложения разные бывают.
Иное приложение только и делает, что создает удобную оболочку для имеющихся консольных или иных неудобных средств. Там 99% работы программиста - это как раз UI.
VZVZ
> еще 1 название - для той самой библиотеки контролов System.Web.UI
В этом неймспейсе прежде всего WebForms и есть, так называемые server controls. Вот например, там есть такой класс - https://msdn.microsoft.com/en-us/library/system.we... - как раз ваша ASPX страничка. А вот такого класса там нет - https://msdn.microsoft.com/en-us/library/system.we... , он в System.Web.Mvc. Не пойму, о какой общей библиотеке контролов идет речь. В MVC приложениях никакие server controls не используются, еще раз подчеркиваю.
Станислав Макаров: > Вот например, там есть такой класс ... как раз ваша ASPX страничка
> А вот такого класса там нет ...
Ну и что с того, что классы лежат в разных неймспейсах и dllках?
Отродясь никто не мешает в одном проекте юзать несколько неймспейсов или dllок (если эти dllки построены под 1 и ту же платформу). Нигде такого никогда не было.
Нееееет, здесь не всё так просто.
И вы не совсем правы.
Но и я не совсем прав: вот сейчас вернулся к своим экспериментам с ASPX в MVC и обнаружил, что Click-то создается, а вот заставить в нем выполняться какой-либо код - чтой-то никак не получается, хотя в WebForms тоже самое работает...
VZVZ
> Ну и что с того, что классы лежат в разных неймспейсах и dllках?
Ди ничего, просто два несовместимых подхода к жизненному циклу веб-приложения, его архитектуре и способам хранения его состояния.
Я вам говорю, как называется фреймворк, или если хотите, подсистема, классы которой составляют содержимое System.Web.UI, для которого вы хотели придумать название.
> Click-то создается, а вот заставить в нем выполняться какой-либо код - чтой-то никак не получается
Вы может все-таки объясните, чего вы хотите добиться и в чем суть попытки скрестить WebForms и MVC? Вам вообще кто сказал, что можно взять и бок о бок их использовать без дополнительных ухищрений? Вы так решили только потому, что студия позволила вам добавить ASPX-файл в проект? А что вы думаете по поводу цикла обработки запроса, по поводу роутинга?
Станислав Макаров: > просто два несовместимых подхода к жизненному циклу веб-приложения
Причем здесь жизненный цикл и архитектура веб-приложения? WebControls - это чисто для View.
А вот обработка СЕРВЕРНЫХ событий от этих контролов (вроде события Click) - это уже и жизненный цикл и архитектура, и в WebForms оно поддерживается, а в MVC события просто не вызываются. В этом я убедился на опыте, так что теперь всё на своих местах.
> Вы так решили только потому, что студия позволила вам добавить ASPX-файл в проект?
Нет. Студия еще и позволила мне обработчик серверное событие Click, в итоге этот обработчик, разумеется, не работает, т.к. приложение MVC, а не WebForms.
Плохо, что студия об этом не предупреждает. Я бы на месте MS так не оставил это.
VZVZ
> WebControls - это чисто для View.
> А вот обработка СЕРВЕРНЫХ событий от этих контролов (вроде события Click) - это уже и жизненный цикл и архитектура
Вы сами себе противоречите. Контролы WebForms (или, если угодно, WebControls) это прежде всего серверный код и связь между HTML-элементами и логикой на сервере, а не только тег input в сгенерированном HTML.
> Плохо, что студия об этом не предупреждает.
Ваши ожидания от инструмента весьма завышены. Я бы понял ваше недоумение, если бы стандартный проект из шаблона не работал или позволял бы каким-то непонятным образом добавить WebForms-контрол на страницу, и он бы, в свою очередь, не работал. Но вы взяли, добавили ASPX, воспользовались его дизайнером, и считаете, что студия должна предупредить о неработоспособности всего этого. Вероятно, есть способы настроить работать WebForms и MVC вместе, если, например, они висят на разных корневых URL, и возможно кому-то это полезно. Но это ж не значит, что все должно работать просто от добавления файла.
Технологии абсолютно разные, даже архитектура приложения разная. Единственное у них общее, это одно, ядро для обработки запросов и связи с IIS. Все. В WebForms грубо говоря, контролы, через канал связанны с обработчиками событий на сервере. В MVC главное это контроллеры с набором действий, которые могут вам отдавать код через шаблонизатор, файл или сериализованные данные. То, что обе технологии завязаны на System.Web можно в одном приложении применять обе технологии. О том, что это вещи разные, говорит то, что в новом ASP.NET 5 (не путать с версиями MVC) MS выпилили WebForms полностью, те создав MVC проект, вы не добавите в него ASPX файл.
Странная логика у вас, не читая ничего, имея скромные навыки в этих технологиях, просто создав проект, добавив пару файлов, вы сделали вывод. Странно, очень даже
> В WebForms грубо говоря, контролы, через канал связанны с обработчиками событий на сервере
Да, серверные обработчики - это именно дело WebForms. Поэтому под ASP.NET MVC они и не работают.
Но сами контролы (и клиентские обработчики - которые на JS) - это дело шаблонизатора ASPX, которых и под ASP.NET MVC доступен был.
> главное это контроллеры с набором действий
С архитектурой MVC уже имел дело, только на PHP с фреймворком Yii2.
А у PHP что ни фреймворк, то в архитектуре MVC, ничего похожего на WebForms я там не видел. Поэтому там таких вопросов не возникало.
> Странная логика у вас
Странная логика - это у MS. Почему студия позволила мне добавить обработчик, который не будет работать, и не предупредила меня Warningом? При этом всё скомпилировалось и запустилось. Я понял, что обработчик работать не будет, только тогда, когда попробовал написать в него "рыбный" код.
Я бы на месте MS не стал делать так.
> в новом ASP.NET 5 (не путать с версиями MVC) MS выпилили WebForms полностью, те создав MVC проект, вы не добавите в него ASPX файл
Хм, спасибо! Но я не думаю, что прям уж так "не добавите". Всегда можно придумать какой-то костыль. Это уже кому как.
> просто создав проект, добавив пару файлов, вы сделали вывод
Вывод очень предварительный был.
А насчет читать, я всё изучаю, прежде всего, на практике. Почему? Потому что я иногда вынужден изучать до кучи такого, о чем ВООБЩЕ почитать негде, и так сделано специально, ибо копирасты. Работа у меня такая. Reverse-Engineering.
Роман:
> с ее точки все норм, вы добавляете в проект шаблон.
Если бы все так рассуждали в свое время, то мы бы на десктопе на голом WinAPI сидели.
Высокоуровневее надо мыслить. Мыслить о том, чего еще нигде нет, но что было бы хорошо, если бы было. Понятно?
> Добавить любой файл можно, только все равно работать не будет.
Было бы хорошо, если бы предупреждала.
VZVZ
> Почему студия позволила мне добавить обработчик, который не будет работать, и не предупредила меня Warningом?
Вы или на работали со студией ранее, или работали не очень плотно. Добавление файла в проект - это добавление его в процесс сборки, не более. Я могу добавить ASPX-файл в WinForms проект, чтобы потом его впилить в EXE-шник в качестве ресурса. И почему студия должна меня о чем-то предупредить? А то, что она открывает дизайнер - почему нет, каждый файл или группа файлов редактируется своим дизайнером, вполне логично. Еще раз говорю - VS это не тот инструмент, который будет следить за каждым вашим шагом, хотя бы потому, что в ней можно решать широкий круг задач.
> Хм, спасибо! Но я не думаю, что прям уж так "не добавите". Всегда можно придумать какой-то костыль. Это уже кому как.
Я в другом треде уже тертий день вам пытаюсь объяснить, что точно такой же костыль вы и сделали, добавив ASPX в MVC-проект. Только в ASP.NET 5 этот костыль уже до работающего состояния не довести, а в предыдущей версии ASP.NET это еще реально сделать.
Станислав Макаров: > работали не очень плотно.
Работал на уровне того, что плагины для VS писал.
> VS это не тот инструмент, который будет следить за каждым вашим шагом, хотя бы потому, что в ней можно решать широкий круг задач.
Пошла-поехала линуксятина.
Тогда проще выкинуть нафиг студию и взять блокнот, а лучше HEX-редактор, как инструмент для самого широкого круга задач.
Это линуксячий подход и есть.
Спорить не буду. В разработке IDE вы все равно не участвуете, и слава Богу.
VZVZ
> Работал на уровне того, что плагины для VS писал.
И до сих пор не знаете, что добавление файла в проект - по сути добавление ItemGroup в MSBuild-скрипт, коими и являются студийные проекты.
> Тогда проще выкинуть нафиг студию и взять блокнот
Для меня студия это набор софта, который работает вместе гораздо лучше, чем некий редактор с некоей сборочной системой и неким компилятором. знаете ли, открыть студию, создать проект и одним нажатием F5 его запустить и тут же поставить брякпоинт на дебаг - это куда больше чем редактор, так что не стоит вдаваться в крайности. Линуксячий подход это когда вы берете vim, и сами пилите всю сборку проекта, флажки компилятору ставите ручками, makefile пишите. И самое главное, студия НЕ МЕШАЕТ использовать такой подход, когда проект уже требует этого. Я в крупных проектах последние пару лет вообще proj-файлы только вручную редактирую, но это не мешает мне собирать и запускать проект по F5 и дебажить студийным отладчиком.
О, черт возьми, да в окне добавления файла в проект шаблоны файлов даже по группам рассортированы, чтобы помочь вам ориетироваться. Куда ж еще лучше-то? Вам совсем Lego нужен?)
Станислав Макаров: > И до сих пор не знаете, что добавление файла в проект - по сути добавление ItemGroup
Знаю. И нутро проектов и решений я 100 раз открывал в блокноте.
Что вы прицепились к этому добавлению файла? Я говорю про добавление ОБРАБОТЧИКА, который не будет работать, а не файла.
При построении проекта ASP.NET MVC, с файлом ASPX, в котором есть обработчики, можно было бы кидать Warning, о том, что обработчики не будут работать.
> И самое главное, студия НЕ МЕШАЕТ использовать такой подход
Вышеупомянутый Warning тоже бы не мешал игнорировать его. Я же не говорю кидать Error. Я говорю кидать Warning.
> Куда ж еще лучше-то? Вам совсем Lego нужен?)
В идеале нужен ИИ, который за меня программирует. И к этому надо стремиться, иначе и развития в отрасли не будет.
Хоть в ASP.NET MVC проектах и можно создавать файлы .aspx и .ascx, тем не менее, для asp.net mvc они - инородные тела, артефакты из WebForms.
>>>А уж MVC или не MVC - это уже архитектура
Чисто теоретически, можно реализовать паттерн MVC на WebForms, но это уже извращение
В ASP.NET MVC вообще нет таких понятий, как "контрол" и "событие". Точнее может есть, но не в том контексте, что Web Forms или Win Forms
Ваши рассуждения почему-то напомнили мне анекдот:
- Когда были с женой в Париже, ходили во французский ресторан
- Ну и как?
- Макдональдс как Макдональдс
Так и вы, внедряете в MVC технологии WebForms, а потом говорите, что разницы никакой
Почему же ASPX - это "технология WebForms"?
ASPX - такой же движок, как и Razor.
Он не мешает использовать архитектуру под названием MVC. Движок - это движок, а коробка передач - это коробка передач))
> В ASP.NET MVC вообще нет таких понятий, как "контрол" и "событие"
Не отрицаю. Контролы - это не MVC, это чисто V. Контролы, события - это дело "движка", а не "коробки передач". Движок развязан (отделен) от коробки передач.
В общем, странное название "ASP.NET MVC" правильнее всего было бы интерпретировать как "ASP.NET and MVC".
То есть поддерживается всё то, что было в WebForms, но в архитектуре "MVC". Ну и в ASP.NET and MVC 3+ еще есть новый движок Razor, как альтернатива ASPX.
Хорошо, что хотя бы в Википедии написано без ошибок:
"ASP.NET MVC и ASP.NET Web Forms являются двумя родственными технологиями, в основании которых лежит одна платформа ASP.NET"
Но и там не поясняется, что ASPX - это фича, реализованная на уровне всего ASP.NET, а не ASP.NET Web Forms.
>>>ASP.NET MVC и ASP.NET Web Forms являются двумя родственными технологиями
Не, ну если так лихо обобщать, то все технологии .NET в каком-то смысле родственные, базируются на NET Framework, одни и те же сборки можно подключить через Nuget и к веб-проектам, и к WinForms приложениям, и к консольным, и к Silverlight и т д.
>>>ASPX - такой же движок, как и Razor.
Да, действительно, aspx можно использовать как шаблонизатор в кач-ве альтернативы Razor, но вы то когда поднимали топик акцентировли внимание именно на применение специфических фишек WebForms в MVC
(>>>Кинул туда кнопку Button, запустил, всё работает... Попробовал добавить событие Click -)
mletov: > Не, ну если так лихо обобщать, то все технологии .NET в каком-то смысле родственные,
С этим я потом разберусь. Пока вижу сходство в поддержке одного и того же движка представлений - и средств разработки для него (WYSIWYG в VS работает нормально в обеих случаях). Это уже кое-что.
> >Кинул туда кнопку Button, запустил, всё работает... Попробовал добавить событие Click
Наличие такой возможности - это НЕ фишки WebForms, это именно фишки ASPX, а если быть точнее, то это фишки IDE Visual Studio, в нее входит вышеупомянутый WYSIWYG.
>>>Наличие такой возможности - это НЕ фишки WebForms, это именно фишки ASPX, а если быть точнее, >>>то это фишки IDE Visual Studio, в нее входит вышеупомянутый WYSIWYG.
Студия тут вообще не причем. Визуальный редактор в VS, позволяющий накидывать кнопки и поля на форму - всего лишь удобный инструментарий и не более того. С тем же успехом можно открыть aspx блокнотом и написать
mletov: я и без вас все это знаю. Я сам писал WYSIWYGи.
Тут не в том дело. А в том, что обработчик-то я создал, но что-то в нем не работает тот код, который под WebForms в таком же обработчике работал бы... Видимо, тут действительно не все так просто...
VZVZ: Естественно не будет работать, так как технологии то разные, приложение WebForms страница, создает, грубо говоря, канал между клиентом и сервером, в случае MVC такой канал не создается. ASPX используется лишь как шаблонизатор
>>> VS лишь удобный инструментарий... С тем же успехом можно открыть aspx блокнотом и написать...
>>>я и без вас все это знаю. Я сам писал WYSIWYGи.
Если знаете, зачем тогда писать, что это фишки Visual Studio?
>>>нем не работает тот код, который под WebForms в таком же обработчике работал бы
Из чего следует, что серверные контролы и их обработчики - это не "фишки Visual Studio" и не "фишки aspx", а в первую очередь основная и неотъемлемая часть идеалогии WebForms
VZVZ: Вы опять не допоняли, серверные контролы, не работают отдельно от WebForms, а вот сам WebForms (вернее её часть, которая за обработку ASPX отвечает) можно использовать как шаблонизатор. Начиная с ASP.NET MVC 5, ASPX выпилили из фреймфорка, а со следующей версии ASP.NET (которая сейчас бета), оставили там только MVC. те создать WebForms приложение в принципе невозможно будет (хотя опять же, файлы ASPX вы добавить сможете, зачем студии вам запрещать это делать, она считает вас умнее все таки )
Роман: > зачем студии вам запрещать это делать, она считает вас умнее все таки )
А это очень большая ошибка так думать, и идеологии MS это совершенно не соответствует.
Любая IDE (любая!) - это прежде всего "абстрактор". То есть хреновина, которая абстрагирует вас от лишних тонкостей, и многое делает за вас автоматом, по крайней мере, по дефолту.
VZVZ: Еще раз, я могу создать приложение, например WPF, со встроенным веб сервером, и затолкать туда ASPX файлы в качестве ресурсов, а потом вызывать шаблонизатор, если не заметили, то у каждого файла есть свойства, в том числе, как его будет обрабатывать система сборки.
У вас крайне странная логика. Вам "позволили" удобства ради добавить в проект страницу на старом шаблонизаторе, и вы считаете, что это значит что WebForms это есть MVC? Я из описанных вами опытов увидел именно это.
Да, MVC это архитектура, но ASP.NET MVC это прежде всего название технологии в целом, т.е. всей инфраструктуры и классов, обеспечивающих написание таких приложений. И шаблонизатор - это даже не главное, что стоит за понятием ASP.NET MVC
> на старом шаблонизаторе
Ну, во-первых, почему все кругом относятся к ASPX как к чему-то "старому"? Это RAD-средство. А Razor - это не RAD-средство. Разные инструменты для разных целей, они не могут заменять друг друга. Это такая же нелепость, как и утверждать, будто WPF заменяет Winforms (тоже часто так говорят).
> вы считаете, что это значит что WebForms это есть MVC
Вот именно, что я уже НЕ считаю, хоть до конца пока и сам не разобрался.
А вот ДРУГИЕ - везде пишут, будто WebForms - это только ASPX, а MVC - это только Razor. И на тостере такое было.
Вот решил внести ясность.
VZVZ: Ну WPF и заменяет WinForms, и именно для этой цели создавалась
Ну не разобрались, а кричите во всю. WebForms это и есть ASPX, а Razor это MVC, то что их можно скрещивать в одном приложении заслуга ядра, которое обрабатывает запросы к приложению на серевере.
Роман: > Ну WPF и заменяет WinForms, и именно для этой цели создавалась
Нет, не заменяет. Это уже ВАШЕ незнание ДЕСКТОПА.
WPF основан на DirectX. Слово "DirectX" вам ни о чем не говорит? Игры, 3D, анимация...
Спрашивается, нахрена нужен этот DirectX в программке, где окошко, пара кнопок, десяток текстбоксов, пара табов, и все это дефолтным GUI и никаких красивостей и уж тем более анимаций?
Не нужен он в таком приложении. И более того, будет только мешать. Так как изначально DirectX тормознее, чем GDI/GDI+. Тупо засекаем время запуска приложения и сравниваем, сколько занимает ОЗУ. Можно и по нагрузке на ЦП графики построить и сравнить. При наличии кучи анимаций или 3D, эти тормоза с лихвой компенсируются, и DirectX/WPF получается куда быстрее, и при том и удобнее для разраба.
Но если ничего этого нет, то всё наоборот, и WPFовский WYSIWYG тоже будет только мешать, ибо чисто физически требует более точных движений мышкой, да и на слабых компах притормаживает жестче, чем Winformsовский WYSIWYG.
> WebForms это и есть ASPX, а Razor это MVC, то что их можно скрещивать в одном приложении заслуга ядра
Главное знать, что под MVC мы можем создать макет с помощью ASPXовских контролов, и добавить JSовские (клиентские) обработчики, но не сможем добавить серверные обработчики - обработку все равно придется делать в соответствии с архитектурой MVC.
VZVZ: а причем тут точность движения мышкой? И да заменяет. А то, что там DX, это не значит, что на 3D заточено, а то, что аппаратное ускорение используется.
Роман: > а причем тут точность движения мышкой?
Притом, что с WPFовским WYSIWYG тупо менее удобно работать.
Простейший пример на уровне хелловорлда: вот в Winforms ткнешь по рамке формы - выделишь Form, ткнешь по клиентской области - выделишь Form. Это одно целое.
А в WPF: есть Window (это окно), а есть Grid (это контейнер), и нужно переключаться то к одному, то к другому, и не перепутать.
Только не надо говорить, что я здесь тоже нихрена не знаю. С десктопом у меня огромный опыт, уж всяко больше вашего, поэтому не нужно спорить.
Но ни опыт, ни знания не делают не очень удобное - удобным.
> а то, что аппаратное ускорение используется.
Сколько раз я слышал эту зазубренную фразочку от людей, кто нахватался вершков, а как применять это аппаратное ускорение - не знает.
Ну так знайте: аппаратное ускорение ускоряет ТОЛЬКО 3D и анимации (когда картинка быстро меняется).
VZVZ
> Слово "DirectX" вам ни о чем не говорит? Игры, 3D, анимация...
Если вам интересно мое мнение, то Direct3D говорит мне о возможности использования ресурсов видеокарты, а не об играх и 3D.
> Нет, не заменяет. Это уже ВАШЕ незнание ДЕСКТОПА.
С таким же успехом можно сказать, что Windows 7 не заменяет Windows 95. Например, потому, что не запустится на всех машинах, где будет работать Windows 95. DirectX 11 не заменяет DirectX 9. Ну и так далее. Под "заменяет" обычно понимают современную альтернативу, на которую есть смысл перейти, если вы способны удовлетворить ее требования к окружению и ресурсам.
VZVZ: Вообще пофиг, я XAML ручками пишу, и мне удобно. Во вторых WPF в разы мощнее в плане дизайна и создания новых элементов, все можно без кода, на XAML замутить. ну на WPF не пишу, Silvelight и UWP, с точки зрения визуальной разработки да и внутренне WPF от них не очень отличается, UWP основная разница - время жизни приложения, в SL отсутствуют некоторые низкоуровневые вещи.
Станислав Макаров: > С таким же успехом можно сказать, что Windows 7 не заменяет Windows 95.
На Windows 7 запустится куча программ, какие не запустятся на Windows 95.
В Win 7 (точнее, Win XP и выше) входят реально нужные вещи, и DirectX в их числе, но не для свистоперделок, а для игр, для DirectShow - и для тех редких случаев, когда GUI все-таки имеет смысл делать на DirectX (например, графические, видео-, WYSIWYG-редакторы).
А WPF что реально нового дает, кроме свистоперделок ненужных?
> https://en.wikipedia.org/wiki/Desktop_Window_Manager
Зачем вы мне эту ссылку суете?
Я и без вас знаю, что такое DWM, и знаю, что он использует DirectX.
Ну и что он там ускоряет, кроме анимаций и прочих свистоперделок? Ничего. А вот замедляет - это да.
Что вы все прицепились к этому ускорению отрисовки? Вы вообще в курсе, как работает отрисовка, и как часто перерисовывается окно?
Если не в курсе, то объясняю.
Вот открылось окошко. Один раз нарисовались контролы. И ВСЁ. Больше оно не перерисовывается, пока юзер: не изменит размер окна, не перетащит его за край монитора и обратно, не свернет в значок и вернет обратно, и не проскроллит.
А теперь представьте себе Калькулятор. Окно обычного Калькулятора. Растягивать - его нельзя вообще. Скроллить - его нельзя вообще. Значит, перерисовка осуществляется только при сворачивании/разворачивании и перетаскивании за край монитора (или окно поверх всех окон). Это что, так часто происходит? Так критично, чтобы было без малейших артефактов? Вот когда вы с калькулятором работаете, вы что, смотрите нету ли артефактов где, не мелькнет ли где белый/черный? Или у вас голова все-таки расчетами занята?
А если расчетами, то что вы здесь ускорять DirectXом собрались?
Если у вас огромная панель с полтинником контролов и в ней скроллбар (сам попал однажды в такую ситуацию), то здесь пригодится WPF.
Ну так эту панель и надо делать на нем, а все остальное - на Winforms, и внедрить ее через ElementHost.
Хотя если вы не только программист, но и Architect, то у вас есть куча самописных контролов и прочих готовых классов для частых задач, почему бы не попробовать и панель с скроллом написать самому? Скорость отрисовки определяется не столько тем, что лежит в ее основе (DirectX или GDI/GDI+), сколько прямизной алгоритма отрисовки...
> Если вас в 2016 году устраивает look&feel уровня MS-DOS или Windows 95
Что за бред? В Winforms вполне стандартный look&feel, как в винде. XP-стили давным давно по умолчанию включены в Winforms, какой к черту 95?
А вот как раз в WPF - дефолтный look&feel берется НЕ из Themes винды, а полностью свой, и несколько непривычен пользователю. И еще более непривычен кастомный look&feel (то бишь "свистоперделки").
VZVZ: Кто вам сказал, что не нужно? вы так решили за всех? А суть в том, что GDI это растровая графика, а Direct2D, а соответственно WPF, векторные, вот в векторах оно и надо.
VZVZ
> Если не в курсе, то объясняю.
Вот открылось окошко. Один раз нарисовались контролы. И ВСЁ.
Я в курсе. В курсе, что оно так будет вести себя как раз таки с DWM, который для каждого окна держит отдельный буфер в видеопамяти и позволяет им не перерисоваться по триста раз. А вот без DWM-а, например в Windows XP мы видели вот это: www.imagehosting.cz/images/happytrail.png , я думаю понятно почему.
> Ну и что он там ускоряет, кроме анимаций и прочих свистоперделок?
Композицию окон он ускоряет, и дает приложениям возможность пореже их перерисовывать.
> DirectX в их числе, но не для свистоперделок, а для игр
удивительная фраза. Т.е. если играть - так играть, а если работать - то все по хардкору. Интересно, была бы та же Макось такой как сейчас, если бы в ней все рисовали технологиями уровня GDI? Вы я смотрю в UI анимашечки не цените. К вам заказчики не приходили и не спрашивали, а почему это на смартфоне, или еще хуже, на веб-сайте у меня все выглядит круче, чем в нашем новейшем десктопном приложении.
> Если у вас огромная панель с полтинником контролов и в ней скроллбар
Вот кстати скролл - отличный пример. Например, в DataGrid-е с кастомными колонками. А то вы так говорите, будто сложность большинства десктопных приложений находится на уровне калькулятора.
> а все остальное - на Winforms, и внедрить ее через ElementHost.
мсье знает толк))))
> сколько прямизной алгоритма отрисовки...
Да уж конечно, аппаратный растеризатор ни в коем случае не сможет работать быстрее хорошего алгоритма на процессоре))
> XP-стили давным давно по умолчанию включены в Winforms, какой к черту 95?
Знаете, XP-шные стили конечно красивее олдскула Win95, но я в общем-то и их считаю прошлым веком. Да, стандартный look&feel это важно, не спорю, но что-то Word 2016 не на WinForms написан. И Фотошоп уже довольно давно использует аппаратное ускорение, благодаря чему любые перемещения и манипуляции с изображением в нем сегодня выглядят гораздо приятнее, чем во времена 8-й версии.
Станислав Макаров: > Т.е. если играть - так играть, а если работать - то все по хардкору
Причем здесь хардкор? Просто игровая графика и GUI - это совсем разные области.
В играх всегда и анимации, и 3D почти всегда, и...
> Интересно, была бы та же Макось такой как сейчас, если бы в ней все рисовали технологиями уровня GDI?
Какой такой? Такой же понтовой и потому притягательной для "сосалок" и им подобных? Да, была бы. Кто-то же должен занять эту нишу. Графика здесь каким боком?
> К вам заказчики не приходили и не спрашивали, а почему это на смартфоне, или еще хуже, на веб-сайте у меня все выглядит круче, чем в нашем новейшем десктопном приложении.
Нет.
В мои обязанности входит работать (над архитектурой приложения, по реверс-инжинирингу, и мн. др.), а не свистопердеть и еще получать за это бабки, как в свое время стали делать программисты MS, и все от них этим заразились.
Поэтому даже самые абсурдные жалобы самых шизанутых заказчиков никак не касаются свистоперделок.
Это во-первых.
А во-вторых, шизанутых я просто посылаю куда подальше. Я очень многое умею, в т.ч. уникальное (прежде всего - все тот же реверс-инжиниринг), поэтому я нарасхват, и без работы долго не просижу.
> А то вы так говорите, будто сложность большинства десктопных приложений находится на уровне калькулятора.
Не приложений, а GUI приложений. Это совсем разные вещи, друг с другом напрямую не связанные.
> но я в общем-то и их считаю прошлым веком
А мне все равно, что вы там считаете. Мне в данном случае важно, что они стандартны, в отличие от WPFовской подделки под дефолтную виндовую тему
> но что-то Word 2016 не на WinForms написан
Вот опять нахватались вершков.
Скажем, VBA с UserFormами и прочим - это еще тот антиквариат как раз таки времен Win 95, и по GUI, и не только по нему (что уже реально плохо).
И я уверен, что и в 2016-ой версии ничего особо не поменялось. MS это тупо не надо. Как думаете, почему?
> И Фотошоп уже довольно давно использует аппаратное ускорение
Я и не говорю, что в графических редакторах не нужно аппаратное ускорение.
Роман: > вы так решили за всех?
Да нет, только для себя.
Кто хочет, пусть свистопердит и получает за это бабки, вместо того, чтобы получать деньги за работу.
Но вдруг разгорится кризис, работодатели поумнеют, почешут репы - и за борт всех свистопердельщиков. А я останусь.
> А суть в том, что GDI это растровая графика, а Direct2D, а соответственно WPF, векторные
Что за странный довод?
Мы говорим о GUI, а ЛЮБОЙ GUI - векторный, ибо с координатами. Разговор о растровой и векторной графике - применим к графическим форматам (скажем, bmp - растровый, а Wordовский документ с автофигурами - векторный), а не к GUI.
VZVZ
> Просто игровая графика и GUI - это совсем разные области.
У нас разные представления о GUI. Для меня дополненная реальность - это тоже GUI. Пример утрированный, но лично я принципиальной разницы между игровой графикой и графикой для интерфейса не вижу.
> Кто-то же должен занять эту нишу. Графика здесь каким боком?
не знаю, причем здесь сосалки, они вроде больше с iOS общаются. Графика таким боком, что люди с острым эстетическим чувством обнаруживают, что Макось со всей ее вылизанностью им гораздо более привлекательна как инструмент для работы и развлечений. Уверен, что в UI макоси аппаратное ускорение играет не последнюю роль. И да, мы с вами забыли о высоком разрешении и 4k мониторах, где пикселей для растеризации еще больше. Если вы и это считаете свистоперделками, то продолжать обсуждать бессмысленно, вам хватит и консоли 80 на 25 символов.
> Нет.
> В мои обязанности входит работать (над архитектурой приложения, по реверс-инжинирингу, и мн. др.), а не свистопердеть и еще получать за это бабки
Ну мы же вас не учим реверсить, не учите как делать интерфейсы). Я вас понимаю, вы наверное из старой школы, вы больше по ассемблеру, а не по рюшечкам. Но мир-то не стоит на месте, и его тенденции и хотелки определяете не вы и не я. Дома я тоже весь такой минималист и умничаю про то, что Win 2000 прекрасно работала и всем ее хватало, но на работе есть проект и требования к нему. А то, что человек хочет комфорта во всем, в том числе во взаимодействии с машиной, я считаю естественным и правильным.
> как в свое время стали делать программисты MS
Еще и программисты Apple, потом программисты Google.. Довольно многие люди)
> Скажем, VBA с UserFormами и прочим
Это вы видимо специально умудрились вспомнить действительно самую антикварную вещь в ворде, которую, совместимости ради, еще не закопали. И VBA MS-у действительно не нужен. Но я все-таки не о VBA говорил, а об основной функциональности Ворда, и о его основном интерфейсе, который врядли сделан только на GDI. Конечно, там еще много диалогов осталось из предудыщих версий, но все инструменты первичной важности были переделаны еще со времен 2007-го и появления Ribbon-а.
> Но вдруг разгорится кризис, работодатели поумнеют, почешут репы - и за борт всех свистопердельщиков.
Во-первых расскажите об этом Эпплу, во-вторых - вы утверждали, что вы - архитектор.
Я вот например, недолюбливаю весь этот смартфонный мир - у меня мобильник 2008-го года выпуска, и он вполне меня устраивает. Меня изрядно раздражают слюни на последние модели айфонов, все эти ненужные наручные гаждеты и прочие игрушки. Но это не значит что я буду посылать на фиг всех желающих сделать мобильную версию какого-либо приложения. Архитекторы понимают требования бизнеса, который их кормит, и так не поступают.
Собственно, я и сам зарабатываю скорее грамотным проектированием БД и веб-сервисов, но я абсолютно точно уверен, что абы как написанное клиентское приложение нашим клиентам нафиг не нужно. Мы потратили уже почти год на улучшение его GUI, как в техническом плане, так и плане юзабилити - убирали каждую лишнюю кнопку. За образец кстати брали 2GIS. И как "архитектор", когда мне говорили, что у нас таблицы туго скроллятся или карта на GDI-движке тупит и туго отрисовывается, я не имел никакого права кого-либо посылать. Моя работа и работа моих коллег - готовый продукт, вылизанный во всех отношениях. Его вылизанность и отсутствие излишеств по сути и есть киллер-фича, позволяющая работать с ним малоопытным пользователям.
Я рад за вас, что у вас работа сугубо техническая, и что вам платят не за свистелки, но не следует выдавать ваши желания и предпочтения за объективную (пусть и не самую приятную) реальность.
Да, кстати, боюсь представить, какое ваше мнение о Win8 и Win10. Для вас наверное вообще не существует этих версий венды)
Станислав Макаров: > лично я принципиальной разницы между игровой графикой и графикой для интерфейса не вижу
Ну, если вы не видите, что в играх анимации необходимы, а в GUI - как минимум необязательны, то тут ничего не поделаешь.
> что Макось со всей ее вылизанностью
Видел и Макось, и Safari видел вживую. Никакой особой "вылизанности" не вижу. Не лучше винды.
> вы наверное из старой школы
Да нет. Ну, скажем, 10 лет назад я вообще программировать не умел.
> вам хватит и консоли 80 на 25 символов
> по ассемблеру, а не по рюшечкам
> человек хочет комфорта во всем
Какая связь между комфортом и свистоперделками? Если она и есть, то она обратная, а не прямая. Кастомные свистоперделки - непривычны, а непривычное всегда создает стресс=дискомфорт (если вы, конечно, работаете, а не играетесь). Психология.
А насчет комфорта, я не зря называю себя архитектором, и знаю, что такое "комфорт", что такое "hi-level" и что такое "качество".
Даже класс MessageBox с его методом Show, я считаю недостаточно удобным, и написал для него свою обертку, в рамках своего фреймворка (я же архитектор - пишу фреймворки). Сейчас я приведу пару примеров кода, посмотрю, что скажете.
Вот MessageBox от MS:
MessageBox.Show(3.14.ToString());
Вот мой аналог:
Utils.MsgBox(3.14);
Снова MS:
var doc = new HtmlDocument(...);
MessageBox.Show(doc.DocumentNode.InnerHtml);
Снова мой:
var doc = new HtmlDocument(...);
Utils.MsgBox(doc);
Снова MS:
MessageBox.Show(textBox1.Text);
Снова мой:
Utils.MsgBox(textBox1);
Снова MS:
MessageBox.Show("");
Снова мой:
Utils.MsgBox();
Есть и еще одна особенность, которую в данном коде не видно, однако она есть.
Мой метод MsgBox лежит в классе Utils, в котором много прочего нужного, а класс Utils лежит в Root Namespace моего фреймворка (как System в .NET), в этом Namespace также полно полезных классов. Таким образом, не приходится подключать System.Windows.Forms только ради какого-то мессейджбокса, достаточно подключить и заюзать Root Namespace (который по-любому пригодится в любом проекте), и MsgBox также станет доступен.
...Ну ладно, допустим неудивительно, что такой удобной фичи нет в стандартном .NET, включая и WPF.
Зато в таких высокоуровневых, дорогостоящих, знаменитых, продвинутых RAD-фреймворках, как DevExpress, Telerik, ComponentOne, он просто обязан быть!
Что ж, идем в документацию... www.telerik.com/help/winforms/forms-and-dialogs-me...
И - просто невероятно! - там есть ЧТО УГОДНО, есть любимые всеми кастомные свистоперделки, есть какие-то Details... А вот элементарной гибкости набора входных параметров - как раз и нет...
> программисты Google
Кстати, о программистах Google.
Вам показать код, написанный на основе ихнего YouTube API под .NET, и тот же самый код, но написанный на основе моего класса?
> умудрились вспомнить действительно самую антикварную вещь
Нет. Это вещь, с которой я работаю уже второй год в рамках одного проекта.
> И VBA MS-у действительно не нужен
Здрасьте приехали. Вот такой бред даже оспаривать противно.
> Мы потратили уже почти год на улучшение его GUI
Да не надо путать качество GUI и свистоперделки.
У меня есть концепты таких юзабельных контролов для GUI, каких нет ни в Winforms, ни в WPF, ни даже в Telerik/DevExpress/...
Но - без единой свистоперделки.
> боюсь представить, какое ваше мнение о Win8 и Win10
Вынужден сидеть на 8.1 по ряду причин. ВЫНУЖДЕН.
Средний
