ASP.NET Core: сырой ли он ещё?
Доброго времени суток форумчаны.
Собираюсь изучить этот движок, и так как это очень новая технология, интересует вопрос: он уже годится для enterprise разработок, или эта технология ещё сыроватая?
Спасибо!
Богдан Зозуляк, Full stack .NET Core в Adsology Media Group
Facebook
Twitter
LinkedIn
Roman S
если вдруг нужна болванка для докер имейдж билдера под dotnet core
github.com/...dotnetcore-image-template
Андрей Литвинов
Кстати, для тех, у кого 1.0 и 1.1 в проде стоит MS сделали секурити апдейт github.com/...t/announcements/issues/34.
Vitaliy Fedorchenko
Вроде как фикс нужен только если коре 1.х ранится под win10 или win2016 ? На убунте можно не заморачиваться )
Sergiy Korzh
У нас сайт в продакшене на .NET Core (еще 1.1) уже полтора года. Начинали пилить еще когда была бета.
Сейчас еще один проект в разработке уже под .NET Core 2.0.
Некоторые проблемы есть, но они не критичны. К тому же в 2.0 уже можно использовать и пакеты, которые собраны только под .NET 4.x и еще нет версий под .NET Standard.
Но, надо отметить, что у нас совсем не enterprise. Если в целом — надо смотреть по задачам. Если проект совсем новый — то однозначно рекомендуем.
Take YourLife
Из реального опыта. а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 ништяки
Например, чего вам не хватало?
Eugene Kiba
Технологии, ведь, не стоят на месте и можно найти хорошие альтернативы. Какая в вас задача? А если 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.
Roman Olkhovsky
Это если не пытаться разобраться в сути вопроса
Sergii Kovalchuk
перед обычным фреймворком
«Наш стиральный порошок стирает лучше, чем обычный стиральный порошок»
Александр Шевченко
Oleksii Kraievyi
В принципе, 1.1 фреймворк уже гуляет по продакшену и справляется со своими задачами. Перевод с обычного .net на core почти безболезненный (немного по другому конфижить Startup класс) Еще сложность (Не со стороны разработчика) это настроить билд агенты на CI с соответствующими тулами. А так, все ок
Дмитро
Зависит от проекта и используемые в нем апи. Далеко не все проекты заведуться под .net corе. Startup класс это для веба, в целом разница по нутрям, подходам к хостингу, используемым компонентам колоссальная. Если это веб enterprise проект, там почти всегда активно используются компоненты integrated pipeline модуля, тут всего этого нет и надо смотреть на наличие альтернативных компонентов, которые не всегда бесплатные многие апи просто безальтернативно отсутствуют. В целом под те задачи, что являются профильными для asp.net core можно и даже нужно взять. Но он пока ещё много чего не умеет из коробки по сравнению с платформой, много чего пока в стадии alpha разработки.
Oleksii Kraievyi
Если это веб 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 уже очень норм. Пока не сталкивался ни с чем, что на нем бы не работало.
George
А чи сильно впливає на розробку «недоношений» EF Core?
Вообще никак не влияет. Я им не пользуюсь. Но то, что пробовал работало нормально. Чего он недоношенный?
Немає TPT, TPC.
Не можна встановити зв’язок many-to-many без додаткової сутності.
Да, есть такое, но этими возможностями я даже в EF 6 не пользовался и считаю из скорее вредными. Если поектировать сущности как агрегаты в терминах DDD то наследование редко нужно и без нез него можно обойтись. А можно разделить структуру данных для сохранение и сам агрегат и сохранять так, как умеет EF.
Artyom Krivokrisenko
Стив Джобс умер, но дело его живет
www.engadget.com/...-issues-youre-holding-th
Расскажи нам про свою любовь к EF6 и стенания из-за ущербности EF Core.
Elance Test
Вы специально перечисляете в 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 интересно, спасибо.
35 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів