Репутація українського ІТ. Пройти опитування Асоціації IT Ukraine
×Закрыть

ASP.NET Core: сырой ли он ещё?

Доброго времени суток форумчаны.

Собираюсь изучить этот движок, и так как это очень новая технология, интересует вопрос: он уже годится для enterprise разработок, или эта технология ещё сыроватая?

Спасибо!

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

если вдруг нужна болванка для докер имейдж билдера под dotnet core
github.com/...​dotnetcore-image-template

Кстати, для тех, у кого 1.0 и 1.1 в проде стоит MS сделали секурити апдейт github.com/...​t/announcements/issues/34.

Вроде как фикс нужен только если коре 1.х ранится под win10 или win2016 ? На убунте можно не заморачиваться )

У нас сайт в продакшене на .NET Core (еще 1.1) уже полтора года. Начинали пилить еще когда была бета.
Сейчас еще один проект в разработке уже под .NET Core 2.0.
Некоторые проблемы есть, но они не критичны. К тому же в 2.0 уже можно использовать и пакеты, которые собраны только под .NET 4.x и еще нет версий под .NET Standard.
Но, надо отметить, что у нас совсем не enterprise. Если в целом — надо смотреть по задачам. Если проект совсем новый — то однозначно рекомендуем.

Из реального опыта. аsp.net core 1.2 у нас на проде и все ок. Переходить на 2.х ветку будем наверное аж после нового года после релиза 2.1 версии, потому как:
а) 2.0 версия вышла вот буквально в августе и еще полностью не обкатана. Мы натыкались на баги, которые уже пофикшены в 2.1 пререлизе.
б) пока еще не все необходимые нам библиотеки были портированны на 2.x ветку
Из плюсов, что еще очень ждем. Это Signal-R, который пока в альфа версии для 2.х ветки. А так в целом — дела весьма и весьма неплохи. Основная идея была удешевления прода. Сейчас у нас как сайты, так и сервисы(демоны) крутятся под линуксом. Еще из опробованного хотелось бы отметить, что во второй ветке очень хорошо поработали с запуском кода на разных платформах. Теперь можно даже не замарачиваться с установкой фреймворка на линуксе, а просто включать его в ваш билд и ранить на разных дистрибутивах линукса (ценос\убунта\и т.д)

Доброе утро!

ASP.NET Core — не только готов для разработки, но уже активно используется на многих high-load проектах. На данный момент актуальная версия платформы — 2.0

Если интересуетесь разработкой под .NET Core — предлагаю присоединиться к .NET Core Ukrainian User Group:
— группа в фейсбук — www.facebook.com/groups/dncuug
— телеграм — telegram.me/dncuug
— сайт — dot-net.in.ua

В нашем комьюнити сможете получить всю интересующую вас информацию. Удачи в разработке!

Спасибо! то что хотел услышать — услышал)

Смысла разрабатывать на нем пока нет.
Сделать простой сайт чтобы он на линуксе пошел можно и на PHP. А для серьезного проекта нужны остальные .NET ништяки а это уже виндовая платформа. А если виндовая то особого преимущества core перед обычным фреймворком нет.

А для серьезного проекта нужны остальные .NET ништяки

Например, чего вам не хватало?

Технологии, ведь, не стоят на месте и можно найти хорошие альтернативы. Какая в вас задача? А если WCF ради WCF или существующий большой проект то, да, остается Full Framework.

Это просто пример.
Если писать с нуля — можно найти альтернативы.
Если код УЖЕ написан — то переписывать под Core может оказаться нецелесообразно...

Конечно, нужно анализировать. Тем не менее, если есть видение преимуществ, которые может привнести .NET Core можно мигрировать отдельные проекты (csproj) на .NET Standard и делать миграцию поэтапной там, где применимо (с этим, правда, тоже есть нюансы github.com/...​otnet/corefx/issues/23229 и связынные, youtrack.jetbrains.com/issue/RIDER-6961). А WFC сервисы можно хостить отдельно и обращаться к ним с .NET Core.

Это если не пытаться разобраться в сути вопроса

перед обычным фреймворком

«Наш стиральный порошок стирает лучше, чем обычный стиральный порошок»

В принципе, 1.1 фреймворк уже гуляет по продакшену и справляется со своими задачами. Перевод с обычного .net на core почти безболезненный (немного по другому конфижить Startup класс) Еще сложность (Не со стороны разработчика) это настроить билд агенты на CI с соответствующими тулами. А так, все ок

