Ну, вообще, мне тоже интересен кейс частичной выборки, когда у нас не условный графкл, с которым ты можешь вообще все пропитать указанием ожидаемых полей и это даже будет нормально. На дто точно ориентироваться нельзя при выборке полей (ну, разве что косвенно), т.к., условно, бизнес-логика может работать с 10 полями и тремя связанными сущностями, а клиенту в дто прописано отдавать 6 полей и одну связанную сущность
Ну тут только опциональные поля делать т.к. разные типы дто не решат проблему на клиенте
Это просто вообще вопрос во всем ДДД, во всех примерах у нас есть класс бизнес сущности, ок, но там же эта сущность полностью вся читается из бд (той де орм), чтобы заполнить все свойства класса. А если мне для бизнес логики нужно только 1 поле? А если мне нужно обработать в цикле 1000 этих сущностей, прочитав только 1 поле? А если у меня документная бд а-ля монги и из огромного мегабайтного документа мне нужно пару полей? Хочу сэкономить трафик между бд и приложением?
Угу, думаю, чтобы красиво это построить, нужен отдельный слой с pick’ами от оригинальных сущностей. Если кто-то подкинет лаконичное решение - welcome :)
Почему не хочешь завести новую сущность из одного поля?
Будет Entity и EntityWithNameOnly?)))
Под каждый кейс пикать думаешь норм? Это как бы решение, как я и говорил, но сомнительное
Ну очевидно второе наименование менее удачно потому что потом надо будет извлекать ещё и дескрипшн
Ну если сознательно выбран такой подход и на простом скриптовом языке пишут как на жабе, очевидно, люди готовы идти по пути страданий
Что у сиквэл, что у монги есть возможность вытягивать определенные поля. Или вопрос касательно как сдружить классы в коде с учётом этого + дто?)
Ну когда сложность подходит к сложности средних задач на жабе, простой скриптовый язык немножк перестаёт быть простым. Проблема не в языке, а в инструментах и экосистеме. Сравнивая тот же спринг и нест - небо и земля. И в списке причин такой разницы пункт «у самого языка меньше возможностей» будет ближе к концу. Но не суть, речь же шла про кейс «доменная сущность на 500 полей, а я не хочу 500 полей, хочу 20, мне в моем кейсе больше не надо» 😅
Я не совсем понял при чем тут жаба
Понятно что можно вытянуть поля отдельные, вопрос философский, с точки проектирования
всегда есть вариант оставить простой язык, но распилить монолит :) мне не очень понятна проблема. Если сущности написаны так, то не могут построиться с двадцатью полями вместо пятисот, значит нужны новые сущности
Предполагаете просто только обязательные поля в конструктор пихать?
Скорее, нужно искать беду в архитектуре бд) мб там что-то наворотил
Бд нету) я абстрактную проблему придумал))
Ну так абстрактная бд с такими сущностями есть) значит в ней и проблема)
нет если ты строишь иерархию классов, то у тебя должен быть отдельный класс/интерфейс на такие случаи просто пиши много кода, в чём проблема 8)
Обсуждают сегодня