Вхід і реєстрація
Посилання · 24 червня 2016, 13:16 8562
Андрей Литвинов, C Señor

.NET дайджест #11: Не все так красочно c .NET Core и С#, границы DDD и микросервисов, обзор подсистемы Windows для Linux

В выпуске: параллельные вычисления на одном ядре, поиск ошибки производительности, анонс ASP.NET Core RC2, 6 примеров неправильного использования событий, начало работы с Angular2 и WebPack, как деплоят ребята из Stack Overflow.

.NET

Channels как альтернатива DataFlow.

Параллельные вычисления на одном ядре с использованием пространства имен System.Numerics.

Json.NET поддерживает .NET Core RC2.

Возвращение MSBuild вместо project.json.

Унифицированное API поможет проще портировать приложения на .NET Core.

Поиск ошибки производительности, или еще одно напоминание, почему стоит сравнивать строки без учета культуры, если в ней нет необходимости.

Ветка с вопросом о крутых OSS .NET проектах.

Реализация markdown для .NET.

Пост, в котором автор рассказывает, что возможно не все так красочно c .NET Core и С#.

Довольно интересная дискуссия о том, можно ли создавать серьезные системные приложения на .NET: часть 1, часть 2, часть 3, часть 4.

ASP.NET

Анонс ASP.NET Core RC2.

ASP.NET Core расписание и roadmap. Похоже, что со дня на день должен быть релиз.

ASP.NET Core Engineering guidelines.

IdentityServer4 переписан на ASP.NET Core RC2.

Строготипизированные настройки конфигурации в ASP.NET Core.

Content negotiation in ASP.NET Core.

DDD/microservices

DDD and Microservices: наконец-то какие-то границы.

Пример реализации агрегата в Bounded context, использующем CQRS и EventSourcing.

Варианты решения вопроса взаимодействие между агрегатами. Дельный совет про инъекцию сервисов в методы агрегата. В своем приложении тоже пришел к такому заключению, особенно в процессе рефакторинга. Но злоупотреблять не стоит.

10 уроков которым научил долгоиграющий проект с DDD часть 1, часть 2.

6 примеров неправильного использования событий.

Windows

Обзор подсистемы Windows для Linux.

Tools

ReSharper Ultimate 2016.2 EAP.

Docker

Контейнеры и Docker на Windows Server 2016 TP5. И еще один блог-пост на эту тему.

JS

Экспериментальная поддержка WebAssembly в основных браузерах.

Резюме и самый интересный новости ng-conf 2016.

Начало работы с Angular2 и WebPack.

SQL Server

Запустили SQL Server 2016.

Other

Почему гугл хранит миллиарда строк кода в одном репозитории.

Доступны записи выступлений с Xamarin Evolve 2016.

Как деплоят ребята из Stack Overflow.

Обзор того, как OSS работает в Microsoft.

Обязательно к прочтению из hack.summit() 2016.


← Предыдущий выпуск: .NET Дайджест #10
Следующий выпуск: .NET Дайджест #12 →

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

Теми: .NET, .NET дайджест
👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn



57 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.
Valentin Nechayev архімаггриб в Дарницькі печери 27.06.2016 07:45
Довольно интересная дискуссия о том, можно ли создавать серьезные системные приложения на .NET: часть 1

Поправьте ссылку на часть 1 (различие в регистре, но получается 404).

Відповісти
Підтримати
Андрей Литвинов C Señor 27.06.2016 09:01

Спасибо, вот правильная ссылка codeofrob.com/...-good-.net-developer.html, видимо, она как-то сконвертилась при публикации. Думаю, Сегрей или Валентина скоро поправят.

Відповісти
Підтримати
Valentin Nechayev
Alexander Gatsenko 24.06.2016 21:59
Не все так красочно c .NET Core и С#
Так ребята с мелкософта опаздали на 11 лет. Ну хотябы стартанули это в 2010. А так не понятно, к чему все это ?
Відповісти
Підтримати
Андрей Литвинов C Señor 24.06.2016 22:09

