RS
Grigori
в общем все верно написано, только изменение формы на фронте это скорее следствие того что вы меняете бизнеслогику, а не наоборот.
Ну да, я так и подумал, но в принципе сути не меняет.
Size: a a a
2019 July 25
G
Для каждом формы на фронте создается свой DTO-класс - это то же не так, если вы создаете РЕСТ приложение, то делаете впервую очередь правильный РЕСТ, а потом фронт им пользуется
PB
Обычно DTO через мапофильтры превращают сразу в объекты для сохранения (если такие объекты есть/нужны в вашей DB библиотеке). Если JPA, то получает DTO -> Entity.
DAO это объект, инкапсулирующий работу с хранилищем. Называть ваши сущности/entity DAO - это не совсем верно, так как они просто pojo. А вот спринговый репозиторий в данном случае и будет DAO.
DAO это объект, инкапсулирующий работу с хранилищем. Называть ваши сущности/entity DAO - это не совсем верно, так как они просто pojo. А вот спринговый репозиторий в данном случае и будет DAO.
RS
Возник такой вопрос: Какие обьекты должны быть в приложении? Имею в виду, где должны быть DTO, где BO, а где DAO. Я просто никогда реальных приложений не видел, поэтому не знаю, как лучше строить архитектуру. Сейчас прикинул себе такой вариант, но не знаю, правильно ли это:
Для работы с фронтэндом я использую DTO-классы, у них есть только те поля, которые можно ввести с формы на фронте. Для каждом формы на фронте создается свой DTO-класс. Пример: RegistrationForm(для формы регистрации пользователя), EditProfileForm(для формы редактирования профиля пользователя). В таких классах нет никакой логики, исключительно поля для транспортировки между фронтэндом и бекэндом.
Для работы с базой использую DAO-классы, в них есть только те поля, которые требуют персистентности, то есть, практически все поля, которые могут быть у теоретического пользователя. Эти классы помечены аннотацией Entity и их структура максимально простая, никакой логики, только поля. Так же, эти классы я пытаюсь держать максимально близко к той части приложения, где производится работа с базой, а в бизнес логику я их не пускаю.
Для бизнес логики я использую обычные классы, которые имеют все нужные пользователю поля и могут содержать какое-то поведение.
Проблемы, которые я заметил:
Например, для условного класса пользователя, все 3 класса(DTO, BO и DAO) почти одинаковые, то есть содержат одни и те же поля, за исключением пары полей. В результате, код дублируется и в случае изменения одного из этих трех, придется менять как минимум еще один. Пример: Изменилась форма на фронте и теперь DTO принимает еще одно поле, значит такое же поле нужно добавить и в BO, а если его еще и нужно сохранять в базу, то и DAO придется менять.
Прошу подсказать, как такие вещи решаются в реальных приложениях, какие для этого существуют паттерны и где об этом можно почитать. Если же описанная выше схема приемлема, то прошу указать на минусы или идеи для улучшения.
Для работы с фронтэндом я использую DTO-классы, у них есть только те поля, которые можно ввести с формы на фронте. Для каждом формы на фронте создается свой DTO-класс. Пример: RegistrationForm(для формы регистрации пользователя), EditProfileForm(для формы редактирования профиля пользователя). В таких классах нет никакой логики, исключительно поля для транспортировки между фронтэндом и бекэндом.
Для работы с базой использую DAO-классы, в них есть только те поля, которые требуют персистентности, то есть, практически все поля, которые могут быть у теоретического пользователя. Эти классы помечены аннотацией Entity и их структура максимально простая, никакой логики, только поля. Так же, эти классы я пытаюсь держать максимально близко к той части приложения, где производится работа с базой, а в бизнес логику я их не пускаю.
Для бизнес логики я использую обычные классы, которые имеют все нужные пользователю поля и могут содержать какое-то поведение.
Проблемы, которые я заметил:
Например, для условного класса пользователя, все 3 класса(DTO, BO и DAO) почти одинаковые, то есть содержат одни и те же поля, за исключением пары полей. В результате, код дублируется и в случае изменения одного из этих трех, придется менять как минимум еще один. Пример: Изменилась форма на фронте и теперь DTO принимает еще одно поле, значит такое же поле нужно добавить и в BO, а если его еще и нужно сохранять в базу, то и DAO придется менять.
Прошу подсказать, как такие вещи решаются в реальных приложениях, какие для этого существуют паттерны и где об этом можно почитать. Если же описанная выше схема приемлема, то прошу указать на минусы или идеи для улучшения.
одно уточнение. DAO - это не класс с данными (из вашего сообщение складывается ощущение, что у вас это так). DAO - это слой работы с данными. Т.е. тот код, который загружает/сохраняет ваши данные в БД. А классы с данными, которые будут иметь во многих случаях те же поля, что и DTO - это Entity.
G
Ну да, я так и подумал, но в принципе сути не меняет.
это кажется мелочью но об этом надо помнить, иначе у вас очень скоро в БизнесОбъектах будутут детали реализации фронта )
G
точно вы ДАО с Ентити перепутали
RS
Хорошо, насчет DAO я понял. Насчет DTO -> Entity. У меня так и происходит, но через прослойку, в виде BO. Может, мне тогда BO вообще ну нужны? У меня просто сейчас практически никакой бизнесс логики нет и я не знаю, нужны ли мне эти обьекты будут или нет.
Насчет REST. Сейчас у меня никакого реста нет, да и не планировал особо, но как я понимаю, сначала нужно запилить REST API, а потом его дергать из фронта? Насколько это традиционная практика?
Насчет REST. Сейчас у меня никакого реста нет, да и не планировал особо, но как я понимаю, сначала нужно запилить REST API, а потом его дергать из фронта? Насколько это традиционная практика?
G
да, Ентити часто выполняют роль БО в небольших проектах, да и в больших то же )
RS
Но это неправильно, да?
PB
Это нормально, если это работает
G
Но это неправильно, да?
нормально
RS
Потому что я изначально вообще использовал Entity как DTO и в результате напоролся на баг, с которым я выше обращался. После этого решил четко разделить обьекты для каждого слоя приложения отдельно.
RS
Ну хорошо, если в целом всё более-менее верно, то буду и дальше двигаться в этом направлении. Всем спасибо за ответы.
G
"Насколько это традиционная практика?" - прям радикально православная
RS
В эту сторону тоже копну, спасибо.
PB
Нужно понять, какой кусок вашей веб-страницы приводит к срабатыванию ошибки.
Например, если у вас на странице есть какой-нибудь
Если в скрипте вы, например, пытаетесь вытащить картинку и для этого пишите
Аналогичная будет ситуация, если у вас вместо бекенда какой-нибудь nginx раздает картинки/файлики с неправильным
Тут нет общего решения, нужно понять, почему ошибка возникает.
Например, если у вас на странице есть какой-нибудь
<script src="https://bla-bla.com/malicious_file.json"> - вы тут же получится CORB (как минимум по утрвеждению документашки хрома)Если в скрипте вы, например, пытаетесь вытащить картинку и для этого пишите
<img src="BACKEND_HOST/url при этом у вас бекенд возвращает хедер X-Content-Type-Options: nosniff, и Content-type: text/xml, вы также получится CORB.Аналогичная будет ситуация, если у вас вместо бекенда какой-нибудь nginx раздает картинки/файлики с неправильным
content-typeТут нет общего решения, нужно понять, почему ошибка возникает.
SA
Всем привет! кто подскажет? на работе стоит прокси, настроил в idea,maven все работает ок. Далее вопрос старта приложения, есть определенная строка jdbc:mysql://IP/DBName?useUnicode=true&characterEncoding=utf8&serverTimezone=UTC
11:12 AM
вот IP в студии проверяю через прокси, есть коннект, без прокси нет, вот как сказать приложению какой прокси использовать для подключения в бд? пока гугл только чет в старые варианты конфига отправляет классы переписывать, мб есть способ что-то поправить в пропертях?
11:12 AM
вот IP в студии проверяю через прокси, есть коннект, без прокси нет, вот как сказать приложению какой прокси использовать для подключения в бд? пока гугл только чет в старые варианты конфига отправляет классы переписывать, мб есть способ что-то поправить в пропертях?
RS
Всем привет! кто подскажет? на работе стоит прокси, настроил в idea,maven все работает ок. Далее вопрос старта приложения, есть определенная строка jdbc:mysql://IP/DBName?useUnicode=true&characterEncoding=utf8&serverTimezone=UTC
11:12 AM
вот IP в студии проверяю через прокси, есть коннект, без прокси нет, вот как сказать приложению какой прокси использовать для подключения в бд? пока гугл только чет в старые варианты конфига отправляет классы переписывать, мб есть способ что-то поправить в пропертях?
11:12 AM
вот IP в студии проверяю через прокси, есть коннект, без прокси нет, вот как сказать приложению какой прокси использовать для подключения в бд? пока гугл только чет в старые варианты конфига отправляет классы переписывать, мб есть способ что-то поправить в пропертях?
если у вас именно HTTP прокси (а не, например, socks), то никак. jdbc через http прокси не пройдет, т.к. там не http-протокол.
SA
Ruslan Stelmachenko
если у вас именно HTTP прокси (а не, например, socks), то никак. jdbc через http прокси не пройдет, т.к. там не http-протокол.
Уточню ок. А если есть и socks?
RS
ну тогда, по идее, как описано тут в п 2.4 https://docs.oracle.com/javase/8/docs/technotes/guides/net/proxies.html