×

.NET Core: возможности и перспективы

Я начал следить за платформой .NET Core ещё с момента анонса. В своё время я успел ознакомится с версиями RC1, RC2 и сейчас активно изучаю возможности RTM версии. На сегодняшний момент .NET Core представляет собой легковесное модульное кросс-платформенное решение, позволяющее, помимо прочего, пользоваться всеми преимуществами классического .NET. В этой статье я предлагаю взглянуть на возможности обновлённой платформы и её перспективы.

Предыстория

Появившись в 2002 году, платформа .NET прошла долгий путь и смогла завоевать сильные позиции как надёжное решение корпоративного уровня. Долго время .NET была мультиплатформенной средой, позволяющей создавать серверные и десктопные приложения, приложения для мобильных и встраиваемых устройств, приложения для развёртывания в облачной инфраструктуре. Но при этом не являлась кроссплатформенной и поддерживала исключительно операционные системы семейства Windows.

Скорее всего, если вы слышали про .NET Core, то слышали про него то, что это новый .NET, который работает под Linux и Mac OS X. Именно возможность запуска платформы на ОС, отличных от Windows, и вызвала в свое время множество споров и обсуждений. Хотя, на самом деле, задолго до появления .NET Core уже существовали кроссплатформенные реализация .NET Framework. Два самых известных проекта — небезызвестный проект Mono, который не раз был отмечен даже самой Microsoft, и DotGNU, в свое время поддерживаемый Free Software Foundation. На сегодняшний день проект DotGNU уже закрылся, а вот Mono, наоборот, в последние два года получил активное развитие. Mono представляет собой open source реализацию .NET, поддерживающую операционные системы Linux и Mac OS X. Развивается Mono независимым сообществом разработчиков, которые занимаются реинжинирингом компонентов .NET и создают их кроссплатформенную реализацию. Ввиду этого Mono всегда была «догоняющей» платформой, в которой возможности оригинального .NET появлялись спустя довольно длительное время.

Главное отличие .NET Core от Mono состоит в том, что Mono — это именно перенос «большого» .NET, на платформу *nix. В то время, как .NET Core — это спроектированная практически с нуля платформа, изначально рассчитанная на работу с различными ОС. При этом большая часть кода которой писалась с тем, чтобы платформенно-специфичных зависимостей было как можно меньше. На приведенном ниже графике — соотношение общего кода платформы и кода специфичного для каждого отдельно взятого семейства ОС:

Что нового

По своей сути .NET Core — это практически полная перезагрузка стека .NET Framework. Из новой платформы по разным причинам был исключён ряд технологий. Следует понимать, что платформа .NET Core рассчитана в первую очередь на разработку для серверных и облачных решений. Для десктопных приложений лучше подходят классический .NET для Windows (с поддержкой WPF и Windows Forms) и Mono для Linux и Mac OS X (с поддержкой Windows Forms). Мобильные проекты можно создавать, используя Xamarin. На схеме показано, как технологии распределены внутри различных реализаций .NET:

Таким образом, в .NET Core были исключены:
— ASP.NET WebForms;
— WCF;
— WPF;
— Windows Forms.

Зато инструменты для разработки консольных и веб-приложения получили новый этап развития. При разработке большинство необходимых компонент приложения могут загружаться как отдельные модули через пакетный менеджер NuGet. Это позволяет уменьшить количество избыточных зависимостей и общий размер готового продукта.

На изображении ниже показано, как соотносятся между собой классический .NET и .NET Core.

Open Source. В отличии от классического .NET Framework, код которого по большей части является закрытым, код .NET Core полностью открыт и распространяется под лицензиями MIT и Apache2.

Стоит отметить, что после открытия кода .NET Core команда, занимающаяся разработкой проекта Mono, объявила о намерении объединения кодовой базы тех компонентов Mono, которые реализованы в .NET Core.

Работа в облаке. Как и проект, написанный на классическом .NET, проект на базе .NET Core достаточно легко перенести в облако. Microsoft Azure уже поддерживает размещение .NET Core проектов как в службах Application Services, так и на виртуальных машинах.

Библиотеки для работы с сервисами Microsoft Azure также уже начинают портироваться на .NET Core. Например, Windows Azure Storage уже доступна для работы. Соответственно Azure Storage Services могут использоваться в core-проектах.

Также, для проектов .NET Core появляется возможность размещения на площадках тех облачных провайдеров, которые не обеспечили поддержку Windows окружения, но при этом обладают другими привлекательными возможностями. Например, виртуальные серверы Digital Ocean за счет использования SSD дисков очень быстрые, но на данный момент позволяют разворачивать только ОС семейства Linux. Развернуть проект на .NET Core на подобно сервере не составит труда.

Инструменты для работы с .NET Core

Несмотря на то, что платформа только недавно получила статус RTM (release to market), уже имеется ряд удобных и мощных средств для разработки. Давайте рассмотрим подробнее, какие инструменты доступны уже сейчас для .NET Core разработчиков.

Project Rider — IDE от компании JetBrains, той самой компании, которая создала ReSharper, наверное, самый популярный плагин для Visual Studio. В основе Rider лежат IntelliJ IDEA (являющаяся основной для целого семейства IDE) и наработки, используемые в ReSharper. На данный момент Rider поддерживает разработку как под Mono, так и под .NET Core. Следует помнить, что на данный момент Rider находится в стадии EAP (Early Access Preview) и по сути не предназначен для использования в production, однако уже дает возможность оценить имеющийся потенциал. Rider доступен как под Windows, так и под Linux и Mac OS X.

Visual Studio Code — редактор (хотя уже практически IDE), разработанный компанией Microsoft на базе ядра Electron (того самого, на котором основан Atom). Благодаря большому количеству плагинов VS Code поддерживает разработку не только под Mono и .NET Core, но также и под другие языки, включая Go, C/C++, JavaScript, Typescript, etc. Visual Studio Code работает как под Windows, Linux и Mac OS X.