Я думаю, .NET Core крут и будет популярен. Они его активно допиливают и будут портировать все больше API. ASP.NET Core работает на порядоко быстрее так что можно будет разрабатывать восоконагруженные приложения потребляя меньше ресурсов. И хостить это все на линухе, если угодно. Как по мне, то как раз вовремя.

Відповісти
Підтримати
Alexander Gatsenko
Alexander Gatsenko 24.06.2016 22:17

Сколько вы знаете не высоконагруженных серверов на .NET и Java? А сколько высоконагруженных платформ на .NET и Java? И сколько из них в opensource (не Microsoft & Oracle/IBM etc провайдеров)? А сколько нужно времени, что бы opensource комьюнити .NET хотябы приблизилось к комьюнити Java как по качеству, так и по количеству?

В свое время ответы на эти вопосы меня cклонили в сторону Java. Сейчас отвечая себе же на эти вопросы у меня возникает другой вопрос — к чему эта суета от Microsoft’а?

Відповісти
Підтримати
Андрей Литвинов
Андрей Литвинов C Señor 24.06.2016 22:28

Оу, сколько вопросов. Мне C# просто банально больше нравится, чем Java. И то, что MS поняли, что с линуксом лучше дружить — это очень большой скачек вперед. А по производительности ASP.NET Core приблизился к Scala, если еще не обогнал. Так что Java тут немного в стороне.

Відповісти
Підтримати
Alexander Gatsenko
Alexander Gatsenko 24.06.2016 22:48

