Comments 17
Тоже недавно портировал api на Core…
А Вы не используете механизм Delta< T > для update методов из Web API OData? Мне кажется без него жизнь-боль в условиях, когда клиенты шлют динамический набор полей входящего класса с обновленными значениями, и надо либо гемороиться с проверками какие поля таки надо обновлять, а какие null просто потому что их не прислали, либо использовать Delta< T >
Но в core версии Odata он всё еще поломан, и я крайне огорчён сим фактом ((
Eщё SignalR только в процессе портирования. Бета версия только есть… но минимум кое как работает.
EF7 немного поменялся синтаксис, но не критично. Остальное скопировалось копипастой и работает. Ради интереса запустил на убунте в том числе в связке с линукс версией MSSQL. Огонь ))
Не пробовали https://habrahabr.ru/post/319996/ ?
нет… ну а он решает именно задачу парсинга odata запросов, а меня интересовал специфический функционал поиска изменённых полей во входящем классе, просто каким-то чудом присутствующий в либе одаты майкрософта.
В любом случае я запостил баг о проблеме на гитхаб несколько недель назад, его недавно подтвердили и, надеюсь, скоро исправят
при работе с классом Delta в запросе никакой необычности нет, обычный json
{"id":1,"firstName":"новое имя","lastName":"новая фамилия"}дело только в принимающей стороне.
Update([FromBody] Delta<UserClass> req);после этого в req будет спец объект, в котором будет помечено какие поля изменились, а какие не прислали. Он потом может сам пропатчить сущность
req.Patch(originalEntity);Указанная выше библиотека OdataToEntity поддерживает стандартный OData path такого вида.
Всем угодил. NLog умеет в .NET Core 2, пока что живем с ним. Но, судя по опыту других наших проектов, интеграция Serilog с ELK происходит прозрачнее и уже успешно используется в production. А как у вас с этим дела?
А в отношении сервисов, у нас все хуже, т.к. инфраструктуру проектировали лет 5 назад и всё написано на .NET. Есть куча WCF SOAP микросервисов, каждый под свои задачи. Все работают standalone, без IIS, как обычный Windows Service.
Вот, планируем отказываться от винды и перетащить всё на swagger с REST-ом в докере, поэтому и присматриваюсь к опыту переноса под NET Core. Но есть одна серьёзная проблема, есть сервис на который смотрят наши партнеры и там обязательно оставлять SOAP.
А зачем вам в связке Serilog + ELK нужен L?
Упустили самую интересную часть — как настраивали 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 тынц
О чем не пишут в документации, или тонкости рефакторинга на .Net Core