Visual Studio Community Edition — одна из редакций той самой Visual Studio, которая де факто уже стала эталоном IDE. При этом Community Edition распространяется бесплатно и может быть использована в разработке коммерческого ПО. Естественно, как флагманский продукт компании, именно эта IDE даёт наибольшее количество возможностей для как c .NET/.NET Core, так и с Mono. Единственное ограничение этой IDE — на данный момент существует исключительно версия под Windows. Что впрочем не мешает разрабатывать и отлаживать проекты, которые будут работать под Linux и Mac OS X.

ReSharper — наверное, самый популярный плагин для Visual Studio, который добавляет возможности анализа и рефакторинга кода. Буквально несколько дней назад вышла версия 2016.2, в которой реализована полная поддержка проектов на базе .NET Core.

Существующие решения

Уже сейчас есть несколько интересных проектов для построения веб-сайтов на базе .NET Core:

Platformus CMS. Как пишет о сам автор Дмитрий Сикорский: «Platformus CMS — молодая система управления содержимым веб-сайтов (10-я альфа на момент написания статьи), построена на базе не менее молодых ASP.NET Core и ExtCore Framework. Написана CMS на C#. Благодаря возможностям ASP.NET Core, она одинаково хорошо может работать на Windows, Linux и Mac. Сама исполняемая среда, необходимая для работы любого приложения на .NET Core, может быть как установлена отдельно, так и интегрирована непосредственно в само приложение». Подробнее о CMS можно прочитать здесь.

Orchard. Orchard — система управления контентом с открытым исходным кодом от компании Microsoft. Первая версия CMS была анонсирован в марте 2010 года и основывалась на ASP.NET MVC. Вторая версия активно разрабатывается уже на основе ASP.NET Core. Подробности на сайте проекта.

Платформа корпоративного уровня для всех

Обычно, когда говорят про .NET, то в первую очередь подразумевают крупные корпоративные проекты с высокими требованиями к надёжности, масштабируемости и расширяемости. И при этом с дорогой инфраструктурой. Поэтому разработка под .NET всегда была достаточно недешёвым удовольствием. Однако с .NET Core все немного иначе.

Оставляя в наличии все плюсы классической версии, новая версия позволяет значительно снизить инфраструктурные затраты. Хостинг проекта на .NET Core обходится гораздо дешевле хостинга проекта на «большом» .NET. Так в Microsoft Azure самая дешёвая виртуальная машина с возможностью хостинга ASP.NET веб-приложения будет стоит от $13 в месяц. Размещение в службе Azure App Services в тарифе Shared будет стоить от $9 в месяц. При этом размещение проекта на виртуальном сервере у Digital Ocean обойдётся всего в $5 в месяц. При этом количество ресурсов выделяемых на приложение будет гораздо больше, чем у Shared-сервиса, а если сравнивать с виртуальной машиной от Azure, то конфигурация Digital Ocean будет выгодно отличаться наличием SSD диска.

Конечно, для крупных корпоративных проектов подобные суммы не имеют никакого значения. Более того, корпоративная среда достаточно консервативна. Поэтому, на мой взгляд, .NET Core начнёт широко использоваться в enterprise проектах не ранее чем через 2-3 года, как это было с ASP.NET MVC. В текущем же своём виде новая платформа будет играть в том же сегменте, где сейчас находятся такие технологии, как Node.js и Ruby — это небольшие проекты с ограниченным бюджетом и невысокой архитектурной сложностью. Крупные решения как и прежде будут реализовываться на «большом». NET. Таким образом, целевой аудиторией .NET являются стартапы и рынок малого и среднего бизнеса.

Выводы

Исходя из всего вышесказанного, можно сделать вывод, что .NET Core позволяет небольшим проектам и стартапам получить все преимущества платформы корпоративного уровня, при этом предоставляя удобные и средства разработки, а также недорогую инфраструктуру. В будущем же неизбежен приход платформы и на крупный корпоративный рынок.


P.S. Если вы заинтересовались разработкой под .NET Core и хотите быть в курсе новостей и тенденция платформы, приглашаю вас присоединиться к группе .NET Core Ukraine User Group. В группе можно обмениваться полезной информацией и сообща находить ответы на возникающие вопросы. Группа ориентирована как на специалистов, которые уже знакомы со стеком технологий от Microsoft и хотели бы изучить возможность развёртывания своих проектов на операционных системах семейства *nix, так и на тех, кто только начинает изучать возможности .NET.

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

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному2
LinkedIn

Схожі статті

  • Тернистим шляхом до системи логування GraylogТернистим шляхом до системи логування Graylog

    Євгеній Сафонов

    Цю статтю спрямовано на огляд дуже універсальної системи логування, приклади й практичний досвід наводитимемо через призму всесвіту .NET / .NET Core. Але ця інформація може допомогти всім без винятку, хто шукає системи такого класу. 18

  • Співбесіда з .NET. 150+ запитань для Junior, Middle, SeniorСпівбесіда з .NET. 150+ запитань для Junior, Middle, Senior

    Редакція DOU

    Редакція DOU поспілкувалась з розробниками, що проводять технічні співбесіди для різних рівнів .NET-спеціалістів, і зібрала приблизний список запитань для кандидатів. У матеріалі є і теоретичні питання, і практичні задачі. 95




76 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.
.NET Core позволяет небольшим проектам и стартапам получить все преимущества платформы корпоративного уровня, при этом предоставляя удобные и средства разработки, а также недорогую инфраструктуру.
Это канечна безусловно, но возьмем один только EF:
blogs.msdn.microsoft.com/...framework-core-1-1-plans
Entity Framework Core 1.1 Plans:
Fix a lot of the bugs reported on the 1.0 release in order to improve stability
Tackle a number of critical O/RM features that are currently not implemented in EF Core
А если посчитать, то получается:
92 бага с типами
232 enhancements
29 рефакторингов
Удачи стартапам! :)
А серьезней, то движутся в правильном направлении, но пока сыровато.
но пока сыровато.
Так о том и пишу, что всерьез платформу только года через полтора два можно будет использовать. Но для pet-projects и чего-то небольшого вполне подойдет. Держу сейчас пару проектов на .NET Core — особых проблем к счастью не встретил.

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

Мы уже почти год используем .Net Core для микросервисов и сервисов на продакшн. Пока сполшные плюсы. Та же возможность деплоить в линуксовых контейнерах сэкономила вполне ощутимую сумму.