Вы, навреное, не совсем понимаете попытки Microsoft’а оживить .NET (могу ошибаться). Основное в .NET core — это opensource. Можно было бы запилить поддержку *nix.NET с коммерческой лицензией. Ход конем (opensource) — это хоть как то оживить opensource комьюнити под .NET. Производительность здесь вообще ни причем (10% туда, 10% сюда не сильно играют поределяющую роль — посмотрите на проекты на PHP/Python/Ruby/Javascript — там иногда все 100% проседают). Основное — это комьюнити под платформу. Язык — это конечно классно (Java как язык и рядом не стоит с C#), но, сейчас, без вменяемой комьюнити и платфомы (в меньшей мере) — это ничего не значит. Например, как там с D vs C++? Или с Rust vs C++? Да особо никак. Вот точно так же и с .NET vs Java — тольстый клиент под винду vs ынтерпрайз/сервер/высоконагруженные приложения.
З.Ы. и да API от ASP.NET MVC в разы лучше, чем че то там в мире Java, но это не повод вложения бабла в эту технологию в каком то ынтерпрайз проекте, тем более стратапе (если высоконагруженное приложение — зачем тратиться на не понятно что — бери и юзай бесплатно куча готовых решений на джаве).

Відповісти
Підтримати
Андрей Литвинов
Андрей Литвинов C Señor 24.06.2016 22:59

Конечно, если под задачи лучше подходит джава — стоит выбирать джаву. Я не вижу (может, не замечаю) проблем с .NET коммюнити. Хотя от остальных PHP, Ruby, и т.п. далек.

Відповісти
Підтримати
Alexander Gatsenko
Sergey Litvinov .Net Developer в DataArt 27.06.2016 12:54

Ну не скажите. .Net core не только про opensource, а так же и про кросс платфомерную поддержку, и плюс про офф поддержку Microsoft-ом, чего явно не было у Mono, что весьма существенный плюс для энтерпрайза.

Відповісти
Підтримати
Alexander Gatsenko
Vitaliy Fedorchenko Founder в SeekTable.com 25.06.2016 12:01

«.net core-скептики» во многом правы — платформа сейчас ужасно сырая (от тузлов до самого фреймворка — в пакетах и версиях уже сейчас просто натуральный dependency hell в полный рост), что очень нетипично для MS. Чтобы в этом убедиться, достаточно попробовать сделать что-то на шаг право-влево от простейших MVC страничек \ REST API (например, подготовить билды своих библиотек под .NET Standards 1.3-1.5) — и это в RC2, выпущенном за месяц до релиза.

Ясно, что релиз 1.0 это больше маркетинговый ход и вот так магически в 1.0 все не станет стабильно и неглючно. Еще 6-12 месяцев — это даже оптимистичный сценарий, учитывая сколько времени заняло дойти до того что имеем на текущий момент.

Также MS ярко подпортила имэйдж с цирком k-runtime, ASP.NET 5, dnx, asp.net 1.0 core — подавая совершенно разной направленности сигналы потребителям платформы, а также массово забивая на свои же технологии (WCF, WebForms вот это все — список длинный. Вложено кучу ресурсов — люди изучали, внедряли, базировались, и все в дедпул). В итоге вроде бы текущий фреймворк 4.x то легаси, то уже не легаси, и там где был выбор .net с мутным будущем или что-то другое, в последние годы выбирали что-то другое.

p.s. разрабатываю на .net с самой первой версии, и полностью зависим от этой платформы — и как вендор .net компонентов, и как разработчик. Очень хочется надеяться, что «там наверху» изменят текущее состояние вещей, добавят вагон ресурсов и смогут стабилизировать платформу как задумано, до того как она перейдет в маргинальную нишу. Пока что прогноз по принципу вчерашней погоды, не очень радостный.

Відповісти
Підтримати
Андрей Литвинов
Андрей Литвинов C Señor 25.06.2016 12:55
с цирком k-runtime, ASP.NET 5, dnx, asp.net 1.0 core
по-моему, все понятно и логично. k — это было временное название для dnx. А переименоване в Core и создание .NET Core чтобы на платформе можно было не только веб-приложения создавать, но и сервисы — очевидное решение, жаль, что они сразу так не слелали.
забивая на свои же технологии
Из-за WebForms я думаю не много кто расстроится, тем более Full Framework никто не отменял. То же и с WCF, если нужно — используйте.

Для себя я вижу использование .NET Core в производительный микросервисах, тех, в которых на него можно легко перейти. Опять, же, использовать там, где применимо.

Відповісти
Підтримати
Vitaliy Fedorchenko
Vitaliy Fedorchenko Founder в SeekTable.com 25.06.2016 13:31

Это стало логичнее и понятнее после переименования в .NET Core 1.0 (потребители платформы это не только разработчики. Есть еще много тех, кто совсем не разработчики но принимают решения, и они в первую очередь ориентируются на официальные блоги/презентации MS), и уже совсем понятнее после объяснений куда все идет с .NET Standards — а это было аж несколько месяцев назад если не ошибаюсь.

Из-за WebForms я думаю не много кто расстроится
Я вот подобное массово-негативное отношение к этой технологии наблюдаю только у наших аутсорсеров. Вы просто не представляете сколько людей продолжают использовать WebForms в мире, и как ни странно — особенно в развитых странах (моя выборка — тысячи фидбеков и вопросов по моим компонентам, с 2013 года). Я наблюдаю, что WebForms/WebPages технология просто отличная для бизнеса — особенно для использования не профессиональными разработчиками, когда надо заткнуть текущую потребность прямо сейчас — сгенерить простую форму, отрендерить какой нибуть invoice. Они просто делают это очень быстро (и дешево) добавляя 1 aspx файл, и г%%нячат аки в PHP (но в отличие от — могут быстро накидать туда UI-контролов). И это реально работает — мир не состоит только из монстроидальных тырпрайз систем.
Ответ «вот же он остался WebForms» слабый — технология не развивается, хотя идеологически есть куда и что исправлять хоть отбавляй. Кто мешал перескочить от серверного рендеринга к MVVM, при этом сохранив компонентную модель для UI контролов?.. MVC это же шаг назад на лет 15 — все эти контроллеры модели и шаблоны у нас были в 2000-м на PHP, низкий уровень абстракции и сложный реюз, делать Web UI все так же дорого и долго. Прорыв есть в плане переносимости — но в большинстве реальных веб-проектов это не было критичным — выбрали .net / windows, и ладно. MVC Core не имеет никаких концептуальных преимуществ перед аналогичными фреймворками на пхп\руби\js.

По WCF также могу пройтись, но это уже точно оффтопик.

Відповісти
Підтримати
Андрей Литвинов
Дмитро 27.06.2016 12:53
Я вот подобное массово-негативное отношение к этой технологии наблюдаю только у наших аутсорсеров. Вы просто не представляете сколько людей продолжают использовать WebForms в мире, и как ни странно — особенно в развитых странах (моя выборка — тысячи фидбеков и вопросов по моим компонентам, с 2013 года).
Да, ну? Вы и вправда наивно полагаете что все это потому, что Web Forms удобней любой из PHP CMS и быстрее для освоения непрофессионалом, а не из-за плюшек саппорта с хорошими гарантиями на уровне корпоративных лицензий и общей тенденции к использованию legacy систем оставшихся в наследие из 2000?
MVC Core не имеет никаких концептуальных преимуществ перед аналогичными фреймворками на пхп\руби\js.
Думаю, все-таки имеет. Насколько мне известно перечисленные технологии одновременно не предоставляют асинхронность с неблокирующим i\o, многопотчоностью и условную типизацию в рамках одной платформы.
Відповісти
Підтримати
Vitaliy Fedorchenko
Vitaliy Fedorchenko Founder в SeekTable.com 27.06.2016 13:50
Да, ну? Вы и вправда наивно полагаете что все это потому, что Web Forms удобней любой
Я наивно полагаю, что несмотря на известные проблемы (исполнение было далеко от идеального, факт), концептуально технология была весьма мощной, ориентированной на реюз компонентов и снижение издержек, особенно в бизнес-аппах. Что предложено взамен — MVC с тем же уровнем абстракции, что был и 15 лет назад — обработкой GET/POST для любого чиха?.. Без какой-либо вменяемой компонентной архитектуры, с размазыванием кода по файлам. Нормальный подход для контентовых сайтиков, отстой для репид девелопмента веб аппов. В любом случае, это мое мнение и мой опыт.
не предоставляют асинхронность с неблокирующим i\o, многопотчоностью и условную типизацию в рамках одной платформы.
для большинства асп.нет аппов (формошлепство), все эти фичи не являются маст-хев, а причина тормозов находится на уровне запросов к бд. Особенно если потребители приложения — аж эти все 50-100 юзеров какого-то относительно небольшого бизнеса. И попробуйте используя только эти аргументы, обосновать преимущества .net core (глючного на данный момент) перед альтернативными платформами для бизнеса, которому по большому счету все равно что там под капотом и какими кейвордами оперируют наемные спецы.
Відповісти
Підтримати
Дмитро
Дмитро 27.06.2016 14:11
обосновать преимущества .net core (глючного на данный момент)
вы интересовались концептуальной разницой технологий, если вопрос только в сроках — любой PHP фрилансер перебьет ASP.NET Web Forms проект по срокам с простым сайтом на CMS и бюджетом в разы меньшим на развертывание\разработку\сопровождение.
Если вопрос в качестве — то ASP NET MVC и сопуствующие фреймворки гибче Web Forms. В современной веб-разработке люди уже давно не парятся вопросами оптимизацией размера Server State и разбухшей разметки, и не потому что в корпоративных сетях гонять и рендерить метры этого мусора — стало ок, они это просто выкинули как страшный сон и стараются не вспоминать, когда их пытаются заманить на мертвые Enterpirise проекты. Ничего удивительного что MS не инвестирует в эту «нишу».
Відповісти
Підтримати
Vitaliy Fedorchenko
Vitaliy Fedorchenko Founder в SeekTable.com 27.06.2016 18:06

Если ошибаюсь поправь — я думаю, ты из свежего поколения, для которого дотнет был всегда (в смысле, не застал времена когда его еще не было), а WebForms запомнился только как непонятный зверь с безумной логикой биндинга и здоровыми вьюстейтами. Как и любую технологию, ее можно было использовать криво и стрелять в ногу, кто спорит. А можно было готовить правильно, и тогда она позволяла действительно осуществлять rapid development — напомню, я изначально говорил про вебформы как техологию для бизнес вебаппов, где стопятсот списков-форм-переходов, описывающих кастомный бизнес процесс. Альтернативы которая позволяла бы делать это еще быстрее И дешевле (имхо важнейший критерий ценности технологии) — на самом деле сейчас нет.

з.ы. сейчас слепить SPA который грузит 10мб — это типа норм, зато вьюстет в 50кб это же ужас-ужас =)