Зависит от проекта и используемые в нем апи. Далеко не все проекты заведуться под .net corе. Startup класс это для веба, в целом разница по нутрям, подходам к хостингу, используемым компонентам колоссальная. Если это веб enterprise проект, там почти всегда активно используются компоненты integrated pipeline модуля, тут всего этого нет и надо смотреть на наличие альтернативных компонентов, которые не всегда бесплатные многие апи просто безальтернативно отсутствуют. В целом под те задачи, что являются профильными для asp.net core можно и даже нужно взять. Но он пока ещё много чего не умеет из коробки по сравнению с платформой, много чего пока в стадии alpha разработки.

Если это веб enterprise проект, там почти всегда активно используются компоненты integrated pipeline модуля, тут всего этого нет и надо смотреть на наличие альтернативных компонентов, которые не всегда бесплатные многие апи просто безальтернативно отсутствуют

Middleware же

Там все заточено максимально под кроссплатформенность и azure. Быстрые и простые json-based решения, а не enterprise. Если для корп сети что-то более специфичное на чем мс специализировалось ранее ничего не поддерживается SAML токены, ws-*, любой xml, DTC, MMC ничего этого нет. И дело не в том что .net core сырой, просто мс для этого рекомендуют брать платформу.

SAML токены, ws-*

Вот пояаилось превью недавно так что скоро будет github.com/...​pnet/Security/issues/1473

любой xml

в 2.0 можно работать с XML.

DTC

стоит обходиться без него.

MMC

 хз что это.
Вообще .NET Core уже очень норм. Пока не сталкивался ни с чем, что на нем бы не работало.

А чи сильно впливає на розробку «недоношений» EF Core?

Вообще никак не влияет. Я им не пользуюсь. Но то, что пробовал работало нормально. Чего он недоношенный?

Немає TPT, TPC.
Не можна встановити зв’язок many-to-many без додаткової сутності.

Да, есть такое, но этими возможностями я даже в EF 6 не пользовался и считаю из скорее вредными. Если поектировать сущности как агрегаты в терминах DDD то наследование редко нужно и без нез него можно обойтись. А можно разделить структуру данных для сохранение и сам агрегат и сохранять так, как умеет EF.

Расскажи нам про свою любовь к EF6 и стенания из-за ущербности EF Core.

Вы специально перечисляете в EF все, что там следует запретить, а за использовние отстреливать руки?

Я якраз перерахував те, чого мені не вистачає порівняно з EF6.

Many-to-many это не фича ef, это один из перечня базовых способов как организовать хранение нормализированных данных в таблицах. Раньше ef это умел из коробки сейчас это надо делать руками. Кроме этого еф core имеет по сравнению с ef6 очень серьезные гепы в апи — например tracking changes для Navigation Properties он не умеет, не умеет делать group by и т.д. На текущи момент использовать можно, но еще очень сырой.

что там следует запретить, а за использовние отстреливать руки?

Что не так с TPT, TPC или TPH?

Очень громкое заявление. к тому же кому как не тебе знать о гепах технологии и ее специализации. :) подход если этого нет значит это не надо тоже интересный, но очень спорный — все гепы что есть сейчас в net core не потому, что это не надо, а потому что либо это пока не было времени сделать — чаще всего, либо с этим есть проблема для кроплатформенности. Хуже всего что весь net core пока сделан на максимально быстрых фундаментальных решениях, которые чаще всего неоптимальны совершенно, например отсутсвие нормальной реализации сетевого i\o, косяки дизайна работы с файловой системой под Unix и т.д.

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

А про

отсутсвие нормальной реализации сетевого i\o

я не слышал или не запомнилось, поделись ссылкой.

Я о том, что asp.net core не работает и не ставит целью иметь быстрый сетевой апи как часть .net core — вместо этого они взяли под копирку сделали веб сервер аналогичный node.js — взяли библиотеку на c++ и работают с сокетами через p\invoke ->
начало это еще на этапе разработки
github.com/...​strelHttpServer/issues/45
и сейчас по всей видимости они тоже отказались от идеи делать кросплатформенные реализации для большинства протоколов как часть .net core api
github.com/...​relHttpServer/issues/1980
github.com/...​relHttpServer/issues/1980

А, в этом смылсе. Ну, я не вижу в этом проблемы на столько критичной чтобы не брать .NET Core в разработку. Думаю там есть более приоритетные задачи по быстродействию. Может и к сокетам доберуться. Про Bedrock интересно, спасибо.

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