Мы уже почти год используем .Net Core

25 серпня 2016 23:10
То есть где-то за год чуваки поправили основные «баги-ограничения-недостаток комьюнити»? Это гуд :)

А теперь серьезный вопрос:
F# можно нормально использовать НЕ под виндой? И в общем насколько удобно использовать F# с дотНетКор?

F# можно нормально использовать НЕ под виндой

Да, давно уже.

Насколько удобно использовать F# с дотНетКор

Также, как и с обычным дотнетом. В проекте вполне могут быть сборки как на F#, так и на C#.

Ответ на серьезный вопрос знает любой, кто знает основы дотнет...

Да, Core очень бурно развивается как с точки зрения продукта, так и комьюнити. Хотя в момент перехода и были некоторые опасения — не рановато ли (опыт разработчиков, возможные недоделки), но в случае микросервисов риски не такие уж большие — теоретически отдельный микросервис можно переписать за пару недель, а их у нас пока не так много. Основная часть продукта по прежнему на .Net Framework, но медленно дрейфует в сторону распила на микросервисы.

P.S. Я вижу, что некропост, но возможно кому-то интересно обсудить, как изменилась ситуация за пару лет.

Я вижу, что некропост, но возможно кому-то интересно обсудить, как изменилась ситуация за пару лет.

Так создайте тему на форуме с описанием актуального опыта

Возможно позже, когда полностью переведем всё запланированное на м/сервисы

EF Core 1.1 запланирован к концу года (+\-). Пока сомневающиеся раздуплятся, уже все произойдет.

Базовые фичи работают нормально. Для каких-то особых моментов (сложные/db-specific запросы, batch inserts/updates, load multiple record sets и т.д.), в дополнение к EF Core можно использовать напрямую интерфейсы ADO.NET и/или либы типа Dapper. Или вот мое: NReco.Data ^_^ (поддерживает schema-less data access)

в дополнение к EF Core можно использовать напрямую интерфейсы ADO.NET и/или либы типа Dapper. Или вот мое: NReco.Data
Использовать библиотеки доступа к данным, которые не поддерживают нормально linq, без веских на то причин??? Спасибо, не надо!

какие-то проблемы с SQL ? )) Dapper это библиотека доступа к данным, которую используют в StackOverflow, быстрая и эффективная. Запросы принимает в виде сырого SQL, но это нормально в performance-critical местах. Очень быстро маппит результат в POCO модели, в общем-то фишка этой либы.

Мое (NReco.Data) дополняет «обрезанный» ADO.NET в corefx, в котором больше нет DbDataAdater/DataTable/DataRow (а иногда нужно), и добавляет другие полезности:

  • Query — представляет абстрактный запрос (избавляет от SQL в коде), легко собирается в run-time, например для user-defined запросов или фильтров. Может парситься из строки, прикольных relex-выражений (их можно передавать как параметры в API, например). LINQ так не умеет :-)
  • RecordSet — легкая структура с API, похожим на DataTable/DataRow. В несколько RecordSet-ов можно вычитывать data reader с multiple result sets.
  • RecordSetReader — реализует дата-ридер по in-memory data rows.
  • DbCommandBuilder — генерирует select/insert/update/delete по Query, и поддерживает application-level data views
  • DbBatchCommandBuilder — композит несколько SQL-statements в одну DbCommand (востребовано при работе с cloud DB типа Azure SQL, где возможны задержки в десятки ms для исполнения одной команды)
  • DbAdapter — предоставляет очень простой API для круд операций с POCO, dictionary или RecordSet.

Такие либы можно использовать как основной DAL — может быть оправдано в небольших микросервисах/проектах, или где доступ к данным с особыми требованиями. Многие так и делают (ORM имеет своих противников, и не без причин).

Вообще не понял, чем напугало использование таких инструментов (при необходимости) в дополнение к EF Core целого Solution Architect (потому что в них нет LINQ ??). Это в EPAM-е полиси какое-то? )

Меня ничего нигде не пугало — просто немного удивило предложение использовать узкоспециализированные или самописные библиотеки, не поддерживающих современных инструментов языка в столь очевидном месте просто так «by default». Это также неэффективно в общем случае, как и, к примеру, оптимизация на уровне native windows API в типичном ентерпрайз приложении.
Раз уж я встрял, то напишу подробно.
Если коротко то проблем с raw sql 3:
— мейнтенанс: типичный кейс «а давайте переименуем колонку в БД». С последующим реплейсом по всему проекту
— перфоманс: люди пишут худшие запросы чем генераторы. Чисто статистически косяков больше.
— ранее обнаружение ошибок: с linq провайдерами множество типичных опечаток отлавливается на этапе компиляции. Так же в большинстве случаев они лучше юнит тестируются. Со строковыми запросами надо прогонять интеграционные тесты, что обычно занимает пару часов.
И никакой религии :)