Відповісти
Підтримати
Дмитро
Дмитро 27.06.2016 18:41

Rapid development связанных списков можно сделать и в SAP и в 1С, Oracle и любой другой ERP\CRM\BPM системе. Это имеет мало общего с веб разработкой и проблемами, которые есть в ней сейчас. Для этих задач никто не нанимает ASP.NET Web Forms девелопера, что бы порешать их «быстро» разработав систему с нуля, которую еще прийдеться и интегрировать с ERP и админинстрировать кому-то.

Відповісти
Підтримати
Vitaliy Fedorchenko
Igor Golodnitsky те самые 5k$ в PreciseQ 28.06.2016 14:05

Есть большие компоненты, которые не плохо смотрелись в web forms.
demos.devexpress.com/ASPxPivotGridDemos

Відповісти
Підтримати
Дмитро
Vitaliy Fedorchenko Founder в SeekTable.com 28.06.2016 16:23

Пора переходить на вітчізняного виробника )) pivottable.nrecosite.com

Відповісти
Підтримати
Igor Golodnitsky
Sergey Litvinov .Net Developer в DataArt 27.06.2016 19:51

10мб SPA должно кешироваться на клиенте (не говоря о том что это как-то сильно много даже для SPA). А 50кб вьюстейта будет в каждом запросе без кеширования. Причем когда страница маленькая ~5kb, и у неё 50кб вьюстейта который будет в каждом запросе — ну это как-то сильно уж.

