Часто это показывает, что зависимости неправильно расставлены, и таким образом пытаются отстранится от инфраструктурных частей. От которых вообще не надо зависеть.
Вы тогда ограничиваете себя правилами кодогенерацией фреймворка. Код который нельзя править самому, ну не абсурд ли? Вот возьмите обычную задачу. Допустим там модель с 20ю полями и еще пара вложенных типов. Это сделать используя любое IDE и мультикаретку - пара минут. И нет никаких волшебст и зависимостей. Все. Вот он код. Захотел переименовал, захотел прописал еще что-то там.
Люди придумывают себе проблемы из ниоткуда. Все ваши фреймворки для маппинга приводят к проблемам. Это неявно, это сложно расширять правилами. Сложно найти то место где это магически сделано, используя простой переход к реализации. Экономите пару минут, но потом тратите неделю на фикс. Можно просто использовать, например, IConvert<TFrom, TTo>. И внедрять куда надо. Это никогда не сломается при переименовании или апдейте фреймворка. И это можно мокать, если есть на то потребность в тесте. Если IConvert лень часто внедрять, и моментное удобство дороже быстрого перехода к реализации, то можно обернуть а сервайслокатор, внедрить его и вызывать для всех маппингов (что по мне не перевешивает удобство перехода к реализации).
Что за навык "тестирование"? Вы тестировщик? Программирование состоит не только из локальных алгоритмов. Большая часть времени это организация архитектуры, рефакторинг и здравые решения, на одной внимательности вы не выедете, если вдруг у вас получится спагетти код который будет без ошибок. Бинарный поиск или быстрая сортировка не скажут вам как сделать не спагетти.
Да и это банально не интересно набивать алгоритмы вместо изучения интересных и полезных кейсов. Очнитесь.
Обобщение ради чего? Каждый тип требует набор методов "репозитория", это ограничение. Обобщения задуманы для реализации гибкости в архитектуре, тут этим и не пахнет. Репозиторий задуман чтобы отделить доменную логику от инфраструктурной, которая знает как сохранить объект. IQueryable это протечка через абстракции, так как он связан с конкретной реализацией и бд. Да и в целом "репозиторий" протек: инфраструктурные типы в ДТО.
Даже если забить на простейшую архитектуру и все лепить вместе, то это решение минимум не практично, объекты не бывают плоские, они ссылаются на другие и запросы бывают сложные. Сами программные модели не бывают такими простыми. Вы определили пару методов, добавили новый который не вписывается в ограничение и придется еще делать один репозиторий. Есть принцип: интерфейсы принадлежат клиентам. А у вас он тупое и беспощадное ограничение.
Не знаю как многие, но я сильно притормаживаю во время лайвкодинга, с возрастом наверно еще больше. А после него задачи решаю в голове за секунды. Думаю если разработчик не приспособлен к этому, то лучше избегать таких интервью, потому что появляется мысль о самозванстве. Ну и о вас сложится мнение как о плохом специалисте и не важно что вы знаете, что изучали и читали, как организуете архитектуру. Лучше оставьте лайвкодинг олимпиадникам, которые умеют это делать на рефлексах без подсказок ide.
Вы не похожи на того кто примет чью то ценности это раз. Два это, что "ценность статьи" у всех читателей своя. Три "ценность статьи" у вас не то же самое что и "зачем статья", потому что на "зачем" я уже однозначно ответил несколько раз, там не может быть разночтений.
Еще раз повторю, поскольку вы видимо не в состоянии прочесть сложное предложение, вам никто не обязан доказывать "ценность", даже если вы дадите свое определение ей, а у вас оно явно какое то свое.
Интересность текста определяется плюсами и дискуссией. Даже если статья неинтересна, как ваши заминусенные, это все равно не запрещает их тут размещать.
И прекратите флудить, если вас сильно что то задело, то обратитесь к администрации, возможно вам там помогут.
А какие у вас бывают они? Дайте классификацию и я отвечу вам
Статья не про компанию. Тематика не та.
Я вас не игнорю, на все был дан ответ, вопрос на ваш ответ тоже ответ.
Я сказал зачем, мне интересно мнение. Возможно кто то найдет еще какой то смысл в статье. Если вы не видите смысла в каких то статьях, то не читайте, минусуйте, это сообщество, а не платформа для лично вас. Перед вами отчитываться никто не должен, понимаете?
Если вы измените его, то следующая генерация кода его перезатрет.
Часто это показывает, что зависимости неправильно расставлены, и таким образом пытаются отстранится от инфраструктурных частей. От которых вообще не надо зависеть.
Вы тогда ограничиваете себя правилами кодогенерацией фреймворка. Код который нельзя править самому, ну не абсурд ли? Вот возьмите обычную задачу. Допустим там модель с 20ю полями и еще пара вложенных типов. Это сделать используя любое IDE и мультикаретку - пара минут. И нет никаких волшебст и зависимостей. Все. Вот он код. Захотел переименовал, захотел прописал еще что-то там.
Люди придумывают себе проблемы из ниоткуда. Все ваши фреймворки для маппинга приводят к проблемам. Это неявно, это сложно расширять правилами. Сложно найти то место где это магически сделано, используя простой переход к реализации. Экономите пару минут, но потом тратите неделю на фикс. Можно просто использовать, например, IConvert<TFrom, TTo>. И внедрять куда надо. Это никогда не сломается при переименовании или апдейте фреймворка. И это можно мокать, если есть на то потребность в тесте. Если IConvert лень часто внедрять, и моментное удобство дороже быстрого перехода к реализации, то можно обернуть а сервайслокатор, внедрить его и вызывать для всех маппингов (что по мне не перевешивает удобство перехода к реализации).
Да, можно было гуглить наверно. Чисто из любопытства спрошу, вы думаете я на сложные все нагуглил, а про лист не знал как гуглить?
Что за навык "тестирование"? Вы тестировщик? Программирование состоит не только из локальных алгоритмов. Большая часть времени это организация архитектуры, рефакторинг и здравые решения, на одной внимательности вы не выедете, если вдруг у вас получится спагетти код который будет без ошибок. Бинарный поиск или быстрая сортировка не скажут вам как сделать не спагетти.
Да и это банально не интересно набивать алгоритмы вместо изучения интересных и полезных кейсов. Очнитесь.
Вообще то мешает, общий ресурс время.
Лучше вечер потратить на прочтение полезной книжки про юнит тестирование например и багов станет меньше.
У вас нет доменных сущностей и домена, детали orm протекают через всё.
Ещё не надо давать вредные советы про мапперы, мапперы всегда создают проблемы.
Обобщение ради чего? Каждый тип требует набор методов "репозитория", это ограничение. Обобщения задуманы для реализации гибкости в архитектуре, тут этим и не пахнет. Репозиторий задуман чтобы отделить доменную логику от инфраструктурной, которая знает как сохранить объект. IQueryable это протечка через абстракции, так как он связан с конкретной реализацией и бд. Да и в целом "репозиторий" протек: инфраструктурные типы в ДТО.
Даже если забить на простейшую архитектуру и все лепить вместе, то это решение минимум не практично, объекты не бывают плоские, они ссылаются на другие и запросы бывают сложные. Сами программные модели не бывают такими простыми. Вы определили пару методов, добавили новый который не вписывается в ограничение и придется еще делать один репозиторий. Есть принцип: интерфейсы принадлежат клиентам. А у вас он тупое и беспощадное ограничение.
Не знаю как многие, но я сильно притормаживаю во время лайвкодинга, с возрастом наверно еще больше. А после него задачи решаю в голове за секунды. Думаю если разработчик не приспособлен к этому, то лучше избегать таких интервью, потому что появляется мысль о самозванстве. Ну и о вас сложится мнение как о плохом специалисте и не важно что вы знаете, что изучали и читали, как организуете архитектуру. Лучше оставьте лайвкодинг олимпиадникам, которые умеют это делать на рефлексах без подсказок ide.
Инфоциганство же
Много вредных советов.
Мне сказали руководитель.
Это идея
Ответ "нет" означает что вы не правильно понимаете и я могу дать вам ответ. Это никак не бьется с тем что я написал до и после.
Ответ "да" подходит, это что что вы пытаетесь вытащить вопреки здравому смыслу.
Отвечаю на upd:
Ответ "да" невозможен. https://habr.com/ru/articles/746144/#comment_25724802
Смешно то что "нет" не подходит к вашему вопросу.
Вы не похожи на того кто примет чью то ценности это раз. Два это, что "ценность статьи" у всех читателей своя. Три "ценность статьи" у вас не то же самое что и "зачем статья", потому что на "зачем" я уже однозначно ответил несколько раз, там не может быть разночтений.
Еще раз повторю, поскольку вы видимо не в состоянии прочесть сложное предложение, вам никто не обязан доказывать "ценность", даже если вы дадите свое определение ей, а у вас оно явно какое то свое.
Интересность текста определяется плюсами и дискуссией. Даже если статья неинтересна, как ваши заминусенные, это все равно не запрещает их тут размещать.
И прекратите флудить, если вас сильно что то задело, то обратитесь к администрации, возможно вам там помогут.
А вы буйный пациент однако.
А какие у вас бывают они? Дайте классификацию и я отвечу вам
Статья не про компанию. Тематика не та.
Я вас не игнорю, на все был дан ответ, вопрос на ваш ответ тоже ответ.
Я сказал зачем, мне интересно мнение. Возможно кто то найдет еще какой то смысл в статье. Если вы не видите смысла в каких то статьях, то не читайте, минусуйте, это сообщество, а не платформа для лично вас. Перед вами отчитываться никто не должен, понимаете?
В статье и в комменте ответил, слово "эйчар" что то говорит для вас?
В чем ценность вашего комментария?