или самописные библиотеки, не поддерживающих современных инструментов языка в столь очевидном месте просто так «by default».
linq to entities достаточно специфичный инструментарий, он не тянет на то, что называеться компонентом DAL by default, к тому же реализован он в ef так, что нарушает первичную идею использования linq как абстракции поверх sql — он использует повсеместно статические хелпери с вызовом нативных sql server функций в результате нутри базы торчат везде, где вы используете EF Linq и пишите запрос чуть более сложный чем «выбери мне продукты, где цена больше 5».
То что Linq провайдеры не входят в состав большинства ORM поверх ADO в .net — не случайность, а достаточно здравая закономерность — зачем тратить столько усилий на то, что привязано к конкретной бд, работает с косяками после стольких лет развития ef, как с точки зрения синтаксиса, так и с точки зрения производительности, к тому же и не поддается оптимизации в отличии от sql.
В целом я за использование EF Linq — это во многих случаях просто удобно, но не более и уже точно это не стандарт DAL в .NET в силу ограниченности, неочевидности и кривых абстракций нарушающих саму идею этих абстракций.
— ранее обнаружение ошибок: с linq провайдерами множество типичных опечаток отлавливается на этапе компиляции.
Опечаток в C#, ну да? А как насчет ошибок рантайма, когда с# method\operation not supported in sql?
Так же в большинстве случаев они лучше юнит тестируются. Со строковыми запросами надо прогонять интеграционные тесты, что обычно занимает пару часов.
Linq to entities запросы юнит тестируються? интересно как? вы анализируете дерево выражений или все-таки результат выборки из базы — это больше похоже на integration test? или вы тестируете linq to entities прогнав через enumerable коллекцию — тогда его лучше просто не писать.
он использует повсеместно статические хелпери с вызовом нативных sql server функций
EF далеко не идеален. За тот же Include авторам уже миллион раз спасибо сказали. Но вот других широко распространенных статических враперов я так навскидку и не вспомню.
где вы используете EF Linq и пишите запрос чуть более сложный чем «выбери мне продукты, где цена больше 5»
Да в общем то чуть более чем 90% запросов в типичной OLTP системе — это банальные фильтры, простые джойны и юнионы.
То что Linq провайдеры не входят в состав большинства ORM поверх ADO в .net — не случайность, а достаточно здравая закономерность
Очень и очень хм.... смелое заявление идущее в разрез с моим опытом. Даже больше: для всех сколько нибудь современных СУБД я без проблем находил linq провайдеров, чаще официальные чем нет.
Опечаток в C#, ну да? А как насчет ошибок рантайма, когда с# method\operation not supported in sql?
Так и есть. Значительный процент ошибок-опечаток отлавливается на этапе компиляции. Это не панацея, но реальный профит.
или вы тестируете linq to entities прогнав через enumerable коллекцию — тогда его лучше просто не писать.
Опять таки, это лучше писать в абсолютном большинстве случаев. Не смотря на все проблемы. Опять таки банально потому что большинство запросов к бд в типичном ентерпрайзе — простые.
Но вот других широко распространенных статических враперов я так навскидку и не вспомню.
msdn.microsoft.com/...lfunctions(v=vs.110).aspx
Даже больше: для всех сколько нибудь современных СУБД я без проблем находил linq провайдеров, чаще официальные чем нет.
официальных их несколько штук всего, остальное любительские реализации с несколькими сотнями загрузок — сомнительное решение для продакшина.
Но вот других широко распространенных статических враперов я так навскидку и не вспомню.
msdn.microsoft.com/...lfunctions(v=vs.110).aspx
О чем я и говорю — широкоиспользуемых ну совсем немного. А всякие Asin и CharIndex — ну ет явная экзотика.
официальных их несколько штук всего, остальное любительские реализации с несколькими сотнями загрузок — сомнительное решение для продакшина.
Ну вот навскидку, с чем приходилось сталкиваться:
ms sql
oracle
mongodb
my sql
имеют нативные драйвера. Еще есть серьезные коммерческие провайдеры типа devarts которые пишут альтернативные реализации. И это далеко не
любительские реализации с несколькими сотнями загрузок
О чем я и говорю — широкоиспользуемых ну совсем немного. А всякие Asin и CharIndex — ну ет явная экзотика.
Да, нахождение подстроки это экзотика вообще не встретишь.., вот еще пример экзотических запросов — выбрать каких-то сущностей ’за последние n дней’, ’truncate date’..
Что у вас за задачи на сиквеле если вам таких выборок не надо делать? вы совсем не работаете с таблицами фактов?
Ну вот навскидку, с чем приходилось сталкиваться:ms sql
oracle
mongodb
my sql
имеют нативные драйвера. Еще есть серьезные коммерческие провайдеры типа devarts которые пишут альтернативные реализации. И это далеко не
Отличная попытка из них официальных аж два: ms sql, mongo, для оракла — подделка, и для my sql коммерческий linq клиент. То что devarts, запилили linq провайдер для самой известной open source реляционки и начали его продавать за деньги еще раз подтверждает что все это далеко на стандартный функционал для DAL в .NET
Да, нахождение подстроки это экзотика вообще не встретишь.., вот еще пример экзотических запросов — выбрать каких-то сущностей ’за последние n дней’, ’truncate date’.
Большинство функционала реализуется без статических хелперов. Like через contains(да я в курсе про индексы, но обычно это именно то самое что клиент хочет). Where DateCreated < DateTime.Now.AddDays(-10) и так далее.
Я тебя уверяю, среднестатистический 23х летний сеньор именно так и сделает — и не факт что это плохо. :)
Отличная попытка
Еще раз по буквам: Для большинства сколько нибудь популярных СУБД есть либо официальные linq провайдеры либо коммерческие, которые можно спокойно брать в продакшн. С чем именно ты не согласен? В скобках отмечу, что наличие коммерческих linq провайдеров говорит о том, что фича востребованная даже за деньги.
То что devarts, запилили linq провайдер для самой известной open source реляционки
Лет 5 назад я использовал mysql провайдер под EF. Подумал похоронили — ан нет, вот он, бер и ипользуйся:
dev.mysql.com/...et-entityframework60.html
Так что с mysql мы имеем 2 как минимум 2 варианта для выбора.
С чем именно ты не согласен?
С тем что это стандартная часть DAL компонентов в .net. Это плюшка, которая продаеться как бонус, не более того.
Dapper например инструмент во многом сделанный намного более грамотно чем EF как ORM и он полностью покрывает потребности ORM не более того и работает в 4-6 раз быстрее EF. Именно поэтому его используют достаточно широко и никого не волнует отсутствие в нем Linq, а EF используют не потому, что там есть Linq, а потому, что это стандартный фреймворк от MS. То что в нем нет Linq провайдера не делает его менее привлекательным. Формально Linq это вообще внешний компонент по отношению к ORM, можно написать Linq провайдер и заменить raw sql на использование сервиса в своем репозитории. Linq to entities в целом очень опасная штука по многим причинам, нужно интуитивно понимать что может быть преобразовано в sql и в каком виде, а что нет — в последтвии это повышает уровень входа в технологию и требует знанения Sql особенно если это касаеться разумного его использования, а заканчиваеться тем, что люди не разобравшись до конца полностью отказываються в ORM только из-за того что их Linq работает медленно и они не знают как на это повлиять — очевидно же что он не панацея.
С тем что это стандартная часть DAL компонентов в .net.
Факты говорят об обратном. Ну да ладно.
Dapper например инструмент во многом сделанный намного более грамотно чем EF
Dapper — был сделан для конкретно взятого проекта в конкретно взятой высококвалифицированной команде с учетов конкретных специфичных требований. Естественно в тех сценариях работы, под который он проектировался, у него перфоманс лучше. Но тут необходимо понимать, что похожих задач и похожих команд не так много во всем мире и на украине их попросту нет. Поэтому не надо тащить микроскоп туда, где достаточно молотка.
что люди не разобравшись до конца полностью отказываються в ORM только из-за того что их Linq работает медленно и они не знают как на это повлиять
Ни разу не встречался с таким кейсом. А вот обратный, когда дата леер из хранимок-ручных запросов становится неуправляемым — можно сказать типичный случай.
Но тут необходимо понимать, что похожих задач и похожих команд не так много во всем мире и на украине их попросту нет.
Это совсем не так. Dapper простой и очень гибкий инструмент — покрывает типичные задачи ORM и поэтому его широко используют как разумная замена EF в том числе и на проектах в Украине.
Это же касается и других простых ORM поверх ADO.NET, в которых нету множества готовых плюшек и которые работают быстрее и гибче.
EF — имеет много готовых встроенных удобных решений lazy, changes tracking, navigation properties, linq, data migrations — плата за это отсутствие модульности, гибкости и производительность, сложности при отладке. Забавно — но В EF Core R1 это стало наиболее слабым местом настолько, что люди готовы переходить на Net 4.6 обратно только из-за нерабочего EF, зато Dapper работает нормально и под netcoreapp.
А вот обратный, когда дата леер из хранимок-ручных запросов становится неуправляемым — можно сказать типичный случай.
Там где SQL неуправляемый, LINQ просто работать не будет.
LINQ нельзя оптимизировать, а SQL можно как я говорил выше.
То что у вас работа с LINQ вызывает меньше проблем — для меня удивительно. Возможно специфика проекта, но в целом LINQ to Entities достаточно ограниченная технология для того что бы о ней говорить, как о спасении проектов где в БД происходит ад на SQL.
но в целом LINQ to Entities достаточно ограниченная технология для того что бы о ней говорить, как о спасении проектов где в БД происходит ад на SQL.
Смелое заявление. Из опыта своего и коллег, сникал в несколько проектов, перевод на linq которых, позволял существенно поднять и maintainability и performance. Из публичных, навскидку — rsdn, его переводили на новые рельсы, в том числе и linq2db(bltoolkit) и об полученных бенефитах писали в холиварах.
А ваще срач raw sql / linq уже вроде как отгремел (наверное везде кроме dou).