Відповісти
Підтримати
Vitaliy Fedorchenko
Vitaliy Fedorchenko Founder в SeekTable.com 27.06.2016 20:05

Ну, 10 лет назад это все бегало, а тут во времена 8-ядерных смартов и массового 4г стало вдруг непереносимой болью )) тем более, что с вьюстейтом после .нет 3.5 стало лучше. Моя теория — забили, так как олдскульные архитекты которые продвигали компонентную разработку — все эти XML-модели там же, ушли (может и на пенсию бгг), а молодая смена не пойняла полета мысли дедов, и давай строчить клон рельсов со своим блекджеком и json конфигами. Кстати тяжко шло, MVC 1.0 был еще той адской поделкой.

Відповісти
Підтримати
Sergey Litvinov
Дмитро 27.06.2016 20:26

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

Відповісти
Підтримати
Vitaliy Fedorchenko
Sergey Litvinov .Net Developer в DataArt 27.06.2016 21:24

он же ThreadStatic что не совсем тоже самое. Ну и Core 1.0 они ушли от этого

Відповісти
Підтримати
Дмитро
Sergey Litvinov .Net Developer в DataArt 27.06.2016 22:41

Да ладно. HttpContext.Current по факту идёт в ContextBase, который по факту хранится в Thread.CurrentThread, что в общем-то идеологически является ThreadStatic.У каждого потока свой статический экземпляр контекста, который хранится в самом же потоке и инициализируется ASP.Net пайплайном.

Відповісти
Підтримати
Дмитро
Дмитро 27.06.2016 23:27
У каждого потока свой статический экземпляр контекста,
Там не так. 1 запрос может выполняться в разных никак не связанных потоках, если есть асинхронные i\o операции, к тому же это асинхронная оперция — пока она выполняеться нету ниодного потока к которому привязан текущий запрос вообще. Вся синхронизация основана на AspNetSyncContext и замыканиях переданных в Continuations.
Відповісти
Підтримати
Sergey Litvinov
Vitaliy Fedorchenko Founder в SeekTable.com 27.06.2016 21:26

