Обобщение ради чего? Каждый тип требует набор методов "репозитория", это ограничение. Обобщения задуманы для реализации гибкости в архитектуре, тут этим и не пахнет. Репозиторий задуман чтобы отделить доменную логику от инфраструктурной, которая знает как сохранить объект. IQueryable это протечка через абстракции, так как он связан с конкретной реализацией и бд. Да и в целом "репозиторий" протек: инфраструктурные типы в ДТО.
Даже если забить на простейшую архитектуру и все лепить вместе, то это решение минимум не практично, объекты не бывают плоские, они ссылаются на другие и запросы бывают сложные. Сами программные модели не бывают такими простыми. Вы определили пару методов, добавили новый который не вписывается в ограничение и придется еще делать один репозиторий. Есть принцип: интерфейсы принадлежат клиентам. А у вас он тупое и беспощадное ограничение.
Не знаю как многие, но я сильно притормаживаю во время лайвкодинга, с возрастом наверно еще больше. А после него задачи решаю в голове за секунды. Думаю если разработчик не приспособлен к этому, то лучше избегать таких интервью, потому что появляется мысль о самозванстве. Ну и о вас сложится мнение как о плохом специалисте и не важно что вы знаете, что изучали и читали, как организуете архитектуру. Лучше оставьте лайвкодинг олимпиадникам, которые умеют это делать на рефлексах без подсказок ide.
Чтобы тест выявил баги, он должен стать положительным после некой модификации тестируемого кода. Если у вас есть тесты и написанный код, то баг вам может только завести тестировщик, само просто наличие теста вам тут не поможет. Кроме того возможно я открою истину, но тесты тоже надо поддерживать.
По поводу оценки "редко" или "не редко" я вам тоже могу сказать что всё, что может пойти не так, пойдет не так, по закону подлости, эти суждения конкретно тут, конкретно к пованивающему коду на рефлексии применять не стоит.
Про то что кто то любит плохой код в виде не нужной рефлексии смысла говорить нет, поймет - исправиться, не поймет уже его проблемы.
А за вас кто то другой код поддерживает или вынужден поддерживать? Вы "настроили" что то там у себя путем написания кода, дальнейшие доработки или баги сами себя не исправят. Код который не требует поддержки это несуществующий код.
Принципы ioc повсеместны, где то они необходимы и облегчают жизнь, но это вас не обязывает делать так абсолютно все, остановитесь там где расширяемость и гибкость уже достигнута.
Это добавляет не явность, необходимость поддерживать рефлексию, ну и поиск по словарю. Считаю лучше внедрить то что необходимо, весь код буден понятен и у вас перед глазами, плюс удобная навигация. Понятно, что это не всегда подходит, иногда модели просто монструозные с вложенными типами (у такого кода как правило есть запашок), но если основном модель имеет много примитивов и парочку своих типов, то от пары внедрений в конструктор не убудет.
И вы правильно заметили про тестирование, простой интерфейс гораздо проще замокать.
Я иногда просто создаю IConvert<A,B>, минус в том что приходиться внедрять вложенные маппинги в конструктор, но то что код явный и на руках и его удобно отладить большой плюс. Появляется даже гибкость в особых случаях. И можно использовать языковые фичи которые в случает ioc подходов невозможны, когда фреймворк сам через рефлексии мапит.
Это не заменит чтение книг. Про solid в первую очередь это труды дяди боба, а не это. Например про S, что за задача? У класса несколько методов, каждый метод, очевидно, решает одну или несколько задач. Где границы какой то непонятной задачи? Тема гораздо глубже и касается причин которые могут затронут несвязанные бизнес задачи. Незнание этого приводит в запутанному коду, когда совсем разные причины затрагивают совсем несвязанные бизнес задачи соответственно. И такие блоки кода очень сложно распутывать и разделять.
Инверсия зависимости так же гораздо сложнее. Это не просто наплодил интерфейсики и внедрил реализации. Так же надо знать где определить пограничный интерфейс. И зачем в принципе тут уместно инвертировать зависимость? Чтоб бизнес логика не зависела от деталей реализации например.
Проблема блазора это не только то что надо писать каждый раз обвязки под js, а события. Есть 2 мира событий, те что в браузере из js, и те что в net, надо ловить одно и прокидывать дальше в net, и обратно. У меня на практике возникали бесконечные зацикливания, не говоря уже о тормозах. Мое личное мнение: ни какого профита в серьезных проектах, по сравнению с ангуляром.
Я вот предположил, что ничего, потому что Except должен вычитать множество (IEnumerable) правого аргумента из множества (IEnumerable) левого аргумента. Однако, вопреки моим ожиданиям я получил:
Лучше вечер потратить на прочтение полезной книжки про юнит тестирование например и багов станет меньше.
У вас нет доменных сущностей и домена, детали orm протекают через всё.
Ещё не надо давать вредные советы про мапперы, мапперы всегда создают проблемы.
Обобщение ради чего? Каждый тип требует набор методов "репозитория", это ограничение. Обобщения задуманы для реализации гибкости в архитектуре, тут этим и не пахнет. Репозиторий задуман чтобы отделить доменную логику от инфраструктурной, которая знает как сохранить объект. IQueryable это протечка через абстракции, так как он связан с конкретной реализацией и бд. Да и в целом "репозиторий" протек: инфраструктурные типы в ДТО.
Даже если забить на простейшую архитектуру и все лепить вместе, то это решение минимум не практично, объекты не бывают плоские, они ссылаются на другие и запросы бывают сложные. Сами программные модели не бывают такими простыми. Вы определили пару методов, добавили новый который не вписывается в ограничение и придется еще делать один репозиторий. Есть принцип: интерфейсы принадлежат клиентам. А у вас он тупое и беспощадное ограничение.
Не знаю как многие, но я сильно притормаживаю во время лайвкодинга, с возрастом наверно еще больше. А после него задачи решаю в голове за секунды. Думаю если разработчик не приспособлен к этому, то лучше избегать таких интервью, потому что появляется мысль о самозванстве. Ну и о вас сложится мнение как о плохом специалисте и не важно что вы знаете, что изучали и читали, как организуете архитектуру. Лучше оставьте лайвкодинг олимпиадникам, которые умеют это делать на рефлексах без подсказок ide.
Инфоциганство же
Много вредных советов.
капец, коммент годный был, хотел ответить с телефона...
А как вернуть случайно отклоненный комментарий?
С HttpClient так не надо
Да, вы меня не правильно поняли.
Чтобы тест выявил баги, он должен стать положительным после некой модификации тестируемого кода. Если у вас есть тесты и написанный код, то баг вам может только завести тестировщик, само просто наличие теста вам тут не поможет. Кроме того возможно я открою истину, но тесты тоже надо поддерживать.
По поводу оценки "редко" или "не редко" я вам тоже могу сказать что всё, что может пойти не так, пойдет не так, по закону подлости, эти суждения конкретно тут, конкретно к пованивающему коду на рефлексии применять не стоит.
Про то что кто то любит плохой код в виде не нужной рефлексии смысла говорить нет, поймет - исправиться, не поймет уже его проблемы.
А за вас кто то другой код поддерживает или вынужден поддерживать? Вы "настроили" что то там у себя путем написания кода, дальнейшие доработки или баги сами себя не исправят. Код который не требует поддержки это несуществующий код.
Принципы ioc повсеместны, где то они необходимы и облегчают жизнь, но это вас не обязывает делать так абсолютно все, остановитесь там где расширяемость и гибкость уже достигнута.
Это добавляет не явность, необходимость поддерживать рефлексию, ну и поиск по словарю. Считаю лучше внедрить то что необходимо, весь код буден понятен и у вас перед глазами, плюс удобная навигация. Понятно, что это не всегда подходит, иногда модели просто монструозные с вложенными типами (у такого кода как правило есть запашок), но если основном модель имеет много примитивов и парочку своих типов, то от пары внедрений в конструктор не убудет.
И вы правильно заметили про тестирование, простой интерфейс гораздо проще замокать.
Я иногда просто создаю IConvert<A,B>, минус в том что приходиться внедрять вложенные маппинги в конструктор, но то что код явный и на руках и его удобно отладить большой плюс. Появляется даже гибкость в особых случаях. И можно использовать языковые фичи которые в случает ioc подходов невозможны, когда фреймворк сам через рефлексии мапит.
deleted
Не, это точно не транзакция, у Фаулера как раз и сказано, что он, в том числе, нужен чтобы не держать транзакцию открытой. Это уже тема ближе к ДДД.
Это не заменит чтение книг. Про solid в первую очередь это труды дяди боба, а не это. Например про S, что за задача? У класса несколько методов, каждый метод, очевидно, решает одну или несколько задач. Где границы какой то непонятной задачи? Тема гораздо глубже и касается причин которые могут затронут несвязанные бизнес задачи. Незнание этого приводит в запутанному коду, когда совсем разные причины затрагивают совсем несвязанные бизнес задачи соответственно. И такие блоки кода очень сложно распутывать и разделять.
Инверсия зависимости так же гораздо сложнее. Это не просто наплодил интерфейсики и внедрил реализации. Так же надо знать где определить пограничный интерфейс. И зачем в принципе тут уместно инвертировать зависимость? Чтоб бизнес логика не зависела от деталей реализации например.
В обоих случаях.
Проблема блазора это не только то что надо писать каждый раз обвязки под js, а события. Есть 2 мира событий, те что в браузере из js, и те что в net, надо ловить одно и прокидывать дальше в net, и обратно. У меня на практике возникали бесконечные зацикливания, не говоря уже о тормозах. Мое личное мнение: ни какого профита в серьезных проектах, по сравнению с ангуляром.
Видимо, только вы один предположили это.