Зачем же народ юзает Dapper? Если LINQ (EF) should be enough for everyone. Проекты разные бывают, далеко не во всех основная сложность нафигачить тыщу формочек для тыщи энтитей, как можно быстрее.

Да в общем то чуть более чем 90% запросов в типичной OLTP системе — это банальные фильтры, простые джойны и юнионы.
Насчет 90 я бы поспорил, но явно больше половины.
Однако проблема в том, что на оставшиеся 10+ процентов вполне может уйти половина ресурсов команды. И где-то рядом волосы, встающие дыбом от того, что видишь в профайлере.
мейнтенанс: типичный кейс «а давайте переименуем колонку в БД». С последующим реплейсом по всему проекту
А нафига переменовывать то?
перфоманс: люди пишут худшие запросы чем генераторы. Чисто статистически косяков больше.
Люди, которые знают, как писать запросы, пишут их лучше.
Я не говорю про DB-разработчиков, достаточно просто человека, который умеет читать план запроса.
Так же в большинстве случаев они лучше юнит тестируются
Если не ошибаюсь, ты сам мне говорил, что подсовывать IEnumerable вместо IQueryable — порочный путь с кучей подводных камней.
. Со строковыми запросами надо прогонять интеграционные тесты, что обычно занимает пару часов.
Не утрируй. Времени на порядок меньше.
Хотя, конечно, геморней, чем юнит-тесты.
А нафига переменовывать то?

Вот это сразу fail. Когда на вопрос «а как сделать» отвечают «а вам этого не нужно» — смело бросайте гранату на звук ответа.

Люди, которые знают, как писать запросы, пишут их лучше.

Люди в принципе не могут писать запросы лучше. Точнее — они в теории могут, но на практике есть довольно большой класс задач типа «фильтрация по колонкам», где это будет «добро пожаловать в увлекательный мир построения запроса путём склейки строк» с runtime ошибками «sql error: invalid character at line 1»

Не утрируй. Времени на порядок меньше.Хотя, конечно, геморней, чем юнит-тесты.

Времени на порядок больше. В linq в подавляющем большинстве случаев запросы типа
context.Entity.Where(x=> (string.IsNullOrEmpty(nameParam) || x.Name.Contains(nameParam) && /* тут over 900 фильтров - знакомо, правда? */ ) 
можно не тестировать вообще. Нечего там тестировать, если только вы не адепт соломенных самолётов.
В случае с ручным построением запроса тестировать это нужно обязательно, причём по каждому фильтру(а в идеале — по всем им комбинациям, это «комбинаторный взрыв» называется, хихикс)

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

Архиткты пишут весьма мало продакшн кода. Они принимают технические решения, чтобы проект уложился бюджет и сроки, а не помер в процессе написания репозитариев, вместо запрошенного кастомером business value.

Это интересно, правда. Функциональная эффективность думающего senior программиста на C# как показывает практика и личный опыть повыше, чем на Java. Все таки большая стандартизация и ограничения помогают. Виртуальная машина быстрая и в Джаве и в Дотнете но писать быстрее на Си Шарпе.

Питон и Руби конечно гибкие языки но медленно работают. ДжаваСкрипт с нодом это маломаштабируемая игрушка. И с точки зрения производительности — добавлять слои это ад колбеков. И с точки зрения добавления программистов в проект — тут тот случай что чем больше людей тем хуже. Никто не держит весь проект в голове и начинается ад.

Кстати для тех кто говорит что нафига опенсорсный Дотнет если есть уже функциональные опенсорсные языки типа Скала. Я тоже был в захвате от Скалы. Когда попробовал написать что то больше чем хеллоу ворд с использованием существующих технологий — убил кучу времени. Все сырое и слабо поддерживается.

Но вот пример одного очень большого стартапа из Сан Франциско. Серверная разработка началась на Скала. Одна часть программистов начала писать в стиле Джава только Скала другая начала наворачивать чисто функциональный код напоминающий читающему послания умирающей цивилизации с Альфа Центавра. Через два года все резко перешли на — внимание — С Шарп на Моно. Все быстро переписали. Все счастливы.

Бывает и в стиле Scala, но на Java)

