Непонятки с DDD
Есть следующие классы: - вопрос: зачем переопределили 'public new ValueId<TIdType> Id' в AggregateRoot. EF дуреет.
public abstract class AggregateRoot<TId, TIdType> : Entity<TId> where TId : ValueId<TIdType> { public new ValueId<TIdType> Id { get; protected set; } protected AggregateRoot(TId id) { Id = id; } protected AggregateRoot() { } }
public abstract class Entity<TId> : IEquatable<Entity<TId>>, IHasDomainEvents where TId : notnull { private readonly List<IDomainEvent> _domainEvents = new(); public TId Id { get; protected set; } public IReadOnlyList<IDomainEvent> DomainEvents => _domainEvents.AsReadOnly(); protected Entity(TId id) { Id = id; } ... }
public abstract class ValueId<TId> : ValueObject { public abstract TId Value { get; protected set; } }
У вас архитекторы не пишут комментов к своему гениальному коду?
Чё это за хрень? В EF уже из коробки есть ORM, Repo, Unit of fucking work и ag... aghhh... aggregation root. Наф ещё чёто поверх городить? Руки чешутся пописать лапшу? ))
Чё это за хрень?
всего 9 мин. Или хотите Вон Верона и Эрика Эванса - там по часу
В EF уже из коробки есть ORM, Repo, Unit of fucking work и ag... aghhh... aggregation root
примерчик есть? Там совсем не то.
Чем транзакции не устроили? Собираете изменения по дереву сущностей с этим вашем корнем агрегации (главной сущностью), и сохраняете пачкой. У меня сейчас в приложухе начала 2000-х подобная же хрень происходит. Придумали какой-то домен, хотя всегда это была бизнес-логика (логика бизнес-процессов, для которых создавалось приложение) или ещё как-то. События какие-то у сущностей. Я как-то лет десять назад тоже событие написал у себя в классах бизнес-логики, типа на склад добавился товар - оповестить подписантов. Всё, у меня DDD. Придумали какие-то новые слова для старых вещей, чтобы со сцены дурачкам продавать. Все давно такие или подобные приложения писали, а тут нашлись чуваки, решившие продать старьё под чуть новым соусом.
Кто знает - работает, кто не знает - множит сущности, запутывает всё, а потом за деньги пытается распутывать - вобщем, зарабатывает на развешивании лапши на уши. Или вот ещё каждый выскочка, даже если ему повезло что-то сделать и он применил какой-то немного не такой подход, бежит навешивать своё имя на это и рассказывать, какой он гуру, и вот у него пачка платных курсов по этой теме.
Сами-то сможете сказать, где в вашем приложении и чем отличается model, domain, business logic и ещё хрен знает что? На собесах такие "назовите 10 отличий хрен-дривен от редька-дривен девелопмент (у меня в шпаргалке под столом так написано)" - "ля, чувак, я и двух не припомню, а ты целыми десятью себе голову забил!".
))
Чем транзакции не устроили?
У вас уже в БД всё промоделировано, а EF дал удобный интерфейс для конвергенции этих двух миров (ООП и БД). Берёте любой объект (таблицу) и сохраняете его изменения и всех их зависимостей по дереву связей как хотите, после чего всё пачкой сохраняете. Чего он там билдинг блокс делает какие-то, непонятно.
Лять, какая херня! А если мне не надо по всему приложению переопределять все возможные операторы сравнения для объектов, приписывать им уникальные айдишники (а что, с БД не устроили?) и прочее, а надо только для части объектво? Всё, у меня не DDD? Вот есть пачка замороченных объектов, я для них написал там все эти сравнения, отслеживание версий объекта и прочее. А для остальных - забил. Что у меня? DDD, MVC, TDD или химера?
А для остальных - забил. Что у меня? DDD, MVC, TDD или химера?
Зная ваши предпочтения, я бы вообще не рекомендовал это смотреть. Ведь всё от неверных или шаманов пытающихся продать свои сказки.
а что, с БД не устроили?
тут есть маленький ньюанс, что ид с БД приходят после создания объекта (записи объекта в базу)
вопрос: зачем переопределили 'public new ValueId<TIdType> Id' в AggregateRoot. EF дуреет.
А вот кто их знает... Чтобы подчеркнуть что это не ID объекта (Entity) а ссылка на Entity по ID?
Чтобы подчеркнуть что это не ID объекта
Тоже вот идей особых нет. При этом все агрегаты будут иметь одинаковый тип ИД, что вроде не очень хорошо.
И в самом первом видео такого нет, но помню есть еще одно. Скорее ради чего то другого изменили.
Но в данном случае, не имею понятия как написать конверторы для EF, особенно когда отношение много-много.
И не хочет еще что-то EF работать со ссылками на объекты (типа UserId), если есть в агрегате объект, то в таблицу пишет его ИД без проблем, а если в агрегате UserId, то пока не нашел способа записать также ИД для всех вариантов.
а что, с БД не устроили?тут есть маленький ньюанс, что ид с БД приходят после создания объекта (записи объекта в базу)
Ну будете вы генерить айди не там, где храните объект, а там, где создаёте. Смысл? Теперь у вас в БД будут либо таблицы без ключей, либо ключи без генерации, что вообще не свойственно для реляционных БД. Т.е. они как бы уникальные и ключи, но генерятся на стороне - т.е. БД по идее не должна их рассматривать как уникальные ключи, т.к. сгенерены не ей самой были - нет доверия, нужна валидация. Т.е. вводить уже на стороне БД проверку на уникальность при добавлении каждого нового объекта с ключом. А это лишние вычисления. Нахрена, если проще создать уже сразу в БД, которая и позаботится об уникальности?
Вот в моём проекте нет БД, я всё храню в файлах, поэтому и генерю айдишники на клиенте (серверной логики у меня тоже нет). Всё, у меня уже DDD? Правда, я его применяю, не бегая по сцене со своими умными лекциями.
Кстати, непонятно, зачем все эти перегрузки операций сравнения, если у вас есть айди на любой объект? Вам теперь достаточно сравнивать лишь айдишники.
Ну будете вы генерить айди не там, где храните объект, а там, где создаёте. Смысл?
хм, да действительно тяжело объяснить что земля круглая.
Хотя какое то время назад тоже не имел никаких проблем с генерацией ид на стороне базы. И в каких то случаях может и будет гораздо лучше, так как никакая архитектура не может быть одинаково хороша для всех проектов.
БД по идее не должна их рассматривать как уникальные ключи
как скажем так и рассматривает.
Кстати, говоря, очень толковые ответы попадаются.
И вопросы не обязательно задаются, что-бы получить на них объяснение.
Сам процесс формулирования вопроса и реакция на него может дать очень много полезного.
Иногда бывает, что уже на этапе формулирования вопроса видишь в чём проблема.