Как пример, в крупном контроллере может быть одна зависимость, которая сама тянет конфиги через сеть. Сломается одна зависимость и сломаются все endpoint, которые находятся в контроллере.
Или, нужно вывести enum на фронт, а для этого вы тянете 10 дополнительных зависимостей при каждом запросе.
Каждый решает сам, стоит оно того или нет, но мне подход с контроллерами напоминает подход с тяжеловесными сервисами по 20 методов, которые врятли когда-либо будут отрефакторены и навсегда останутся подвержены росту. И поэтому я использую Minimal Api на крупном проекте и доволен удобством
В C#, для создания сервисов инстанцируемых в контексте исполнения HTTP запроса, используются Transient services
До меня в команде был разработчик, который добавил DbContext как Transient и поверх этого использовались репозитории. Контроллер содержал в среднем по 5+ репозиториев.
В результате, при каждом обращении к точке доступа вместо одного контекста создавалось куча. Видел даже метод, где в результате было создано 20 контекстов, 19 из которых были не нужны.
Мораль басни такова, что в контексте исполнения HTTP запроса использовать надо не жизненный цикл Transient, а свою голову на плечах.
Извиняюсь, что не по теме, но меня немного припекает от того, что алгоритмы красно-черного дерева не пригодятся, но спрашивают про них. Неужели нельзя сформировать список из 50-100 вопросов из технологий, с которым непосредственно будет работать специалист и задавать часть из них?
Помню, как Авито просил меня доказать принадлежность мне аккаунта. Аккаунт был привязан к Gmail. Именно с этого Gmail я им и писал и всякими способами они вынуждали меня доказать, что аккаунт принадлежит мне.
В информатике есть только два сложных вопроса: инвалидация кэша и присвоение имен.
Добавлю третью проблему, которую практически никогда не решают правильно: удаление старых (неактивных) данных.
Чаще всего обходятся механизмом "soft delete", которая ведет к куче проблем с перепроверкой флагов и рекурсивной зависимостью других компонентов. Другой способ ("hard delete") тоже непростой, так как ты либо не можешь удалить элемент из-за FK, либо удаляешь элемент и все зависимые от него элементы с помощью каскадного удаления, которые не хотел бы удалять.
Сам использую подобный подход через задание Expression напрямую без излишнего велосипедостроения.
Только есть несколько моментов, которые надо учитывать:
1) ConstantExpression в примере автора приводит к тому, что запрос в EF Core не кешируется, поэтому лучше его не использовать
2) вместо операции "И" от EF Core можно написать собственные методы расширения Lambda Expression, которые смогут объединить операции "И" и "ИЛИ". Это может быть полезно, когда динамически строишь Expression без четкой модели запроса с именами параметров или в Entity-Attribute-Value. Тогда можно будет по частям строить предикаты и потом на отдельном этапе их объединить
А представьте, что к вам приходит бизнес и говорит, что Id у объекта Order должен быть int и определяться уже после запроса в БД, а вам нужно писать событие OrderCreatedEvent с указанием id созданного заказа. Плюс к тому же данные транзакции и событие должны писаться в рамках одной транзакции (outbox) и событие изменения должно публиковаться как интеграционный эвент вместо доменного. Плюс к тому же это интеграционное событие должно быть ответом на другое событие из какого-нибудь CorrelationId и указанием конкретной очереди, куда нужно писать и передачей некоторых параметров из прошлого события (например, того же CorrelationId), но указывать его надо не в тело сообщения, а в headers.
Я пользуюсь Тинькофф и мне всегда нравился Тинькофф. Но одна вещь меня просто поражает. В 2020 году я им предлагал добавить информацию обо всех устройствах, которые сейчас в сети с возможностью отключения им доступа. Идёт 2024 год, а такое походу и не планируется.
Хотя такой функционал присутствует чуть ли не у каждого более-менее популярного сайта. Да даже деревянный Сбер показывает авторизованные устройства, а вот Тинькофф - нет.
В статье много интересного для новичков, но не описан ещё один интересный подход. Заключается он в разделении логики ролей и разрешений (permission). У каждой роли могут добавляться, изменяться и удаляться разрешения. Каждому человеку можно прописать сколько угодно ролей.
В итоге каждая точка доступа сверяет разрешения текущего пользователя с необходимыми разрешениями, что даёт большую гибкость
Автор молодец. Ту же самую связку реализовал на C# через EF Core + библиотека SAP как функционал по сохранению и публикации событий. Всё также делается атомарно в рамках одной транзакции и сразу же публикуется после коммита. После публикации статус события меняется.
Когда речь идёт про безопасность, то сразу вспоминается ещё не принятый стандарт OAuth 2.1 или OIDC, который, исходя из моих знаний, реализует его на 99%, а может и на все 100%.
Там даже можно найти реализацию с HttpOnly cookie и BFF.
В Entity Framework Core созданная модель будет непосредственно зависеть от того указан или нет nullable reference type при включении поддержки nullable reference.
Это избавляет от необходимости каждый раз задавать IsRequired свойство в каждом EntityType и очень удобно.
Таким образом это как минимум один случай, когда правильное использование данной функции влияет непосредственно на код
Например, моя зарплата - 155 к, Middle ASP.NET Core разработчик. И в HH только и видишь отказ повсюду.
Если кто-то считает, что 400 к - это обычная заплаты, то готов сделать щедрое предложение такому бизнесу и поработать на них за 250 тысяч.
Как пример, в крупном контроллере может быть одна зависимость, которая сама тянет конфиги через сеть. Сломается одна зависимость и сломаются все endpoint, которые находятся в контроллере.
Или, нужно вывести enum на фронт, а для этого вы тянете 10 дополнительных зависимостей при каждом запросе.
Каждый решает сам, стоит оно того или нет, но мне подход с контроллерами напоминает подход с тяжеловесными сервисами по 20 методов, которые врятли когда-либо будут отрефакторены и навсегда останутся подвержены росту. И поэтому я использую Minimal Api на крупном проекте и доволен удобством
Тема
сисекпринципов работы докера не раскрыта. ЖальPgbouncer чем не устроил?
<Сами знаете что> скоро будут использовать даже дети с 6 лет. При этом есть куча инструкций на GitHub как установить <сами знаете что>.
Предлагаю команде хабра просто заменять <то, что нельзя называть из 3 букв> на <сами знаете что>.
До меня в команде был разработчик, который добавил DbContext как Transient и поверх этого использовались репозитории. Контроллер содержал в среднем по 5+ репозиториев.
В результате, при каждом обращении к точке доступа вместо одного контекста создавалось куча. Видел даже метод, где в результате было создано 20 контекстов, 19 из которых были не нужны.
Мораль басни такова, что в контексте исполнения HTTP запроса использовать надо не жизненный цикл Transient, а свою голову на плечах.
Извиняюсь, что не по теме, но меня немного припекает от того, что алгоритмы красно-черного дерева не пригодятся, но спрашивают про них. Неужели нельзя сформировать список из 50-100 вопросов из технологий, с которым непосредственно будет работать специалист и задавать часть из них?
Помню, как Авито просил меня доказать принадлежность мне аккаунта. Аккаунт был привязан к Gmail. Именно с этого Gmail я им и писал и всякими способами они вынуждали меня доказать, что аккаунт принадлежит мне.
Чудики.
Добавлю третью проблему, которую практически никогда не решают правильно: удаление старых (неактивных) данных.
Чаще всего обходятся механизмом "soft delete", которая ведет к куче проблем с перепроверкой флагов и рекурсивной зависимостью других компонентов. Другой способ ("hard delete") тоже непростой, так как ты либо не можешь удалить элемент из-за FK, либо удаляешь элемент и все зависимые от него элементы с помощью каскадного удаления, которые не хотел бы удалять.
Сам использую подобный подход через задание Expression напрямую без излишнего велосипедостроения.
Только есть несколько моментов, которые надо учитывать:
1) ConstantExpression в примере автора приводит к тому, что запрос в EF Core не кешируется, поэтому лучше его не использовать
2) вместо операции "И" от EF Core можно написать собственные методы расширения Lambda Expression, которые смогут объединить операции "И" и "ИЛИ". Это может быть полезно, когда динамически строишь Expression без четкой модели запроса с именами параметров или в Entity-Attribute-Value. Тогда можно будет по частям строить предикаты и потом на отдельном этапе их объединить
А представьте, что к вам приходит бизнес и говорит, что Id у объекта Order должен быть int и определяться уже после запроса в БД, а вам нужно писать событие OrderCreatedEvent с указанием id созданного заказа. Плюс к тому же данные транзакции и событие должны писаться в рамках одной транзакции (outbox) и событие изменения должно публиковаться как интеграционный эвент вместо доменного. Плюс к тому же это интеграционное событие должно быть ответом на другое событие из какого-нибудь CorrelationId и указанием конкретной очереди, куда нужно писать и передачей некоторых параметров из прошлого события (например, того же CorrelationId), но указывать его надо не в тело сообщения, а в headers.
Вот тогда ваш подход начнет ломаться.
Я пользуюсь Тинькофф и мне всегда нравился Тинькофф. Но одна вещь меня просто поражает. В 2020 году я им предлагал добавить информацию обо всех устройствах, которые сейчас в сети с возможностью отключения им доступа. Идёт 2024 год, а такое походу и не планируется.
Хотя такой функционал присутствует чуть ли не у каждого более-менее популярного сайта. Да даже деревянный Сбер показывает авторизованные устройства, а вот Тинькофф - нет.
В статье много интересного для новичков, но не описан ещё один интересный подход. Заключается он в разделении логики ролей и разрешений (permission). У каждой роли могут добавляться, изменяться и удаляться разрешения. Каждому человеку можно прописать сколько угодно ролей.
В итоге каждая точка доступа сверяет разрешения текущего пользователя с необходимыми разрешениями, что даёт большую гибкость
Вот только я с 1.8 года корпоративного опыта на 9/10 резюме получал отказ. При этом ЯП - C#. Так что ставлю его заявление под сомнение
Если хочется делать гибкие выборки с сортировки и/или поиском, то не лучше ли для этого использовать уже готовые решения как OData?
Плюс к тому же есть немало статей, где описывается, что Paging через Offset сильно нагружает БД.
Автор молодец. Ту же самую связку реализовал на C# через EF Core + библиотека SAP как функционал по сохранению и публикации событий. Всё также делается атомарно в рамках одной транзакции и сразу же публикуется после коммита. После публикации статус события меняется.
Когда речь идёт про безопасность, то сразу вспоминается ещё не принятый стандарт OAuth 2.1 или OIDC, который, исходя из моих знаний, реализует его на 99%, а может и на все 100%.
Там даже можно найти реализацию с HttpOnly cookie и BFF.
Самозанятого с официально прописанным контрактом с указанием области работ в сфере программирования могут взять или нужен именно договор работы?
И, судя по их законам, без высшего образования обязателен уровень немецкого B1 и выше. Насколько это требование важно?
Вы еще Озон с Вайлдберрис не парсили без официального API. Чувствуется, что я нанялся Шерлок Холмсом, а не программистом
В Entity Framework Core созданная модель будет непосредственно зависеть от того указан или нет nullable reference type при включении поддержки nullable reference.
Это избавляет от необходимости каждый раз задавать IsRequired свойство в каждом EntityType и очень удобно.
Таким образом это как минимум один случай, когда правильное использование данной функции влияет непосредственно на код