Функциональная эффективность думающего senior программиста на C# как показывает практика и личный опыть повыше, чем на Java.
«Думающий» синьор не написал бы подобный бред, так что есть вопросы к вашему личному опыту.
Проблема в том что язык определяет очень маленький процент в производительности, куда большая часть — это знание инструментов, еще большая часть — это «ментальная» совместимость.
ДжаваСкрипт с нодом это маломаштабируемая игрушка.
Нода довольно плохо (на сколько я знаю) масштабируется вертикально, поэтому горизонтальное масштабирование там довольно развито, что в современных условиях куда важнее. Нода не лучший выбор для тяжелых вычислений, но это другая проблема.
Серверная разработка началась на Скала. Одна часть программистов начала писать в стиле Джава только Скала другая начала наворачивать чисто функциональный код напоминающий читающему послания умирающей цивилизации с Альфа Центавра. Через два года все резко перешли на — внимание — С Шарп на Моно.
Как-то видел как бухой чувак упал с 5-го этажа на бетонные плиты, полежал немного, встал и пошел со словами «неплохо так».
Есть много статей где люди переходят с одной технологии на другую и получают «супер прирост» по всем параметрам. Проблема таких статей в том что они сугубо для кидания понтов.
Все быстро переписали.
Быстро это сколько? За сколько они переделали ту работу которую до этого делали в течении 2-х лет?
Если меньше чем за 1-1.5 года, то однозначно они просто хной маялись в течении 2-х предыдущих лет.
.
Основная мысль поста:
Проблема в том что язык определяет очень маленький процент в производительности, куда большая часть — это знание инструментов, еще большая часть — это «ментальная» совместимость.
Быстро это сколько? За сколько они переделали ту работу которую до этого делали в течении 2-х лет?
Если меньше чем за 1-1.5 года, то однозначно они просто хной маялись в течении 2-х предыдущих лет.
Нет не маялись. Было несколько итераций, многие части дописывались переписывались. На Моно портировали уже устоявшийся код.
«Думающий» синьор не написал бы подобный бред, так что есть вопросы к вашему личному опыту.Проблема в том что язык определяет очень маленький процент в производительности, куда большая часть — это знание инструментов, еще большая часть — это «ментальная» совместимость.

Личный опыт поверьте богатый. Я не имел в виду чистый C# и Java. Я сравнивал всю экосистему включая среду разработки, поддержку, стандартизацию и прочая. На Си Шарп выходит быстрее.
Хотя бы потому что не такого зоопарка, люди не маются херней на митингах какую выбрать библиотеку для какой то типичной задачи. А Visual Studio c Resharper удобнее среда чем IntelliJ. Ну вот как-то быстрей выходит блин...

Visual studio + reshaper это очень болезненная тема, когда большой проект приходиться разбивать на 5 и больше солюшина, что бы справиться с тормозами, по причине того что vs в 2016 году все ещё может быть собрана только под 32 битный процесс — это не выдерживает никакой критики, я бы вообще не называл vs хорошим продуктом.

Плюс большой вопрос, какого икс в студии до сих пор нет своего штатного и вменяемого аналога решарпера

Алэ яка розумная цьому альтэрнатыва? © :)

Нет не маялись. Было несколько итераций, многие части дописывались переписывались. На Моно портировали уже устоявшийся код.
Давайте определимся. Быстро — это менее полугода. Пока что вы не назвали ни дат, ни объемов, ни даже название большого стартапа.
На Моно портировали уже устоявшийся код.
От только фишка в том что писать новый код быстрее чем портировать (в смысле переписывать под возможности платформы, а не просто синтаксические конструкции менять). Проблема в том что при портировании у вас есть контракт, который не всегда известен на 100%, части документации могли потеряться и тд.
Личный опыт поверьте богатый.
Верить это такое. Давайте проверим.
11 лет судя по линкедину. Слово джава есть только в одном пункте, который длился 1 год + 1 месяц и при том в помеси с другими технологиями.
Пока что я вижу человека у которого 10+ лет дотНета и на фоне этого опыта несколько месяцев написания чего-то на технологии с которой он не особо знаком.
А Visual Studio c Resharper удобнее среда чем IntelliJ.
Круто IntelliJ удобнее чем IntelliJ :) От честное слово, посмотрите пункт «Основная мысль поста»

Круто, круто! Отличная статья, автору огромное спасибо
Поддерживаю, у asp core огромные возможности.
На своем примере могу сказать, что мы молодой стартап и уже опробывали эту технологии и написали онлайн игру meduzzza.io ))
Для стартапов самое оно! И по финансам и в плане разработки, а продуктивность вообще улютная, особенно это помогло нам в нашем проекте.

Никита, могли бы вы чуть детальнее поделиться, какие «плюшки» .NET Core наиболее способствуют продуктивности?

Привет, да конечно)
Например, Сокеты работают намного быстрее чем на старом asp да и в целом все расчеты, математические, сериализация быстрее).
Вот хороший пример и доказательство этому web.ageofascent.com/...llion-requests-12-6-gbps
Больше всего радость для меня была в том, что можно хостить приложения, отказавшись от iis который был относительно затратным по времени, даже с учетом всех максимальных настроек на нем.
Могу сказать, что скоро выйдет статья о asp core и нашем проекте. Там будет описано что поспособствовало высокой производительности и много других интересных моментов.. Уверен будет интересно и более полный развернутый обзор)

