|
Модераторы: LSD |
|
fezzz |
|
|||
Новичок Профиль Группа: Участник Сообщений: 8 Регистрация: 15.2.2007 Репутация: нет Всего: нет |
Уважаемые коллеги нужен адекватный взгляд на проблему
Пришел работать в новую фирму, тут пишут большой корпоративный проект на ejb + gwt (компоненты от sencha gxt2-3). Хотел спросить совета, вернее дать какую-то оценку выбранному архитектурному подходу. Суть проблемы: На уровне данных вроде бы все ок. Объектная модель данных на базе jpa, тут вопросов нет. Но вот дальше начинается самое интересное - придуман некий слой DTO, на который возложено множество функций. Этот слой представляет из себя абсолютно зеркальную к модели данных (классы таблиц) структуру объектов, где каждый класс повторяет соответствующий класс таблицы. Плюс к этому реализованы два сервиса - dozer и combine. Dozer собирает на основе выбранных данных из объектов таблиц структуру из DTO. Причем не существует никаких (почти) механизмов ограничения выборки ветвей графа модели данных. Т.е. если мы например тянем список клиентов в комбобокс, где нужны по сути только их наименования, то dozer тащит все, что к этим клиентам привязано, все структуры, все коллекции и т.д. Т.е. думаю понятно. Есть правда механизм LazyList, который должен подгружать подцепленные коллекции по запросу, но он нигде почти не используется и распространяется только на коллекции. Второй сервис Combine наоборот пишет структуру DTO в базу данных, причем опять же нет никакой возможности управлять этим процессом, если была вытащена огромная структура, в ней поменяли одно поле, то пишется в базу все, с обходом всех связей. Кроме того, в базу сохраняется как бы слепок такой структуры. Если два пользователя допустим добавили какую-то информацию в какую-то структуру, ну допустим 2 разных записи контактной информации клиента, то сохранится только одна из них, потому что клиентское приложение посылает на сохранение всю структуру, которая пишется целиком, а не сливается с той, что в базе данных каким-то образом. Ну и кроме того, вся эта структура DTO одновременно является объектным слоем поставщиком данных для GUI. Все DTO наследованы от ModelData. Т.е. вся работа построена нехитрым образом - прочитали данные, преобразовали в DTO, сразу их показали в GUI, поменяли где надо, послали на запись. Как мне кажется этакий суррогат клиент-сервера. В общем я поработал с этим и пришел к выводу, что все это имеет право на существование только как ну некий трюк, может быть учебный пример или что-то такое, но разрабатывать серьезное приложение очень сложно. Хотел спросить совета, может я чего-то не понимаю (у меня небольшой опыт разработки web приложений), может это распространенный подход и все хорошо? Если что-то непонятно описал, задавайте уточняющие вопросы Заранее спасибо. |
|||
|
||||
Nofate |
|
|||
Опытный Профиль Группа: Участник Сообщений: 266 Регистрация: 13.10.2008 Репутация: нет Всего: 8 |
Так примерно с GWT и приходится возиться. Чтобы лишние данные не гонять - DTO должны содержать необходимый минимум информации.
Так это и есть клиент-сервер. На GWT у вас вполне толстый клиент (Rich Internet Application -RIA если быть точным). Клиент общается с сервером по-умолчанию средствами GWT RPC. Но могут быть и другие варианты, например REST+JSON или REST+XML. Поскольку мы не имеем возможности работать с ленивыми коллекциями хибера на клиенте (это ведь не JSP-представление, а практически автономное приложение, запущенное в браузере), приходится все данные конвертировать на входе и на выходе. -------------------- The future is not set, there is no fate but what we make for ourselves. Нофейтово пространство и смежные области |
|||
|
||||
fezzz |
|
|||
Новичок Профиль Группа: Участник Сообщений: 8 Регистрация: 15.2.2007 Репутация: нет Всего: нет |
Необходимый минимум - это да! Но если Вы прочитали то, что писал я, в этом в случае DTO являются зеркальным отображение вообще всей структуры данных и тащат в себе всегда все связи. Разве это правильно? Я думаю, что DTO пишутся отдельно для каждого отдельного случая и содержат информацию по ситуации, а не копируют всю структуру данных. |
|||
|
||||
LSD |
|
|||
Leprechaun Software Developer Профиль Группа: Модератор Сообщений: 15708 Регистрация: 24.3.2004 Репутация: 1 Всего: 537 |
В целом архитектура попахивает энтерпрайзом головного мозга
Т.е. вообще никакой бизнес логики между прочитали из базы и преобразовали в DTO нет?
В целом - да. Хотя конечно по понятным причинам они весьма похожи на исходные структуры данных. -------------------- Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it. |
|||
|
||||
fezzz |
|
|||
Новичок Профиль Группа: Участник Сообщений: 8 Регистрация: 15.2.2007 Репутация: нет Всего: нет |
Нет, это делается одним методом, который автоматом переносит граф данных из jpa в граф DTO. Клиент ворочает всеми этими структурами, что мне как-то дико. Я в принципе понимаю, что на GWT пишется довольно-таки толстый клиент, который за раз принимает довольно большие объемы данных, обрабатывает их и отсылает на сервер, но это как-то совсем уж крайний случай. Мне просто нужно понять насколько такое решение типично, может я дурак? Т.е. допустим есть у нас некий условный заказ. При его передаче на клиента, передается вообще все, что имеет хоть какое-то отношение к нему. Т.е. клиент вместе с его всеми полями, в которых может быть все, что угодно, начиная от структуры сотрудников клиента, заканчивая какой-нибудь историей изменений и прочее прочее. И так со всеми объектами, которые привязаны к заказу. Более того, если допустим есть некий общий список заказов, где нужно просто выбрать один и открыть его, то этот список это по сути коллекция вот таких вот монстро-образных структур, где каждая запись в гриде - это полный граф такого вот заказа, хотя в итоге-то будет выбран какой-нибудь один и с ним пользователь будет работать, а остальные просто не нужны. Это сообщение отредактировал(а) fezzz - 9.1.2013, 17:36 |
|||
|
||||
LSD |
|
|||
Leprechaun Software Developer Профиль Группа: Модератор Сообщений: 15708 Регистрация: 24.3.2004 Репутация: 1 Всего: 537 |
Это решение очень плохое. Плохо как минимум тем, что сервер не делает никаких проверок прав доступа, корректности данных и т.п. -------------------- Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it. |
|||
|
||||
fezzz |
|
|||
Новичок Профиль Группа: Участник Сообщений: 8 Регистрация: 15.2.2007 Репутация: нет Всего: нет |
Проверки доступа, кстати, реализованы )) Но интересным образом, некоторым пользователям запрещено читать определенные поля, но, что он видит, если что-то пошло не так, это неопределенную ошибку на клиенте, а полное сообщение падает в лог сервера. Проверка логической целостности данных, если и делается, то исключительно на клиенте. |
|||
|
||||
baldina |
|
|||
Эксперт Профиль Группа: Завсегдатай Сообщений: 3433 Регистрация: 5.12.2007 Где: Москва Репутация: нет Всего: 101 |
это тоже нехорошо. получается, сервер и клиент связаны весьма доверительными отношениями. такое решение плохо устойчиво к ошибкам клиента и плохо расширяемо. а что говорят главные архитекторы проекта? |
|||
|
||||
fezzz |
|
|||
Новичок Профиль Группа: Участник Сообщений: 8 Регистрация: 15.2.2007 Репутация: нет Всего: нет |
Человек, который все это написал, сейчас не работает в фирме. А у других программистов отношение весьма лояльное. Потому что, есть видимость того, что писать легко. Сейчас ведь как делается - создается например новая структура в базе, к ней пишется зеркальная DTO - точно такая же и вуаля, все это можно напрямую уже смотреть на клиенте, изменять и писать в базу. Все это похоже на db aware компоненты, которые были на делфи. Тяп ляп и готово. Проект не очень еще развит, но амбиции очень серьезные, вот сейчас начали встречаться с различными сложностями, но пока понимание того, что это работать не будет, еще не пришло. |
|||
|
||||
LSD |
|
|||
Leprechaun Software Developer Профиль Группа: Модератор Сообщений: 15708 Регистрация: 24.3.2004 Репутация: 1 Всего: 537 |
Вот вам и не авторизованный доступ к данным. Берешь дебагер JS и вперед. Как только проект подрастет наступите на грабли масштабируемости проекта. -------------------- Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it. |
|||
|
||||
fezzz |
|
|||
Новичок Профиль Группа: Участник Сообщений: 8 Регистрация: 15.2.2007 Репутация: нет Всего: нет |
Я уже на них стою. Размышляю теперь, как глаза остальным открыть. |
|||
|
||||
JDmitry |
|
||||||
Новичок Профиль Группа: Участник Сообщений: 45 Регистрация: 5.3.2009 Репутация: нет Всего: нет |
Как раз Dozer и нужен для ограничения графа модели. Например, если вы создали класс Topic, содержащий список Comment, то ваш DTO объект должен содержать только нужные поля, как и в TopicDTO, так и в CommentDTO Например, если вам нужно показать только название раздела и его коментарии (без подгрузки коментариев), то обьект у вас будет выглядеть так (я маппинг делаю аннотациями - это не меняет сути)
И тогда вы можете сделать так
И в вашем topicDTO вы получите только часть структуры Таким образом мы вытягиваем только название и текст комментариев, игнорируя все остальные поля в вашем как в вашем Topic Entity объекте, так и в связанном в нем Comments. Даже если в Topic есть другие связи и сущности Это сообщение отредактировал(а) JDmitry - 9.4.2013, 11:59 |
||||||
|
|||||||
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | Java: Design, Quality, Testing | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |