Re[7]: Что если не разделять строго dto, entity, bo...
От: Qulac Россия  
Дата: 29.11.25 17:21
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Qulac, Вы писали:


Q>>Здравствуйте, gandjustas, Вы писали:


G>>>Здравствуйте, Qulac, Вы писали:


Q>>>>Если это не про игры или какие ни будь с заказным навороченным дизайном — то это говорит о том, что кто-то как-то не правильно все делает.

G>>>Почему неправильно? Любой ui это много элементов и взаимодействий, а логика гораздо проще, ибо код stateless, а все «состояние» находится вовне.

Q>>Если вы используете какую ни будь хорошую библиотеку для ui, то все практические превращается в банальное формошлебство — т.е. соединение одного с другим. Это если правильно делать. Приведу пример из практики как не правильно. Дано: штук 5 справочников к которым нужно приделать новый фронт на реакт + добавить возможность редактирования. Все уже для этого есть и компонеты и дизайн. Казалось бы делай вот так:


Q>>1. Получили из апи данные справочника

Q>>2. Загрузили из другого апи данные выпадающего списка
Q>>3. Отправили на апи результат из диалоговой формы
Q>>4. Перешли к другому справочнику
G>То есть предлагаете копипастить кучи кода?

Тут в копипастинге нет ни чего плохого, потому что это не приводит к проблемам. В конце концов есть наследование, можно его использовать.

G>А что делать на нетривиальных формах?

G>- кода видимость/обязательность одних элементов зависит от значен у других?
G>- когда используются справочники, в том числе каскадные ?
G>- когда а одной форме есть mater-detail и логика работающая на всех detail записях?

Что делать, писать код.

G>На стороне бл это простое дерево объектов: получили, обновили из запроса, записали в базу.

G>А на стороне клиента это тонна логики

Q>>На фронтенду захотелось сделать универсальный для таких случаев способ, т.е. что бы один запрос возвращал json который описывает данные, поля, выпадающие списки и прочее что может быть в форме. В результате конечно полезли баги, а как это работает через неделю уже не вспомнишь. Вот на пустом месте сами себе создали проблему и дрючились. И такое где react и vue встречается довольно часто, т.е. люди сами себе усложняют задачу, зачем и ради какой цели — не понятно. И это только один пример у меня было еще хлеще.

G>То есть вы против dry на клиенте, потому что создание повторно используемого кода это сложно?

Оно просто не нужно.

G>Может на сервере делать также? Просто скопипастить код в контроллерах, и поменять запросы?


Q>>>>Преобразование к модели вида, т.е. данные отображения.

G>>>То есть то, что делает маппер?

Q>>Нет, маппер к нужным видам приводит, их может быть несколько разных, бл возвращает данные такими какие они есть в бд.

G>Ну выглядит так, что именно это маппер и делает. В чем тогда заключается БЛ, если отделяем её от запросов?

Еще раз, видом у сущности может быть много, не пихать же каждый в бл, поэтому бл должна возвращать данные в каком — то одном виде, а уже потом это будет преобразоваться.
Программа – это мысли спрессованные в код
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.