Только хотел войти в айти, а уже чтото новое появилось. Читать про core или, всё же, про .NET 4.6?

начать с C# 6.0 — точно не промахнешься!

Читать и про одно и про другое. Это взаимодополняющие проекты, а не взаимоисключающие. Классический .NET — для крупных проектов со сложной архитектурой. .NET Core — пока больше для небольших и экспериментальных проектов. Но базовые принципы у них одинаковые. Так что знания полученные при изучении любой из реализаций будут полезные и для другой.

Зависит от того, хочешь ты получать за свою работу деньги или нет. Если хочешь — читай про взрослый .NET. Если не хочешь — про Core и прочие наколенные поделки MS

rsdn.org:8888/...forum/dotnet/6531587.flat обсуждение как раз на ресурсе максимальных поклонников и апологетов дотнета.

Избранные цитаты:
«Там связь фреймворков как в индийских сериалах.»
«Поскольку движухи всё-таки не хватало, этой весной PCL и ко были заменены на .net standard, который по сути есть творческое переосмысление Android API Levels и у которого всего-то 6 версий плюс планы на „наконец-то мы сделаем правильно aka netstandard2.0“. По сравнению с 46 способами неправильно приготовить PCL — ниочём.»
«Всё отлично, кроме одной мелочи: сам .net core по-прежнему находится в полуразобранном виде, что тянет за собой кучу приключений как при попытке использовать сам .net core, так и в смежных проектах.
В основном мелочи типа „после обновления пакетов пустой проект перестаёт собираться“, но их количество и отсутствие решений не то что в гугле, но и в issues собственно .net core раздражает неимоверно :)»
«Напоминаю, что отношения между developer division, desktop и mobile div...» (картинка, где все всех нацелились отстреливать)
«Рантайм — нормально, базовые библиотеки — почти нормально, с инструментальной обвязкой и с совместимостью... для релиза это фейл. Но тут надо учитывать, что при старом добром подходе к разработке текущее состояние называлось бы CTP, даже не бетой, и вопросов никаких не было бы.»

Кроссплатформенность тоже, мягко говоря, сомнительная — всё мышление на основе Windows-специфичных костылей (как Unix-only, я их понимаю, но поддержать не могу).

только для серьезной разработки пока рано, слишком мало комьюнити.... :(

но очень хочется верит в успех этого проекта. если выгорит то пожалуй эта технология будет для меня новой предпочтительной вместо vanilla JS

Если нет блокеров, противопоказаний для использования .net core нет. С инструментами есть еще гм моменты (осенью ожидается релиз где уберут project.json и ускорят запуск\сборку и глюки VS, сейчас preview2), но сама платформа (рантайм, netstandard libraries) достаточно стабильна. Документация (скорее, туториалы) есть только для MVC Core и EF Core, по остальным вопросам надо ковырять самому (= читать сорцы на гитхабе). Также стоит помнить, что nuget пакеты для netcore-проектов устанавливаются и используются по-другому — хотя это нужно только тем, кто их собирает.

В качестве альтернативы, можно таргетить проект под .net 4.6.2 — будет доступен старый full .NET Framework и можно использовать как старые .net либы, так и новые netstandard (MVC Core, EF Core).

Кто хочет с нуля «вайти-в-дотнет», я бы посоветовал начинать именно с .net core. И С# 6.0 — он прекрасен :-)

Список полезных ссылок / библиотек совместимых с netcore: awesome-dotnet-core — там и мойо тоже есть :-).

От себя добавлю, что для многих вещей что «выпилили» из фреймворка, уже есть альтернативы в виде либ. Например, System.Net.Mail убрали — но замена даже лучше «оригинала»: MimeKit/MailKit.

Чего ощутимо не хватает: провайдера для Mysql (есть коммерческий, обещают что будет скоро официальный но что-то все никак), Open XML SDK тоже пока не имеет билда под netstandard, как и EPPlus. System.Xml.Xsl / System.Xml.Schema — отстутствуют, и вроде как адекватной замены пока нет.
System.Drawing — его также нет (и не будет похоже в обозримом будущем), пока все надежды на ImageProcessor (пока релиза нет).

За линк на awesome-dotnet-core спасибо! Форкнул в репозиторий сообщества. Насчет MySQL. Я для экспериментов пока использую вот этот провайдер: www.nuget.org/packages/MySqlConnector

System.Drawing
он вроде внутри как-то сильно с WinAPI связан. Хотя в думаю можно взять реализацию из Mono (там же вроде как есть? а то я так не помню) и при необходимости портировать.

кажется Mono Drawing сильно завязан на нативную либу libgdiplus (а она тащит еще депенденси) и что-то пока нет желающих собрать все это добро так, чтобы работало под всеми платформами (win, linux, osx).

ну winforms на моне таки работает, хотя и не без багов, для портирования тулзы всякой достаточно. а раз winforms работает, значит System.Drawing реализован достаточно кошерно
что же до работы под осХ — а кому там это надо?

"

что же до работы под осХ — а кому там это надо
"
Mono же работает под Mac OS X. Разве там не реализована поддержка WinForms? Я помню, мне даже удавалось запускать какой-то экспериментальный код WinForms под Mac OS.

И снова спрошу — и кому это может понадобиться?

Жизнь покажет :) .NET Core 1.0 на Linux c 3-x летней гарантированной поддержкой от Microsoft — это отличный ход. Разворачивается элементарно, и многие начнут с того, что добавят к существующему проекту небольшой микросервис на .NET Core — причем проект может быть на чем угодно (PHP/Ruby/Node/Java etc). Просто еще один докер контейнер, никаких Windows-серверов — девопсы не будут против.

По поводу отсутствия преимуществ, вброс засчитан.

И как оно, java streaming после linq? )) мне доводилось портировать либы с жабы на C#, и я искренне не понимаю, как можно сменить чудесный шарп на что-то из списка (жаба/питон/руби/пхп/нода) по своей воле. Вероятно дело в деньгах или может биг-дате / ML.

Если преимущества таки есть, то .нет коре пойдет в массы, верно? ) посмотрим.

