Черезжопный метод это интерполяция строк через delete from nameof(Table)

Dapper не переусложняет код, этот тот же ADO, только с типизацией для ридера и интерполяции параметров в кверю, плюс он более легковесный и работает быстрее, потому что нет трансляции

Я в определённом контексте это говорил)) На чтение мы пользуемся даппером итак

@Liminiens тебе похуй какой таг будет у твоего докер имаджа?

2020 год а в еф нет deleteasync да и просто delete

Ну назови как репу хз

Он же реализует паттерн Unit Of Work, там by design удаление делается не напрямую в базе, а через накопление команд, а потом единоразовый Save.

Он же реализует паттерн Unit Of Work, там by design удаление делается не напрямую в базе, а через накопление команд, а потом единоразовый Save.

Дальше то, что у нас нет острой потребности писать излишне сложный код на который уходит больше времени чем на имплементацию того же через еф. Дальше-то что? Я не говорю что еф идеален и не говорю что он подходит везде и всегда, но айрат и влад в принципе не вели конструктивного диалога и в качестве проблемы привели наименьшую из проблем

Короче пацаны, я не говорю что еф идеален - у него куча минусов и он проседает по перфомансу, но говорить что им нельзя пользоваться - бред Есть задачи под которые он неплохо подходит

простейшие сервисы без нагрузки легко пишутся на даппере, к нему отличный linq провайдер, зачем тащить EF?

а непростейшие лучше уже руками сиквель писать. Заменять сиквель сишарпом вообще так себе идея

@aensidhe если вдруг как-нибудь получится какой-то кусочек примера реализации доменной логики и маппинга ее на бд показать - буду благодарен. Правда интересно было бы посмотреть

Ну я тоже фаулера читал) тут скорее что это реврайт старого ефа где должны были головой думать. Но нет

У линк2дб с имплементацией ддд были проблемы - сходу не вспомню, но при ресерче было видно что костылить приходилось Мб сейчас что-то поменялось

А из еф выпилили ,шоле, возможность плейн sql исполнять?

а как орм связан с ддд?

Удобство имплементации - в еф ты просто строишь агрегат на основе его энтити и используешь А за дал слой отвечает сам еф То есть ты в командах выполняешь действия на агрегате, а за мапинг на бд отвечает сам еф Короче глянь пример в книге мс про контейнерные приложения - у них там есть пример того о чем я говорю

Точнее не книга даже, а онлайн пример eShop или как-то так

Удобство имплементации - в еф ты просто строишь агрегат на основе его энтити и используешь А за дал слой отвечает сам еф То есть ты в командах выполняешь действия на агрегате, а за мапинг на бд отвечает сам еф Короче глянь пример в книге мс про контейнерные приложения - у них там есть пример того о чем я говорю

но аггрегат же это уже уровень бизнес логики, и там по-хорошему надо использовать отдельные модели, а не энтити переиспользовать. Не потому, что так "правильно", а пушто так действительно потом меньше гемора при изменении модели хранения или доменных типов

проблема в том, что модель хранения и доменная модель — это независимые вещи, и изменения в одной из них не должны вынуждать изменения в другой

Оригинальная бизнес-задача, которую вы собираетесь решить с помощью разработки, никакого отношения не имеет к тому, будете ли вы хранить данные в постгре, монге или кассандре, и уж тем более, как вы их оттуда будете доставать. А вот к тому, как выглядят ваши доменные типы, эта задача имеет самое прямое отношение

смотри, тогда у меня вопрос есть агрегат User например. у него есть какой-то набор энтити и вэлью обжектов есть команда в который вызывается ряд методов агрегате (setProfileData, setRegistrationAddress, calculateЧтотоТам) данные методы изменяют объект агрегата в памяти (тк слой бд отделен) вот есть команда которая вызывает Н разных метолов агрегата а после этого нужно сохранить все эти изменения в бд как это будет выглядеть на скл? как понять какие поля были выставлены итд

Ну я бы все это вообще отвязал от слоя персистентности. Ты с каким угодно способом достаешь данные из базы, потом собираешь из них доменный тип и уже над ним совершаешь изменения. Понять, какие именно изменения были сделаны, и какие из них надо сохранить в базу — задача доменного слоя. В доменном слое ты собираешь эти изменения и в свой дата слой передаешь уже тупо набор энтитей, которые просто надо сохранить

Ты точно читал что я написал?) я не знаю причин почему этого нет

что такое rich модель?

что делать с этими событиями и как их сохранять ты уже волен решать сам.

как вариант ага

но развязать его не будет сложностей при потребности

ну а я предлагаю как вариант использовать еф)) вполне жизнеспособный вариант которым многие пользуются хотя вариант с событиясм вполне ок - если начну использовать роу скл то реально о нем подумаю

да можно и еф как вариант, просто я не вижу, как еф или любой другой орм связан с ддд) Я про это спрашивал, а не про качество/ущербность еф

https://thedomaindrivendesign.io/anemic-model-x-rich-model/

рич модель не понравилась тем, что ИО гвоздями прибито к логике. И логика и ио — источники проблем и непоняток. Когда ты их так жестко смешиваешь вместе, разбираться с любой ошибкой становится экспоненциально сложнее. Это, впрочем, не значит, что рич модель нельзя организовать по-человечески, без энтитей и эпоксидки

почему аутично?)

ну оно непривычно для мира сишарпа, но практические бонусы очевидны. И тестировать проще (не надо ласкать моки перед каждым тесткейсом), и в случае ошибок логи читать проще и дебажить легче

@Liminiens для бота надо выставить privacy disabled чтобы он все сообщения в группе мог читать, да?