у дедов зато релиз-кандидаты постабильнее были )) ничего асинхронного в .нет 1.0 не было. Даже кривые Begin*/End* появились чуть позже. На то время, иис+асп.нет вебформы показывали очень и очень приличный перфоманс. И вообще не было асинхронных веб-серверов. Ширше надо смотреть на историю, критикуя дедов — сохранение обратной совместимости штука непростая. А подход «разрушим до основанья, а затем» достаточно гм спорный, то что выходит «затем» часто бывает уже никому не нужно.

Відповісти
Підтримати
Дмитро
Дмитро 27.06.2016 22:02
Ширше надо смотреть на историю, критикуя дедов — сохранение обратной совместимости штука непростая
Последние лет 10 только и делали, что пытались выпилить эту обратную совместимость в виде System.Web, надизайнили как надо — намертво.
ичего асинхронного в .нет 1.0 не было. Даже кривые Begin*/End* появились чуть позже.
на целый год позже! при этом поломав всю совместимость в 1.1 оставили дизайн asp.net из 1.0 и обречены были на страдания, любители самого быстрого ооп антипаттерна все последующие 15 лет.
Відповісти
Підтримати
Vitaliy Fedorchenko
Artyom Krivokrisenko 27.06.2016 22:45
на целый год позже!
Внезапно реализация асинхронных контролеров в первой версии ASP.NET MVC тоже вызывала желание пойти проблеваться, и нормальное юзабельное решение появилось вроде только в 3 версии
Відповісти
Підтримати
Дмитро
Vitaliy Fedorchenko Founder в SeekTable.com 27.06.2016 23:08

отмучались бедняги, зато сейчас заживем! Нет бинарной сериализации? А и не надо, это деды намудрили. Ой, нет DataSet/DataRow? Ф топку, антипаттерн, там же в штабе точно не дураки сидят ))

Відповісти
Підтримати
Дмитро
Artyom Krivokrisenko 27.06.2016 22:41
ничего асинхронного в .нет 1.0 не было. Даже кривые Begin*/End* появились чуть позже.
Ну справедливости ради, в 2000 году асинхронные веб-страницы и так были не нужны.
Відповісти
Підтримати
Vitaliy Fedorchenko
Artyom Krivokrisenko 27.06.2016 22:38
Построить весь веб фреймворк вокруг статического HttpContext
Из статического там же вроде только HttpContext.Current был? На моей памяти особых проблем он не доставлял, плюс там были более цивилизованные способы получить доступы к текущему контексту, не особо отличающиеся от того, что запилили в MVC.
это от большего ума определенно.
Не знаю, от большого или не от большого, но больше 10 лет на той архитектуре просидели, запилили миллионы веб-приложений. и MS не приходилось выпускать новую версию каждый год, как сейчас.
Відповісти
Підтримати
Дмитро
Дмитро 27.06.2016 22:58
Не знаю, от большого или не от большого, но больше 10 лет на той архитектуре просидели,
а было из чего выбирать? так и не запили ниодного альтернативного веб-сервера. зато как отказались от AspNetSyncContext для синхронизации — так сразу стало в 23 раза больше запросов пропускать на том же железе. как упростили контекст и отказались от статической типизации на уровне контрактов HttpContext и сделали нормальную расширяемость так и за пару месяцев сумели запилить на libuv веб-сервер для asp.net.
Відповісти
Підтримати
Artyom Krivokrisenko
Artyom Krivokrisenko 27.06.2016 23:08
зато как отказались от AspNetSyncContext для синхронизации — так сразу стало в 23 раза больше запросов пропускать на том же железе. как упростили контекст и сделали нормальную расширяемость так и за пару месяцев сумели запилить на libuv веб-сервер для asp.net.
Это офигенно, но как видно по графикам, пик популярности пришелся на момент выхода ASP.NET 2.0, построенным поверх богомерзкого HttpContext, а загнулось все после выхода православного ASP.NET MVC.

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

Відповісти
Підтримати
Дмитро
Дмитро 28.06.2016 07:48