з.ы. пишу на .нет с 2002-го, хотя уже тогда джава тоже была вся из себя стабильная и с кучей библиотек, а дотнет 1.0 с кучей костылей.

Нормально можно писать, java 8 — чуть урезанный C# 3.5, зато там есть Scala, которая по фичам давно С# 6, 7 ... обогнала.
А сам JVM по скорости пока равных не имеет (несмотря на отсуствие value-types)
Для high-load, machine learning, big-data альтернатив JVM пока нет.
Ну и самое главное — google, facebook, {whatever silicon value company} — сколько из них используют .net? там везде java

java 8 — чуть урезанные C# 3.5, зато там есть Scala, которая по фичам давно С# 6, 7 ... обогнала.
А как ты так меряешь?)
Ну и самое главное — google, facebook, {whatever silicon value company} — сколько из них используют .net? там везде java
по-моему ты все факты свои выдумал, в гугле полно дотнета, дотнет проектов от других компаний тоже горы; в фб разве кроме переписаного пхп что-то есть?

В фб есть кассандра, например

Изначально фейсбук, потом в апач передали. Распознавание морд на фотках тоже думаю, что не на пхп писано

Давайте разверну вопрос, что может предложить node, Python, etc. такого, чего нет в .NET? С другой стороны, .NET — это мультиплатформенная среда, которая позволяет на одном стеке создавать все: от десктопных до облачных приложений. Включая мобильные и встраиваемые решения. Ни питон, ни тем более нода такого не позволяют. О том, что в случае выбора ноды, вам придётся использовать JavaScript я уже молчу.

Абсолютно согласен, никаких преимуществ .net core на данном этапе нет, скорее наоборот: незрелая кроссплатформенность, незрелые инструменты разработки (под линуксом разрабатывать реально можно будет только когда выйдет Rider, VS Code не годится для чего-то большего, чем хелоу-ворд, project.json RIP и неясные перспективы с msbuild), незрелая экосистема (основные библиотеки переходят на него, но медленно).
И мало того, даже вакансий на .net core еще пару лет не будет.

Это такое самооправдание, чтобы не спрыгивать с теплого лампового .NET Framework, в котором уже как рыба в воде? :) сколько помню, такое происходит всегда, когда появляется новая технология: да сырая, да с багами, да без документации. После какого-то периода, все начинают хотеть «только это» (хайп), вне зависимости от того, есть ли реальные преимущества (как например было с ангуляром, или когда-то с Silverlight — это антипример, когда технология «не выстрелила»). Так же как WebForms сейчас только в легаси проектах, так и MVC5 / EF6 останутся только в легаси через пару лет.

Вакансии под ASP.NET Core уже есть (знаю минимум 3 конторы), в след году думаю лидеры рынка очнутся и начнется охота. Кто желает эх-прокатиться, разумно уже сейчас это все дело ковырять.

На мой взгляд, .NET Core существенно расширяет область применимости платформы: если раньше .NET юзали только плотно подсевшие на стек MS и Windows-сервера, сейчас нет никаких проблем добавить к PHP e-commerce .NET Core микросервис, на том же Linux сервере. Мне кажется, это крутотень :)

контейнеризация, возможность хоститься в произвольном облаке. Это то за что уже Энтерпрайз готов заплатить большие бюджеты и делать сложные распределённые системы на .net core. Как правило выбирают сейчас в таких случаях компромиссный вариант net4.6 + win + core совместимые фреймворка, например asp.net. Год два на стабилизацию платформы и переход большинства систем произойдёт уже на новую платформу, переход тем более в таком случае достаточно удобен.
Технологически .net удобней и проще чем jvm будет в этом случае, отсутствие библиотек под все единственный плюс Jvm насколько долго это преимущество протянет кто знает.

контейнеризация, возможность хоститься в произвольном облаке. Это то за что уже Энтерпрайз готов заплатить большие бюджеты
Че? Энтерпрайз? Накуя ваши хипстерские контейнеры и «произвольные» облака энтерпрайзу?
Я не отрицаю перспектив дотНетКора, особенно с учетом того что редхат делает движения (по крайней мере сейчас) в его сторону. Но двигателем будет явно не энтерпрайз.

Двигателем врядли, но Энтерпрайз уже научен достаточно опытом монструозных систем на старых проверенных технология где надо иметь мат степень что бы верно настроить работу gc и где вендоры просят за саппорт миллионы долларов в год и выхлопу в развитие 0. К моему удивлению они приходят з запросами давайте запилим чуть ли не на микросервисах компонентов для интеграции, а потом ещё и партнерским фирмам поставим это с нашим мобильным фронтом, а со временем выкинем монстров и будем иметь общие технологии на Бекенде и не платить миллионы за саппорт. Потом оказывается что такой партнёр и поставщик облачных сервисов как ibm тоже может предложить какие-то технологии для быстрого поиска и подружиться с .net ведь он хостит все в docker контейнерах. Так что думаю говоря о докере как хипстерской технологии вы либо немного лукавите, либо сильно привыкли к legacy технологиям.

за c# спецов можно платить намного меньше чем за тех кому что бы сделать аналогичный функционал с идентичным количеством кода на выходе надо освоить Java, groovy, Scala etc.

>>

.NET Core позволяет небольшим проектам и стартапам
>>
Node.js и Ruby — это небольшие проекты с ограниченным бюджетом и невысокой архитектурной сложностью.

В этом их схожесть. Нода на практике невозможна (по меньшей мере с Джава Скриптом без типизации) на больших сложных проектах. Руби получше но медленный. Магазин органического корма для собачек — пожалуйста. Система заказа билетов — извините нет.

Нет Кор уже сейчас позволяет небольшим проектам и стартапам насладиться возможностью писать на нормальных языках и уложиться с бюджет. Вскоре позволит Энтерпразу когда тот поймет уровень рисков.

ода на практике невозможна
вголос!
по меньшей мере с Джава Скриптом без типизации)
fyi для js є flow, для python є mypy, і тд. в чому трабла?)
Руби получше но медленный.
як дев може написати просто «получше» ?)
Система заказа билетов — извините нет.
вголос!
небольшим проектам и стартапам
стартапам, Карл!

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