F12 это тоже проблема конечно, но меня больше смущает, что результат выполнения этого метода никому кроме моего бизнес-кода в этом конкретном методе и не нужен — зачем его выделять в отдельную сущность.
Ну вот есть у вас сложный запрос — он уходит в репозиторий, его теперь не видно из кода бизнес-логики… а в нем почти вся суть метода. А его ведь еще и протестировать нужно. И для чего мне тогда разделять их?
Подход не очень распространен — нет решений, чтобы просто взять и начать тестировать. Все приходится собирать самому по кусочкам. Это и была попытка сделать решение работающее из коробки с рекомендациями как построить процесс для максимально простого тестирования.
Отличная библиотека! От ее полноценного использования останавливает только наличие миграций в EF. Не знаете есть ли что-то приличное для миграций с linq2db?
Непонятно за что минусуют, все по делу. Добавлю от себя: непонятно зачем web-фреймворку orm с трэкингом состояний… это же stateless среда. От этого никакой пользы нет, только оверхэд.
Увеличение уровней абстракции не факт, что ведет к уменьшению сложности. А очень даже наоборот — вам теперь нужно помнить как работают две сущности и их взаимодействие вместо одной.
Попробуйте пописать на python — довольно неплохо прочищает мозги. Мне C# милее в сотню раз, но свой отпечаток питон оставил.
Да, не разделять их. Иногда это полезно, иногда нет. Я слышу про отделение базы только в контексте двух сценариев: тестирование и гипотетическая смена базы в будущем. Первое можно готовить и по другому, а второе похоже на раннюю оптимизацию.
Иногда полезно разделить бизнес-логику и обращение к данным. Это оправданно с точки зрения потока данных, алгоритмов — и я не имею к этому никаких претензий. Это может быть оправданно даже с позиции тестов — если вам их надо прогнать тычячи. Но этому есть своя цена и надо знать, что есть и альтернативы.
Меня бы полностью удовлетворила такая формулировка: есть подход А и Б, вот их плюсы и минусы, решайте, что вам дороже обойдется. К сожалению часто звучит "есть только А, остальное ересь" и это напоминает картинку про PNG и JPEG.
Читал, и наверное его читали создатели Ruby on Rails, Django, Yii2 и тем не менее выбрали эту схему. Я могу привести мнение DHH (создателя RoR), но может быть лучше не авторитетами давить, а аргументированно критиковать?
И еще раз — я не против DI как такового… я про то, что это часто избыточно.
Отличная книга! Кому лень читать (а прочитать стоит!) есть короткое видео с автором книги:
Потому что меньше кода, он лучше локализован, тесты максимально приближены к реальной системе (никаких моков) — создал за 10 минут сценарий и погнали.
Можно, если ничего в базу писать не будете. Лишние заморочки...
Ну вот приехали… то есть бывают случаи когда проще применить интеграционный тест?
Оно работает не в том смысле, что тесты загораются зеленым и красным. А в том, что достигается тот же и даже больший эффект меньшими усилиями.
F12 это тоже проблема конечно, но меня больше смущает, что результат выполнения этого метода никому кроме моего бизнес-кода в этом конкретном методе и не нужен — зачем его выделять в отдельную сущность.
И каким же?
То, что за пределами нашего привычного опыта тестируют по другому. И это работает и довольно неплохо.
Ну вот есть у вас сложный запрос — он уходит в репозиторий, его теперь не видно из кода бизнес-логики… а в нем почти вся суть метода. А его ведь еще и протестировать нужно. И для чего мне тогда разделять их?
Все верно, посыпаю голову пеплом… Исправлю в статье.
Подход не очень распространен — нет решений, чтобы просто взять и начать тестировать. Все приходится собирать самому по кусочкам. Это и была попытка сделать решение работающее из коробки с рекомендациями как построить процесс для максимально простого тестирования.
Отличная библиотека! От ее полноценного использования останавливает только наличие миграций в EF. Не знаете есть ли что-то приличное для миграций с linq2db?
Непонятно за что минусуют, все по делу. Добавлю от себя: непонятно зачем web-фреймворку orm с трэкингом состояний… это же stateless среда. От этого никакой пользы нет, только оверхэд.
Увеличение уровней абстракции не факт, что ведет к уменьшению сложности. А очень даже наоборот — вам теперь нужно помнить как работают две сущности и их взаимодействие вместо одной.
Попробуйте пописать на python — довольно неплохо прочищает мозги. Мне C# милее в сотню раз, но свой отпечаток питон оставил.
Да, не разделять их. Иногда это полезно, иногда нет. Я слышу про отделение базы только в контексте двух сценариев: тестирование и гипотетическая смена базы в будущем. Первое можно готовить и по другому, а второе похоже на раннюю оптимизацию.
Иногда полезно разделить бизнес-логику и обращение к данным. Это оправданно с точки зрения потока данных, алгоритмов — и я не имею к этому никаких претензий. Это может быть оправданно даже с позиции тестов — если вам их надо прогнать тычячи. Но этому есть своя цена и надо знать, что есть и альтернативы.
Зато при программировании и поддержке цифры меняются местами… там конечно, не будет отличия на порядок, но и время там подороже стоит.
Меня бы полностью удовлетворила такая формулировка: есть подход А и Б, вот их плюсы и минусы, решайте, что вам дороже обойдется. К сожалению часто звучит "есть только А, остальное ересь" и это напоминает картинку про PNG и JPEG.
Читал, и наверное его читали создатели Ruby on Rails, Django, Yii2 и тем не менее выбрали эту схему. Я могу привести мнение DHH (создателя RoR), но может быть лучше не авторитетами давить, а аргументированно критиковать?
И еще раз — я не против DI как такового… я про то, что это часто избыточно.
Спасибо! Я попробую эти варианты!