Если судить по графику с точки зрения того что популярней asp.net mvc или веб формы, то он ниочем. То что интерес к asp.net начал падать среди прочих технологий уж точно не из-за того, что появилась mvc реализация, а скорее наоборот. Также история и с core — мс закрыли важные хвосты и сделали up to time фреймворк, каким он должен быть и каким asp.net до этого момента не был. Поздно — да, но в целом asp.net еще достаточно живая технология что бы говорить что это никому не нужно.

Відповісти
Підтримати
Artyom Krivokrisenko
Artyom Krivokrisenko 28.06.2016 08:23

Этот график о том, что после выхода абсолютно сырого ASP.NET MVC, который существенно уступал web forms как платформа, фанаты MS поняли, что в импери добра окончательно упоролись и все начали валить с .NET/Windows платформы кто куда попало, конец предсказуем, MS теряет 35% market share всего за несколько лет.

События следующих 5 лет показали, что они сделали правильный выбор.

Также история и с core — мс закрыли важные хвосты
Решили кучу проблем, забыв у кастомеров перед этим поинтерисоваться, нужно ли кому-то решение этих проблем.
каким он должен быть и каким asp.net до этого момента не был.
Ну что, это офигенно, что теперь мне проще и быстрее запилить бекенд сайта на javascript в emacs чем на ASP.NET (хотя раньше мне для этого нужно было нажать несколько кнопочек и настроить нужные свойства в дизайнере, а теперь нужно вручную править json конфиги).
Відповісти
Підтримати
Дмитро
Дмитро 28.06.2016 09:01

Насколько я видел Фаулеру достаточно активно реагировал на запросы комьюнити по добавлению фич в corе. Я тоже был удивлен , когда оказалось что под маком запилить и отдебажить в vs code и задиплоить в докере asp.net сайт не многим сложней node. Учитывая куда более вменяемый рантайм .net с нормальной системой типов в отличии от node единственное, что заставляет использовать Ноду — стабильность платформы и наличие изобилия компонентов, в .net core с этим пока совсем глухо. Но думать про node в перспективе сложно.

Теория с графиком и виной всему mvc звучит немного как bull shit по множеству причин, я слышал много cool story от зрящих в корень проблем мс людей но это уже совсем на смех пробивает.

Відповісти
Підтримати
Artyom Krivokrisenko
Sergey Litvinov .Net Developer в DataArt 27.06.2016 21:30

имхо, мысли дедов MS-а были в том чтобы упростить переход с WinForms на WebForms. Они очень близки в этом — тот же дизайнер в студии, та же подписка на события через дизайнер и странная обработка OnClick-ов и остальных вещей. Те же странные AutoPostback-и. Такой же ужасный HTML код, который сгенерированный этим дизайнером. Я видел один такой проект, который был сделан аля WinForms, который совершенно не учитывал веб специфику.... это было печально.... и это к слову то что было у MS в их обучающих видео по ASP.Net-у первых версий

Відповісти
Підтримати
Vitaliy Fedorchenko
Artyom Krivokrisenko 28.06.2016 08:27
имхо, мысли дедов MS-а были в том чтобы упростить переход с WinForms на WebForms
Нормальная мысль, и народу понравилось. Но потом что-то пошло не так, и вместо тягания контролов и настройки их свойств в дизайнере всех отправили вручную рендерить html как в 95-м году.

Можно представить, что было бы если б вместо выпуска WPF, народу в качестве замены Win Forms предложили бы обертку для вызова Win32API функций.

Відповісти
Підтримати
Sergey Litvinov
Андрей Литвинов C Señor 28.06.2016 11:15

Внезапно, в WPF интерфейс тоже строится с использованием языка разметки. Возможно, такой подход к построению интерфейсов во многом более удобный и гибкий?

Відповісти
Підтримати
Artyom Krivokrisenko
Artyom Krivokrisenko 28.06.2016 11:17

В WPF есть более менее нормальный дизайнер, а редактировать XAML с 20-уровнями вложенности — удовольствие далеко не из приятных, но маемо те що маемо

Відповісти
Підтримати
Андрей Литвинов
Artyom Krivokrisenko 27.06.2016 14:11
асинхронность с неблокирующим i\o, многопотчоностью и условную типизацию в рамках одной платформы
Эээээ... Java?
Відповісти
Підтримати
Дмитро
Denys Slipetskyy Lead Software Engineer в EPAM 27.06.2016 17:05

