Pull to refresh

Comments 17

Тоже недавно портировал api на Core…
А Вы не используете механизм Delta< T > для update методов из Web API OData? Мне кажется без него жизнь-боль в условиях, когда клиенты шлют динамический набор полей входящего класса с обновленными значениями, и надо либо гемороиться с проверками какие поля таки надо обновлять, а какие null просто потому что их не прислали, либо использовать Delta< T >
Но в core версии Odata он всё еще поломан, и я крайне огорчён сим фактом ((


Eщё SignalR только в процессе портирования. Бета версия только есть… но минимум кое как работает.
EF7 немного поменялся синтаксис, но не критично. Остальное скопировалось копипастой и работает. Ради интереса запустил на убунте в том числе в связке с линукс версией MSSQL. Огонь ))

нет… ну а он решает именно задачу парсинга odata запросов, а меня интересовал специфический функционал поиска изменённых полей во входящем классе, просто каким-то чудом присутствующий в либе одаты майкрософта.
В любом случае я запостил баг о проблеме на гитхаб несколько недель назад, его недавно подтвердили и, надеюсь, скоро исправят

Как вы формируете patch запрос? Я использую Microsoft.OData.Client и он это не умеет.

при работе с классом Delta в запросе никакой необычности нет, обычный json


{"id":1,"firstName":"новое имя","lastName":"новая фамилия"}

дело только в принимающей стороне.


Update([FromBody] Delta<UserClass> req);

после этого в req будет спец объект, в котором будет помечено какие поля изменились, а какие не прислали. Он потом может сам пропатчить сущность


req.Patch(originalEntity);
инетересен опыт «в бою», вы вышли в продакшен? делали нагрузочное? как проект справляется? и какой ORM используете? как он себя ведёт. тоже «пилим» сейчас переезд на .net core

Ждите продолжение, там обязательно расскажем.

Всем угодил. NLog умеет в .NET Core 2, пока что живем с ним. Но, судя по опыту других наших проектов, интеграция Serilog с ELK происходит прозрачнее и уже успешно используется в production. А как у вас с этим дела?

Мы молимся на NLOG и я пока не вижу причины его заменять.

А в отношении сервисов, у нас все хуже, т.к. инфраструктуру проектировали лет 5 назад и всё написано на .NET. Есть куча WCF SOAP микросервисов, каждый под свои задачи. Все работают standalone, без IIS, как обычный Windows Service.

Вот, планируем отказываться от винды и перетащить всё на swagger с REST-ом в докере, поэтому и присматриваюсь к опыту переноса под NET Core. Но есть одна серьёзная проблема, есть сервис на который смотрят наши партнеры и там обязательно оставлять SOAP.
Попробуйте gRPC как замену WCF'у.

А зачем вам в связке Serilog + ELK нужен L?

Спасибо! Применительно к .NET ELK мы используем как условную аббревиатуру, Logstash там действительно нет.

В asp.net core так же используется web.config если приложение хостится под iis для настройки веб сервера и параметров запуска хоста — например environment.

Упустили самую интересную часть — как настраивали AD аутентификацию из под Linux контейнера. Kestrel бекенд сервер, это по сути обертка над с++ библиотекой сетевого i\o, веб сервером его с натяжкой можно назвать. Для него вроде есть что-то что работает под виндой с NTLM, но обычно всегда берут серьезный front-end сервер для этих задач c готовыми решениями — например iis или nginx под Linux, а их уже использует kestrel как reverse proxy.

Про kubrrnetes тоже интересно почитать, обычно в один контейнер запихивать все приложение и для этого брать оркестратор типа kubernetes вообще решение не много непонятное, к тому же если у вас on-premise решение, а не облако.

В проекте используется минимальное количество функционала IIS, поэтому по поводу расставания с ним у нас не возникло сомнений. При появлении необходимости будем брать фронтенд-сервер в соответствии с условиями. Какую то часть на себя возьмет Kubernetes (например, балансировщик).


По поводу AD — аутентификация происходит во внешнем для нашего решения сервисе, настройкой аутентификации в данном проекте не занимаемся.


Контейнеров будет несколько — основной мобильный сервис, сервис push уведомлений, сервис управлениями баннерами. Как раз про контейнеры подробно напишем в следующих статьях.

обертка над с++ библиотекой сетевого i\o
Небольшое уточнение, в .Net Core 2.1 Kestrel по умолчанию использует управляемые сокеты (managed sockets), libuv также можно использовать, установив ссылку на Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv тынц
Only those users with full accounts are able to leave comments. Log in, please.