Comments 70
Сегодня же, ASP.NET Core, если верить бенчмаркам, входит в тройку-пятерку лучших по производительности веб-фреймворков на Linux.Ну допустим пока на 10-м месте. Ну неужели php опережает, причём значительно, что удивительно. Однако количество ошибок — 1,272 — настораживает. Java пока тоже опережает по скорости. Но всё равно очень интересно, допилили бы mono до вменяемого состояния: многих удобств .Net или VS ещё нет.
Так и mono и .net core развиваются и берут друг у друга лучшее ;-)
Java изначально кроссплатформенная
А т.е. я могу ее запустить даже на iOS?
Моно — это опенсорс, за которым не стояли гиганты вроде Microsoft, Oracle или Sun. Он развивался силами Xamarin с прицелом на мобильные платформы.
ок, т.е. нельзя. Так и запишем.
Если ява не запускается на платформе, которая приносит больше всего денег разработчикам — это именно проблема явы. Теоретическую кроссплатформенность оставим для производителей чайников.
Чудаки не чудаки, а раз на платформе крутятся основные деньги — надо под нее подстраиваться, пилить AOT/LLVM, интегрироваться хаками в xcode, интеропаться со существующими 3rd party на Obj C/Swift. Если всего этого нет — это проблема не эпла. Xamarin'у вот никто не помешал реализовать всё вышеперечисленное на этой платформе без всяких джейлбрейков. А на java какие-то попытки кроссплатформа/конверт кода появляются временами, но все какие-то жуткие hello-world недоделки.
А вы всерьёз можете привести ссылку, что (корпоративные) системы на Java приносят меньше денег, чем мобильные игрушки? )
![image](https://habrastorage.org/getpro/habr/comment_images/cc0/886/c30/cc0886c30be7435e6e92d4e8bfda358a.jpg)
Только это Windows. А в целом вполне себе топ производительность.
Это то же TechEmpower.
Это показатель того, на сколько шустро работает рантайм + вебсервер.
Думаю многим это интересно, особенно в стадии гринфилд.
ASP.NET Core, если верить бенчмаркам, входит в тройку-пятерку лучших по производительности веб-фреймворков на Linux
А в таблице сортировка идет по `platform` и `micro-framework`. Если смотреть на фреймворки, забыв о платформах, то получается честное третье место.
Там основной прирост не сколько от рантайма, сколько от нормальных веб-сервера и конвеера обработки запросов. На Mono тоже достаточно шустро работает.
Зачем Mono? CoreClr + CoreFx уже вполне нормально на Debian живут. В 2.0 довезут остатки основных апи и еще оптимизаций. Да и Мигель уже в МС :D
По поводу места хз — так как непонятно попал ли билд с PGO на Linux или нет. Может кто помнит и уточнит.
Это где там PHP? :)Ctrl-F в помощь
Зачем Mono? CoreClr + CoreFx уже вполне нормально на Debian живут.Да вижу. А ASP.NET MVC, WCF и т.п. когда будут работать? И что теперь моно будет ненужно, можно будет .Net Core из коробки использовать? Где можно популярно почитать?
А разве MVC не работает? Уже даже LTS релиз есть. WCF не будет больше развиваться в серверной части. Давно уже сказали.
Я уже использую без Mono.
https://docs.microsoft.com/en-us/aspnet/core/tutorials/your-first-mac-aspnet. Тут Mac, но это не принципиально.
Вся каша в так называемых Target Framework Monicker. Если вы напишите net462 — будет бинарник для обычного .Net. А если netcoreapp1.1 — то будете запускать через dotnet run и это работает на любом совместимом дистре.
Просто надо понимать — весь легаси выкинули, апи перетрясли и кучу всего переписали.
То есть WebForms, серверная часть WCF, ВебСервисы(которые asmx), HttpModule's все выкинуто.
WebForms не будет — зачем вам редактор визуальный? :)Как зачем? Странички делать :) Давно ASP.NET не программировал, хочу запилить простенький сайт. Вот думаю, что делать: через визарды быстро в VS 2013 и bootstrap или уже в Linux-e попробовать в VS Code?
То есть WebForms, серверная часть WCF, ВебСервисы(которые asmx), HttpModule's все выкинуто.Навсегда или со временем добавят? Или оно уже не нужно? Чем заменили?
Я не видел редактора WebForms с 2009 года :D
Берёте Node.JS + Rails(еще кусочки Go типа Channels), переводите на C# и у вас .Net Core + Mvc Core.
1. WebForms только в legacy приложениях остались у тех, кто не переписал все на MVC.
2. WCF — ну как-то SOAP сейчас не сильно интересен :) Даже в Enterprise. REST, микросервисы и всякая подобная лабуда сейчас.
3. Это тем более труп еще как WCF вышел.
4. Middleware.
ASP.NET Core похож на классический только названием :)
Живет без IIS, а если и с ним, то IIS только как реверс прокси используется.
Либо просто SPA шаблон любой и Angular/React.SPA — это что? Можно попросить скинуть ссылочки на какой-нибудь мануал или туториал, пожалуйста?! Благодарю!
Берёте Node.JS + Rails(еще кусочки Go типа Channels), переводите на C# и у вас .Net Core + Mvc Core.В смысле?
2. WCF — ну как-то SOAP сейчас не сильно интересен :) Даже в Enterprise. REST, микросервисы и всякая подобная лабуда сейчас.Понятно, я просто думал, что в WCF есть REST, оказывается нет. Значит надо использовать всякие ServiceStack и ит.п.? Непонятно только почему ещё столько предложений работы с WCF.
http://asp.net-hacker.rocks/2016/09/19/aspnetcore-and-angular2-using-dotnetcli-and-vscode.html
MVC в момент своего появления очень многое взял от Ruby on Rails. Потом появился OWIN и Middleware, как в Node.JS. Go и Scala оказывают влияние на сам фреймворк(CoreFx). Например добавили каналы как в Go.
Тот кусочек(WebHttpBinding) постепенно отпочковался, переписался и обозвался WebApi :)
В классическом ASP.NET часто используется связка MVC + WebApi(2). В Core это безобразие свели в одно целое.
Если нужен просто формат SOAP — То форматтер накидать не проблема. Если начинается разговор про WS-Security, WS-Adressing и тд — то тут мимо.
Вакансии есть, так как огромное количество компаний имеют легаси код и/или просто боятся чего-то нового. Иногда просто пишут для галочки :)
«ASP.NET Core MVC с примерами на C# для профессионалов», Адам Фримен, (перевод Юрия Артёменко), бумага офсетная-белая, твердый переплет, 992 стр., ISBN 978-5-9908910-4-3, «ВИЛЬЯМС», 2017
Нашёл ещё хороший источник:
https://metanit.com/sharp/aspnet5/
Вроде бы, можно даже json-сериализацию прикрутить при отдаче ответов.
Просто wcf слишком тяжел, монструозен и сложно настраиваем для большинства программистов.
Ну и просто уже не модно.
Это чрезмерная абстракция, заточенная на SOAP и RPC. REST сервисы там очень неудобно делать. Странно что в 2017 году про этот ахтунг все еще вспоминают при наличии WebApi :)
А серваков не так много.
Выручают фичи, о которых Encarmine написал ниже — бинарная сериализация и замыкание сервисов на одной машине через pipes.А для удобства использования теми, с кем обмен данными пожиже — конечные точки с удобными клиентам интерфейсами.
Да и для моих задач soap оказался удобнее.
2. Двусторонний обмен — WebSockets. На порядки более удобное и масштабируемое решение.
3. Бинарная сериализация не привязана к WCF.
4. Для Discovery есть много решений. Тот же NetMQ предлагает из коробки
5. Обычный роутер ;)
Вы приводите узкоспециализированные примеры использования WCF, но при этом защищаете эту чрезмерную абстракцию. Не проще просто использовать нужный инструмент для задачи?
2. Забыли упомянуть, что оно не поддерживается подавляющим большинством клиентов;
3. Не отменяет того факта, что в WCF она есть;
4. WCF одно из множества решений, предлагающих discovery;
5. Скиньте доку где можно почитать про protocol bridging на обычном роутере?
Но это все неважно, я не утверждал что невозможно построить сервис на чем то другом, и отвечать на это не нужно. Мне просто печет от того, что на волне хайпа вокруг web-api незаслуженно забыли такое архитектурно-мощное решение. Если бы серверный WCF реализовали в .net core, он был быхорошим инструментом для любой задачи.
2. Это какими? Либы под вебсокеты есть под любую мэйнстрим платформу.
3. И причем она тут тогда?
4. WS-Discovery если быть точнее.
5. Protocol Bridging в основном используется с SOAP. Без него самой проблемы не возникает.
Какой хайп? Хайпом это было в 2012. Меня печалит, что в 2017 году все еще есть разработчики, которые верят в универсальные инструменты для всех задач. Это фантастика из середины двухтысячных и какой-то бич .Net комьюнити. :) WCF это пример дикой необоснованной абстракции. Именно текучесть этой абстракции и привела к появлению WebApi, который, напомню от него же и отпочковался.
Нормальный роутинг? Например комбинации версионирования апи по заголовку/пути/query параметру?
Производительность даже обсуждать нечего.
При желании натянуть можно очень многое. На то она и абстракция всего надо всем. Мне приходилоссь и JWT токены в XML заворачивать и тд. С SAML-P вообще ахтунг. Но это все последствия одной текучей абстракции, которая не несет никакого профита, кроме как быстрый старт(типа веб формы в редакторе накидать, а потом е**сь оно конём). Как только надо кастомизировать — получается что проще и дешевле использовать специализированный инструмент, чем натягивать глаз на одно место. Да еще и производительнее будет.
Тут Mac, но это не принципиально.1) Кстати как Net Core работает в маке? моно жутко тормозит
2) Если ли в Net Core WinForms, настольные приложения или планируют? Или здесь только моно поможет?
2. Нет. Десктоп либо UWP(с AOT компиляцией даже) или Mono. Основной фокус CoreClr на серверные приложения сейчас.
Десктоп либо UWP2) В смысле? Оно будет на линуксе ли маке работать или только windows?
Тут "альфа" — это скорее показатель того, что апи ещё может ощутимо меняться. В частности сейчас на рассмотрении висит рефакторинг виджетов верхнего уровня, переписывается стек отрисовки, практически наверняка будет меняться процедура инициализации. А в целом оно работает уже достаточно стабильно, более полутора тысяч тестов покрывают 60% кодовой базы.
В общем, если бы это делали в Microsoft, то обозвали бы бетой или даже rc1 (кавардак с тулингом .net core, я смотрю на тебя)
Апи во многом схож, но не повторяет 1 в 1 таковой из WPF. Так, иначе внутри устроены биндинги (активно используется RX), система смены визуальных состояний основана не на триггерах, а на селекторах, работающих с классами (назначаются значением атрибута каждому конкретному элементу) и псевдоклассами (примеры псевдоклассов: :pressed
, :pointerover`). В целом система стилей заимствует из идеологии CSS. Но в целом это всё тот же самый XAML с шаблонизорованными контролами и биндингами.
С биндингами моновскими основная проблема в том, что они либо активно используют либо свои нативные врапперы, которрые надо собирать на целевой системе (GTK и вообще glib-based либы), либо гвоздями приколочены к моновскому рантайму и зависят от его кастомной сборки (xamarin.Mac). С At вообще всё грустно, биндинги вроде и есть, но я на deabian-based дистрах ни разу не видел, чтобы они из репозитория сами нормально работали. В итоге это всё счастье совершенно непригодно для использования с .NET Core. Мне тут с месяц назад с GTK3 пришлось через P/Invoke вручную взаимодействовать.
Ссылка на статью
Дивный новый Roslyn: Кому нужны собственные анализаторы кода и скриптинг на C#?