Сложно представить такой сценарий в реальности. Обычно передашь везде один и тот же интерфейс ILogger и всё. Если говорить конкретно про логирование, то там можно конфигурацией определить, куда и что писать.
Кажется, вы пытаетесь выстрелить себе в ногу довольно странным и болезненным способом. Если вы хотите, чтобы сервис зависело от конкретной реализации, то положите эту реализацию явно в контейнер и задайте явно зависимость в сервисе. Если сервис зависит от некоторого общего интерфейса, то там может оказаться любая его реализация, и с этим надо жить. Даже если интерфейс имеет одинаковую сигнатуру, но его семантика отличается, то это два разных интерфейса, которые применяются в разных сценариях. Например, у вас есть интерфейс ICommand с методом Execute и есть потребность некоторые команды вызывать определённым единообразным образом через DI. В этом случае целесообразно было бы ввести интерфейс ISpecialCommand с тем же методом Execute и получать все реализации именно этого интерфейса, а не пытаться разобраться, что там за команда прилетела (может и не самый удачный пример с командами, но я думаю, суть ясна)
О да... На этом мы собственно и застопорились при внедрении API First. Если нельзя использовать генератор без напильника, то смысл автогенерации теряется совсем. Видимо придётся писать свои генераторы под свои потребности, потому что то, что позиционируется как официальные инструменты, не работает как надо. К этому добавляется не очень хорошая поддержка многофайловых схем в инструментах, а в одном файле все держать очень не очень
Вот понятия герои и баланс находятся максимально далеко друг от друга. На случайно сненерированных картах баланс невозможен, это не абсолютно симметричные карты турнирного варкрафта
Кажется, что тестовые контейнеры - это ваш выход. Тесты получаются независимые, запускаются в нативном окружении и лишены проблем с инфраструктурой. Всё, что надо сделать разработчику в Windows - включить wsl и поставить docker desktop, в линуксе все из коробки работает
Я бы рекомендовал оставить валидацию в том или ином виде (в debug-сборке или под каким-то флагом), чтобы можно было отлаживаться и получать более-менее вразумительные ошибки при генерации
Если генерить лист с большим количеством объединённых ячеек, то оно начинает тормозить. Причём чем больше объединённых интервалов, тем сильнее тормозит. Выход - объединять ячейки без валидации (если речь идёт именно о генерации файлов, а не о реализации обработки ввода пользователя). Отключение валидации на порядок ускоряет работу с объединённых диапазонами
Кто-нибудь может рассказать, зачем обязательное требование высшего образования? И как высшее образование в области какой-нибудь биологии и стаж там же например поможет работать в сфере ИБ без переподготовки?
Когда внезапно убрали банкомат из ТЦ, а понадобилась мелкая сумма наличными, то пришлось воспользоваться. Работает, но только вместе с какой-нибудь покупкой
Sqlite имеет некоторое количество особенностей поведения. Начиная от того, что создание базы через миграции падает и заканчивая многопоточными блокировками и прочими спецэффектами даже при работе в памяти.
Кроме того, эти субд всё же разные и иногда то, что работает в одном месте, не работает в другом. Так что в интенрационных тестах лучше, на мой взгляд, использовать те зависимости, с которыми проект будет жить в проде. Тем более, что сейчас для этого и делать почти ничего не надо
expand не помог потому, что там нет прямой связи между сущностями. В данном конкретном примере требовалась дополнительная логика по выборке данных из базы.
А функция не взлетела по следующей причине (вероятно, я ввёл в заблуждение слишком кратким описанием примера) : нам надо было, чтобы опция filter работала по одной сущности (пользователь), а другие опции (select/expand) - уже по возвращаем ой коллекции постов. Вот в такое одата не смогла, пришлось подставлять костыли
Используем OData в своих проектах. Что тут можно сказать - это боль и страдания, когда пытаешься сделать шаг влево-вправо. В базовом сценарии работает неплохо, но чуть сложнее - и всё, лютые костыли повсюду.
Пример: вернуть по запросу для одной модели другие модели (например, если фильтр по пользователям, а вернуть надо посты этих пользователей) - через одату мы это сделать так и не смогли, потому что по концепции Микрософта какая сущность в запросе, такая и в ответе.
Куча странного с версионированием api. Например, для v1 нормально работает get/{id}, а для v2 работает только get/{key}, потому что key - конвенционное имя. Это справедливо для 7 версии по крайней мере
Боль миграции - мы до сих пор не можем переехать на последнюю версию пакетов, потому что то одно, то другое отваливается в непредсказуемых местах...
Кроме того, что odata - это почти прямой интерфейс к БД, при котором вся ответственность за оптимальность запросов (если отбросить другие негативные аспекты этого) переложена на клиента и магию EF. Подозреваю (сами не пробовали), что всякие самописные запросы или хранимые процедуры выставить через одату будет тем ещё квестом, особенно с учётом всяких select/expand-опций.
В общем, на наших проектах мы стремимся отказаться от неё настолько, насколько это возможно, и использовать по минимуму. Для меня лично вырисовываются следующие приемлемые кейсы:
прототип API или сервиса, когда надо быстро достать данные из БД, а клиент ещё сам не до конца понимает, какие данные нужны (обычно после этого написанный API выкидывается и пишется пачка нужных методов)
ненагруженный API, который тем не менее должен иметь некоторую вариативность. Тут проще выставить OData-метод и смириться с тем, что запрос будет генерировать клиент
OData подкупает своей кажущейся простотой и отсутствием необходимости писать 100500 разных методов API с разными возвращаемыми данными, но "вдолгую" всё равно оказывается необходимым эти самые методы написать и под них оптимизировать запросы
И graphql в ту же область. Но odata ближе к sql
Сложно представить такой сценарий в реальности. Обычно передашь везде один и тот же интерфейс ILogger и всё. Если говорить конкретно про логирование, то там можно конфигурацией определить, куда и что писать.
Кажется, вы пытаетесь выстрелить себе в ногу довольно странным и болезненным способом. Если вы хотите, чтобы сервис зависело от конкретной реализации, то положите эту реализацию явно в контейнер и задайте явно зависимость в сервисе. Если сервис зависит от некоторого общего интерфейса, то там может оказаться любая его реализация, и с этим надо жить. Даже если интерфейс имеет одинаковую сигнатуру, но его семантика отличается, то это два разных интерфейса, которые применяются в разных сценариях. Например, у вас есть интерфейс ICommand с методом Execute и есть потребность некоторые команды вызывать определённым единообразным образом через DI. В этом случае целесообразно было бы ввести интерфейс ISpecialCommand с тем же методом Execute и получать все реализации именно этого интерфейса, а не пытаться разобраться, что там за команда прилетела (может и не самый удачный пример с командами, но я думаю, суть ясна)
О да... На этом мы собственно и застопорились при внедрении API First. Если нельзя использовать генератор без напильника, то смысл автогенерации теряется совсем. Видимо придётся писать свои генераторы под свои потребности, потому что то, что позиционируется как официальные инструменты, не работает как надо. К этому добавляется не очень хорошая поддержка многофайловых схем в инструментах, а в одном файле все держать очень не очень
Что, если не секрет, вы нашли в качестве альтернативы? Без сарказма, просто на ум приходит крайне малое количество альтернатив вроде vlc и gstreamer
oneof инструкция корректно поддерживается? Заметил, что всякая дичь генерится для нее
Вот понятия герои и баланс находятся максимально далеко друг от друга. На случайно сненерированных картах баланс невозможен, это не абсолютно симметричные карты турнирного варкрафта
А куда ногой? Проблемы больших организаций примерно одинаковы независимо от того, банк это или что-то
Кажется, что тестовые контейнеры - это ваш выход. Тесты получаются независимые, запускаются в нативном окружении и лишены проблем с инфраструктурой. Всё, что надо сделать разработчику в Windows - включить wsl и поставить docker desktop, в линуксе все из коробки работает
так и гугла с vpn капча со светофорами вылезает через запрос... из-за этого почти перестал их поисковиком пользоваться
Как-то так:
Я бы рекомендовал оставить валидацию в том или ином виде (в debug-сборке или под каким-то флагом), чтобы можно было отлаживаться и получать более-менее вразумительные ошибки при генерации
Если генерить лист с большим количеством объединённых ячеек, то оно начинает тормозить. Причём чем больше объединённых интервалов, тем сильнее тормозит. Выход - объединять ячейки без валидации (если речь идёт именно о генерации файлов, а не о реализации обработки ввода пользователя). Отключение валидации на порядок ускоряет работу с объединённых диапазонами
А в итоге мы имеем 5 штук разных агентов на машинах пользователей, которые жрут процессор, диск и сеть и мешают работать. Но ИБ свои KPI закрыли, да
Скайрим как он есть)
Кто-нибудь может рассказать, зачем обязательное требование высшего образования? И как высшее образование в области какой-нибудь биологии и стаж там же например поможет работать в сфере ИБ без переподготовки?
Когда внезапно убрали банкомат из ТЦ, а понадобилась мелкая сумма наличными, то пришлось воспользоваться. Работает, но только вместе с какой-нибудь покупкой
Sqlite имеет некоторое количество особенностей поведения. Начиная от того, что создание базы через миграции падает и заканчивая многопоточными блокировками и прочими спецэффектами даже при работе в памяти.
Кроме того, эти субд всё же разные и иногда то, что работает в одном месте, не работает в другом. Так что в интенрационных тестах лучше, на мой взгляд, использовать те зависимости, с которыми проект будет жить в проде. Тем более, что сейчас для этого и делать почти ничего не надо
expand не помог потому, что там нет прямой связи между сущностями. В данном конкретном примере требовалась дополнительная логика по выборке данных из базы.
А функция не взлетела по следующей причине (вероятно, я ввёл в заблуждение слишком кратким описанием примера) : нам надо было, чтобы опция filter работала по одной сущности (пользователь), а другие опции (select/expand) - уже по возвращаем ой коллекции постов. Вот в такое одата не смогла, пришлось подставлять костыли
Используем OData в своих проектах. Что тут можно сказать - это боль и страдания, когда пытаешься сделать шаг влево-вправо. В базовом сценарии работает неплохо, но чуть сложнее - и всё, лютые костыли повсюду.
Пример: вернуть по запросу для одной модели другие модели (например, если фильтр по пользователям, а вернуть надо посты этих пользователей) - через одату мы это сделать так и не смогли, потому что по концепции Микрософта какая сущность в запросе, такая и в ответе.
Куча странного с версионированием api. Например, для v1 нормально работает get/{id}, а для v2 работает только get/{key}, потому что key - конвенционное имя. Это справедливо для 7 версии по крайней мере
Боль миграции - мы до сих пор не можем переехать на последнюю версию пакетов, потому что то одно, то другое отваливается в непредсказуемых местах...
Кроме того, что odata - это почти прямой интерфейс к БД, при котором вся ответственность за оптимальность запросов (если отбросить другие негативные аспекты этого) переложена на клиента и магию EF. Подозреваю (сами не пробовали), что всякие самописные запросы или хранимые процедуры выставить через одату будет тем ещё квестом, особенно с учётом всяких select/expand-опций.
В общем, на наших проектах мы стремимся отказаться от неё настолько, насколько это возможно, и использовать по минимуму. Для меня лично вырисовываются следующие приемлемые кейсы:
прототип API или сервиса, когда надо быстро достать данные из БД, а клиент ещё сам не до конца понимает, какие данные нужны (обычно после этого написанный API выкидывается и пишется пачка нужных методов)
ненагруженный API, который тем не менее должен иметь некоторую вариативность. Тут проще выставить OData-метод и смириться с тем, что запрос будет генерировать клиент
OData подкупает своей кажущейся простотой и отсутствием необходимости писать 100500 разных методов API с разными возвращаемыми данными, но "вдолгую" всё равно оказывается необходимым эти самые методы написать и под них оптимизировать запросы