Спасибо за комментарий! Всегда пожалуйста! Данная статья - критика варианта использования, который дан в абзаце, "Паттерн "Спецификация". Блеск", такой подход выдуман не мной, а позаимствован из статей наших зарубежных коллег. В целом со спецификациями выбор не велик: либо пишется nuget с спецификациями, описывающими наиболее сложные и часто используемые условия выборки данных на основе Expression, с возможностью их комбинации spec4 = spec1 & spec2 | !spec3, это сложно и оправдано только в сложных доменах. Либо второй вариант спецификации на основе IQueryable и выборками не намного сложнее, чем x => x.Id == someId . Спецификации будут эффективны только на очень сложных доменах.
Денис (мне кажется я общаюсь с Денисом, а не Андреем) добрый день! Да пример не совершенен как и его автор, но как мне кажется мысль о том, что ЕF может генерировать неэффективный SQL, если строит соединения только на основе навигационных полей, эта мысль кмк верная, я предложил путь как этого избежать и всё ещё пользоваться теми преимуществами, которые дарит "Спецификация". В любом случае спасибо за комментарий!
"А что в этом хорошего?" - "хорошесть" вынесения всей бизнес-логики в домен - величина переменная. Например, если Ваш продукт рассчитан на 3 года работы и не более, то можно обойтись монолитом или например, если Вы задумали уволится с этой галеры, и что с ней будет через 5-7 лет вам фиолетово, тогда, конечно, можно и на уровне инфраструктуры логику оставить. В противном случае, лучше потратить время и привести продукт к тому состоянию, когда смена любых инфраструктур не будет приводить к переписыванию логики - самой дорогой части Вашего решения. За 10 лет может и смена движка БД случиться. Примеры у Фаулера, Дяди Боба, Вона и других (да я ушёл от вопроса про примеры ибо лень). Надеюсь ответил на Ваш вопрос, в любом случае спасибо за него.:)
Если хорошо ложится, то не нужно никого никуда заменять :), но бывают случаи когда это необходимо сделать. Например после февраля 2022 некоторым фирмам приходится менять технологии доступа к данным по понятным причинам, и в этом случае проще будет тому, кто таки вынес всю бизнес-логику в домен.
Спасибо за комментарий! Всегда пожалуйста! Данная статья - критика варианта использования, который дан в абзаце, "Паттерн "Спецификация". Блеск", такой подход выдуман не мной, а позаимствован из статей наших зарубежных коллег. В целом со спецификациями выбор не велик: либо пишется nuget с спецификациями, описывающими наиболее сложные и часто используемые условия выборки данных на основе Expression, с возможностью их комбинации spec4 = spec1 & spec2 | !spec3, это сложно и оправдано только в сложных доменах. Либо второй вариант спецификации на основе IQueryable и выборками не намного сложнее, чем x => x.Id == someId . Спецификации будут эффективны только на очень сложных доменах.
Денис (мне кажется я общаюсь с Денисом, а не Андреем) добрый день! Да пример не совершенен как и его автор, но как мне кажется мысль о том, что ЕF может генерировать неэффективный SQL, если строит соединения только на основе навигационных полей, эта мысль кмк верная, я предложил путь как этого избежать и всё ещё пользоваться теми преимуществами, которые дарит "Спецификация". В любом случае спасибо за комментарий!
Посвятил UPD этой проблеме. Спасибо за коммент!
"А что в этом хорошего?" - "хорошесть" вынесения всей бизнес-логики в домен - величина переменная. Например, если Ваш продукт рассчитан на 3 года работы и не более, то можно обойтись монолитом или например, если Вы задумали уволится с этой галеры, и что с ней будет через 5-7 лет вам фиолетово, тогда, конечно, можно и на уровне инфраструктуры логику оставить. В противном случае, лучше потратить время и привести продукт к тому состоянию, когда смена любых инфраструктур не будет приводить к переписыванию логики - самой дорогой части Вашего решения. За 10 лет может и смена движка БД случиться. Примеры у Фаулера, Дяди Боба, Вона и других (да я ушёл от вопроса про примеры ибо лень). Надеюсь ответил на Ваш вопрос, в любом случае спасибо за него.:)
Если хорошо ложится, то не нужно никого никуда заменять :), но бывают случаи когда это необходимо сделать. Например после февраля 2022 некоторым фирмам приходится менять технологии доступа к данным по понятным причинам, и в этом случае проще будет тому, кто таки вынес всю бизнес-логику в домен.
Боюсь, если бы написал, что гибкость - это божественно, то было бы тоже самое. :)