Как минимум Ratpack and Vert.x ... да и Spring уже тоже предоставляет + в 5.0 будет еще больше. Node.js тоже умеет неблокирующий и\о но его надо в несколько процессов еще запускать чтобы все ядра загрузить, но есть средства которые это решают ...

Відповісти
Підтримати
Artyom Krivokrisenko
Igor Golodnitsky те самые 5k$ в PreciseQ 28.06.2016 13:34
Кто мешал перескочить от серверного рендеринга к MVVM, при этом сохранив компонентную модель для UI контролов?

«visual web gui» — например, крутая штука, но умерла.

Відповісти
Підтримати
Vitaliy Fedorchenko
Serhii 01.07.2016 17:25
Кто мешал перескочить от серверного рендеринга к MVVM, при этом сохранив компонентную модель для UI контролов?
Здравый смысл.
MVC Core не имеет никаких концептуальных преимуществ перед аналогичными фреймворками на пхп\руби\js.

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

Відповісти
Підтримати
Vitaliy Fedorchenko
Artyom Krivokrisenko 27.06.2016 14:15
по-моему, все понятно и логично. k — это было временное название для dnx. А переименоване в Core и создание .NET Core чтобы на платформе можно было не только веб-приложения создавать, но и сервисы — очевидное решение, жаль, что они сразу так не слелали.
Честно говоря не вижу ничего логичного. Для тех, кто пристально не следит за каждым шагом MS, весь процес напоминает то, как Дядя Федор писал письмо своим родителям.
Відповісти
Підтримати
Андрей Литвинов
Андрей Литвинов C Señor 27.06.2016 14:27

Те, кто не следит — могли бы просто подождать релиза. Кстати, сегодня должен быть.

Відповісти
Підтримати
Artyom Krivokrisenko
Vitaliy Fedorchenko Founder в SeekTable.com 28.06.2016 12:45

Ну что, первый пошел — NReco.PivotData успешно сбилдил под .NET Standards 1.5 (пока nuget пакет не релизил — собираю фидбеки. Кто захочет потестить вышлю билд).

Кстати, .NET Core-потребители, нет ли потребности в либе, которая предоставляет абстрактный data layer — нечто вроде старого DataAdapter + абстрактные query? Нечто более удобное, чем низкоуровневый System.Data.Common (где надо SQL ручками композить), предоставляющее быстрый CRUD-интерфейс к БД. Для тех случаев когда EntityFramework не подходит. Могу портировать такую либу из закромов родины.

Відповісти
Підтримати
Sergey Litvinov
Sergey Litvinov .Net Developer в DataArt 27.06.2016 14:31

Согласен это не совсем логично, но ведь это их внутренее имя, которое они изменили ближе к релизу. Я понимаю возмущения если бы они меняли названия между релизными версиями, но по факту ведь это все было community preview\beta\etc, которые вполне могли переименовать тулинг во время процесса разработки.

Відповісти
Підтримати
Artyom Krivokrisenko
Oleh Prokaza software developer 24.06.2016 21:47
Channels как альтернатива DataFlow.
лучше редиректить сюда: github.com/....Threading.Tasks.Channels
Відповісти
Підтримати
Андрей Литвинов C Señor 24.06.2016 21:57

Отлично, я пока глубоко не изучал, прото где-то упоминалось, но вещь интересная и добавил себе на потом разобраться. Спасибо за ссылку!

Відповісти
Підтримати
Oleh Prokaza

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

Не підписуватись

Радимо почитати

Як та чому ми закрили продукт: кейс мобільного застосунку Frenzie
Факап вебпроєкту, або Як втратити $45 000 через розробку сайту на Flutter
Російський хакерський інструмент: чи небезпечний Flipper Zero для українців
«Баристи переважно не вірили в наш задум». Айтівець — про те, чому облишив роботу у стартапах і запустив власний сервіс з підбору й доставки кави
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.