Здравствуйте, GreenTea, Вы писали:
GT>Чуть расширенная версия статьи с хабра, для тех кто еще не видел GT>http://brunneng.blogspot.com/2013/10/java-object-merger.html
Статья как раз для хабра. У вас есть кривой код? У нас есть для него фреймверк!
В итоге может оказатся, что существенной разницы между
супротив аналогичного кода на API маппера не имеется.
От себя хочу отметить, что в нормальном дизайне приложения такой ерунды как перекладывания свойств туда-сюда между (тремя!) слоями нет.
BO чудестно можно использовать на всех слоях вместо DTO и VO. Вводя последние лишь в отдельных случаях, когда нужна агрегация и специальная оптимизация.
Re[2]: Маппинг объектов с помощью java-object-merger
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, GreenTea, Вы писали:
GT>>Чуть расширенная версия статьи с хабра, для тех кто еще не видел GT>>http://brunneng.blogspot.com/2013/10/java-object-merger.html B>Статья как раз для хабра. У вас есть кривой код? У нас есть для него фреймверк!
На хабре уже есть более ранняя версия этой статьи.
B>В итоге может оказатся, что существенной разницы между B>
B>супротив аналогичного кода на API маппера не имеется.
Для случая совпадения имен между полями на API маппера вообще ничего не нужно делать. Это определяется автоматически.
B>От себя хочу отметить, что в нормальном дизайне приложения такой ерунды как перекладывания свойств туда-сюда между (тремя!) слоями нет. B>BO чудестно можно использовать на всех слоях вместо DTO и VO. Вводя последние лишь в отдельных случаях, когда нужна агрегация и специальная оптимизация.
Все зависит от размера приложения. Если что-то мелкое — то да. А если одни и те же данные имеют множество представлений в разных местах, то приходится вводить вьюшки. Та и если вы веб сервиса пишете где нужно просто иначе группировать данные, и dto шки для него генерятся по wsdl.. Насчет 3 слоев, это я описал все таки крайний случай, на моей практике маппинг был максимум между 2 слоями.
Re[3]: Маппинг объектов с помощью java-object-merger
Здравствуйте, GreenTea, Вы писали:
GT>Для случая совпадения имен между полями на API маппера вообще ничего не нужно делать. Это определяется автоматически.
Я понимаю. Просто когда модель идентичная, то такой код больше смахивает на промах в проектировании. Когда модель разная, то выгода от маппинге невидируется тем что нужно ещё иметь слой адаптации в тех точках где модели различаются.
GT>Все зависит от размера приложения. Если что-то мелкое — то да.
Не вижу связи.
GT>А если одни и те же данные имеют множество представлений в разных местах, то приходится вводить вьюшки.
Не вижу свяази. У меня толстый GUI, Web, DB, Legacy DB — представлений достаточно.
Похожий код если для конвертации представлений Legacy DB и актуальной DB. Но там маппер не лечит, так как нужно делать массу дополнительных приседаний, а не просто перекладывать свойства.
GT>Та и если вы веб сервиса пишете где нужно просто иначе группировать данные, и dto шки для него генерятся по wsdl..
Если это 3rd party WSDL, то обычно его модель на столько не совпадает с разрабатываемой системной, что простым маппингом это не лечится.
Если это "наша" подконтрольная WSDL, то не вижу причин не использовать одни и те же бины в других слоях.
GT>Насчет 3 слоев, это я описал все таки крайний случай, на моей практике маппинг был максимум между 2 слоями.
Мне однажды достался проект с таким "крайним случаем". Никаких принципиальных преимуществ в таком подходе я не заметил.
Впрочем, я вынужден признать, что у дизайна, с одной и той же моделью на всех слоях есть свои недостатки. Но! Они все вызваны именно тем что инструментарий не предусматривает того что эти классы могуть быть использованы 3-мя, 4-мя аналогичными инструментариями. Таким образом надобность в DTO клона, обычно, вызвано используемыми библиотеками, а не тем что это даёт каких-то преимуществ.
Re[3]: Маппинг объектов с помощью java-object-merger
Здравствуйте, GreenTea, Вы писали:
GT>Все зависит от размера приложения. Если что-то мелкое — то да. А если одни и те же данные имеют множество представлений в разных местах, то приходится вводить вьюшки. Та и если вы веб сервиса пишете где нужно просто иначе группировать данные, и dto шки для него генерятся по wsdl.. Насчет 3 слоев, это я описал все таки крайний случай, на моей практике маппинг был максимум между 2 слоями.
Вот в этом сообщении есть ссылки на две больших темы по DTO, так как DTO наиболее яркий представитель, которому требование копирование свойств. http://www.rsdn.ru/forum/design/3818228.1
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, GreenTea, Вы писали:
GT>>Для случая совпадения имен между полями на API маппера вообще ничего не нужно делать. Это определяется автоматически. B>Я понимаю. Просто когда модель идентичная, то такой код больше смахивает на промах в проектировании. Когда модель разная, то выгода от маппинге невидируется тем что нужно ещё иметь слой адаптации в тех точках где модели различаются.
"Слой адаптации" при использовании маппера это аннотации к сущности на одном из своев. Ничего военного. Вы рассматриваете 2 крайних случая. А бывает так что объекты между слоями на 90% похожи на 10% различны по структуре. На моей практике так и бывало. И для такого как раз мапперы очень облегчают жизнь.
GT>>Все зависит от размера приложения. Если что-то мелкое — то да. B>Не вижу связи.
GT>>А если одни и те же данные имеют множество представлений в разных местах, то приходится вводить вьюшки. B>Не вижу свяази. У меня толстый GUI, Web, DB, Legacy DB — представлений достаточно. B>Похожий код если для конвертации представлений Legacy DB и актуальной DB. Но там маппер не лечит, так как нужно делать массу дополнительных приседаний, а не просто перекладывать свойства.
Возможно это специфика толстого клиента. Поверьте, мешать маппинг в базу, бизнес логику, и представление в одной сущности — как раз это ошибка дизайна. У нас такое было один раз, так что обычные сущности со временем распухали до 1.5к строчек кода, и понять что то было уже не возможно. Насчет большой апликухи я не зря сказал. По началу может модели в базе и на вьюхе не будут различаться, но потом с новыми требованиями различия будут накапливаться, вводится дополнительные вьюшки, меняться представление уже имеющихся данных. Где то репорт потребуется сгенерить, а там вдруг данные представляются совсем не так как в базе! А код, если изначально не разбить на слои, будет ухудшаться все больше.
GT>>Та и если вы веб сервиса пишете где нужно просто иначе группировать данные, и dto шки для него генерятся по wsdl.. B>Если это 3rd party WSDL, то обычно его модель на столько не совпадает с разрабатываемой системной, что простым маппингом это не лечится. B>Если это "наша" подконтрольная WSDL, то не вижу причин не использовать одни и те же бины в других слоях.
Ну представте типичный случай, что на веб сервисе есть 2 метода: первый возвращает всю сущность по id, второй возвращает по критерию поиска — список всех сущностей в укороченном виде (несколько самых важных полей).
GT>>Насчет 3 слоев, это я описал все таки крайний случай, на моей практике маппинг был максимум между 2 слоями. B>Мне однажды достался проект с таким "крайним случаем". Никаких принципиальных преимуществ в таком подходе я не заметил.
B>Впрочем, я вынужден признать, что у дизайна, с одной и той же моделью на всех слоях есть свои недостатки. Но! Они все вызваны именно тем что инструментарий не предусматривает того что эти классы могуть быть использованы 3-мя, 4-мя аналогичными инструментариями. Таким образом надобность в DTO клона, обычно, вызвано используемыми библиотеками, а не тем что это даёт каких-то преимуществ.
Re[2]: Маппинг объектов с помощью java-object-merger
B>супротив аналогичного кода на API маппера не имеется.
Соглашусь. Мэппинг все правно приходтся делать, и накой его делать в конфигах, если можно в коде, не понятно. Только головной боли прибавляет при дебаге.
ЗЫ: Работал в конторе, где нанали дядьку который как раз это самый дозер написал, так как был там фанат этой фигни. Потом одумались, погнали вместе и дядьку и дозер
Re[3]: Маппинг объектов с помощью java-object-merger
Здравствуйте, StanislavK, Вы писали:
SK>Здравствуйте, Blazkowicz, Вы писали:
B>>Здравствуйте, GreenTea, Вы писали:
GT>>>http://brunneng.blogspot.com/2013/10/java-object-merger.html
B>>В итоге может оказатся, что существенной разницы между B>>
B>>супротив аналогичного кода на API маппера не имеется.
SK>Соглашусь. Мэппинг все правно приходтся делать, и накой его делать в конфигах, если можно в коде, не понятно. Только головной боли прибавляет при дебаге.
SK>ЗЫ: Работал в конторе, где нанали дядьку который как раз это самый дозер написал, так как был там фанат этой фигни. Потом одумались, погнали вместе и дядьку и дозер
Конфиги прошлый день! Сейчас рулят аннотации
Re[5]: Маппинг объектов с помощью java-object-merger
Здравствуйте, GreenTea, Вы писали:
GT>"Слой адаптации" при использовании маппера это аннотации к сущности на одном из своев. Ничего военного. Вы рассматриваете 2 крайних случая. А бывает так что объекты между слоями на 90% похожи на 10% различны по структуре. На моей практике так и бывало. И для такого как раз мапперы очень облегчают жизнь.
В этом случае 90% кода можно вынести в общие классы. Сюрприз!
GT>Возможно это специфика толстого клиента.
На Web тоже самое. На Web Service — тоже самое. На RMI тоже самое.
GT>Поверьте, мешать маппинг в базу, бизнес логику, и представление в одной сущности — как раз это ошибка дизайна.
"У нас тут все джентельмены — верят друг-другу на слово". Да?
У меня куча бинов предметной области с маппингами, логикой и пр. В чем ошибка? Как я уже написал выше, косяки вылазят только на кривых инструментах, которые думают что они единолично владеют этими объектами и делают с ним что угодно.
GT>У нас такое было один раз, так что обычные сущности со временем распухали до 1.5к строчек кода, и понять что то было уже не возможно.
Выкладывай класс, я расскажу что с ним не так.
GT>Насчет большой апликухи я не зря сказал.
ОК. Возможно. На больших приложениях косяки всплывают с большей вероятностью.
GT>По началу может модели в базе и на вьюхе не будут различаться, но потом с новыми требованиями различия будут накапливаться, вводится дополнительные вьюшки, меняться представление уже имеющихся данных.
Давайте конкретный пример обсудим. То есть у нас на View совсем не то что в базе? То есть кто-то из двух тупо игнорирует Domain Model? Или как это?
GT>Где то репорт потребуется сгенерить, а там вдруг данные представляются совсем не так как в базе! А код, если изначально не разбить на слои, будет ухудшаться все больше.
Domain Model это отдельный слой. Код разбит на слои. Зачем иметь 3 слоя Domain Model — не понимаю. Пример с отчетом не понятен в двойне. Отчет в любом случае генерится по базе.
GT>Ну представте типичный случай, что на веб сервисе есть 2 метода: первый возвращает всю сущность по id, второй возвращает по критерию поиска — список всех сущностей в укороченном виде (несколько самых важных полей).
Офигить и в WSDL они описаны как 2 разных типа??? PersonFull, PersonPartial, PersonForReport, PersonForView... Класс.
Это всё приводит к тому что ни на уровне работы с базой, ни на уровне представления вы не можете использовать бизнес логику и она начинает странным способом размазываться по слоям.
То есть, нужно например написать Interceptor для Hibernate. И в нем выполнить логику. То мы в нем получаем бин одного типа (база данных). Копируем в бин другого типа (бизнес логика). Вы полняем логику. Конвертируем обратно. Так?
Re[4]: Маппинг объектов с помощью java-object-merger
Здравствуйте, GreenTea, Вы писали:
GT>Конфиги прошлый день! Сейчас рулят аннотации
Не особо-то они и рулят. Вот в чем проблема. У них куча побочных эффектов, с одним из которых вы как раз и боретесь.
Re[3]: Маппинг объектов с помощью java-object-merger
Здравствуйте, GreenTea, Вы писали:
B>>Статья как раз для хабра. У вас есть кривой код? У нас есть для него фреймверк! GT>На хабре уже есть более ранняя версия этой статьи.
Я имел ввиду что статья как раз уровня хабра. Читать там что либо о программировании можно только начинающим.
B>>В итоге может оказатся, что существенной разницы между B>>
B>>супротив аналогичного кода на API маппера не имеется. GT>Для случая совпадения имен между полями на API маппера вообще ничего не нужно делать. Это определяется автоматически.
Мне вот подумалось. Это ж мы на каждый запрос ещё и минимум два раза через рефлексию ходим? Для десятков и сотен свойств. Да?
Re[6]: Маппинг объектов с помощью java-object-merger
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, GreenTea, Вы писали:
GT>>"Слой адаптации" при использовании маппера это аннотации к сущности на одном из своев. Ничего военного. Вы рассматриваете 2 крайних случая. А бывает так что объекты между слоями на 90% похожи на 10% различны по структуре. На моей практике так и бывало. И для такого как раз мапперы очень облегчают жизнь. B>В этом случае 90% кода можно вынести в общие классы. Сюрприз!
Не, не, не. Возможно не так выразился. Я имел в виду что для одной и той же вьюхи 90% полей совпадают, а 10% отличаются (типа: берутся из вложенных сущностей, конвертируется представление [к примеру для даты]).
GT>>Возможно это специфика толстого клиента. B>На Web тоже самое. На Web Service — тоже самое. На RMI тоже самое.
GT>>Поверьте, мешать маппинг в базу, бизнес логику, и представление в одной сущности — как раз это ошибка дизайна. B>"У нас тут все джентельмены — верят друг-другу на слово". Да? B>У меня куча бинов предметной области с маппингами, логикой и пр. В чем ошибка? Как я уже написал выше, косяки вылазят только на кривых инструментах, которые думают что они единолично владеют этими объектами и делают с ним что угодно.
GT>>У нас такое было один раз, так что обычные сущности со временем распухали до 1.5к строчек кода, и понять что то было уже не возможно. B>Выкладывай класс, я расскажу что с ним не так.
Это было давно. Сейчас к сожалению нету доступа к тому коду.
GT>>Насчет большой апликухи я не зря сказал. B>ОК. Возможно. На больших приложениях косяки всплывают с большей вероятностью.
GT>>По началу может модели в базе и на вьюхе не будут различаться, но потом с новыми требованиями различия будут накапливаться, вводится дополнительные вьюшки, меняться представление уже имеющихся данных. B>Давайте конкретный пример обсудим. То есть у нас на View совсем не то что в базе? То есть кто-то из двух тупо игнорирует Domain Model? Или как это?
Есть такая книжечка как Data model resource book (vol 1, 2, 3), там описаны правильные проверенные сопособы огранизации модели в бд для разных предметных областей. Когда мы начали делать нашу медицинскую систему (EMR) то черпали вдохновение из этой книжки. По началу, было совсем не понятно какой модель должна быть сейчас и как она изменится в будующем, т.к. четких требований как таковых к системе не было, и все менялось очень быстро. Поэтому модель делалась очень гибкой, с обилием объектов связок. Это трудно объеснить в паре предложений.
Та к книжку отправлять вас читать — мне честно, жалко. Т.к. она имеет свойство снотворного при ее чтении . Что же получилось. Модель действительно очень гибкая, масштабируемая и удобная для описания бизнес логики. НО! Совершенно не мапится на представление один к одному. Аналитики составляющие требование — класть хотели на нашу супер модель.
Вот скриншот малой части модели.. https://www.dropbox.com/s/olgcy4vx3grlwl3/123.png
А теперь представте что надо вставить данные по сотруднику, его имя, должность, телефон. Это все берется из различный сущностей иерархии модели.
GT>>Где то репорт потребуется сгенерить, а там вдруг данные представляются совсем не так как в базе! А код, если изначально не разбить на слои, будет ухудшаться все больше. B>Domain Model это отдельный слой. Код разбит на слои. Зачем иметь 3 слоя Domain Model — не понимаю. Пример с отчетом не понятен в двойне. Отчет в любом случае генерится по базе.
GT>>Ну представте типичный случай, что на веб сервисе есть 2 метода: первый возвращает всю сущность по id, второй возвращает по критерию поиска — список всех сущностей в укороченном виде (несколько самых важных полей). B>Офигить и в WSDL они описаны как 2 разных типа??? PersonFull, PersonPartial, PersonForReport, PersonForView... Класс.
Ну представте себе да, а вы бы как делали?
B>Это всё приводит к тому что ни на уровне работы с базой, ни на уровне представления вы не можете использовать бизнес логику и она начинает странным способом размазываться по слоям. B>То есть, нужно например написать Interceptor для Hibernate. И в нем выполнить логику. То мы в нем получаем бин одного типа (база данных). Копируем в бин другого типа (бизнес логика). Вы полняем логику. Конвертируем обратно. Так?
Не совсем, в текущем проекте бизнес объект оборачивается вокруг объекта базы. И работает как прокси. Тут маппинга нет.
Re[4]: Маппинг объектов с помощью java-object-merger
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, GreenTea, Вы писали:
B>>>Статья как раз для хабра. У вас есть кривой код? У нас есть для него фреймверк! GT>>На хабре уже есть более ранняя версия этой статьи. B>Я имел ввиду что статья как раз уровня хабра. Читать там что либо о программировании можно только начинающим.
B>>>В итоге может оказатся, что существенной разницы между B>>>
B>>>супротив аналогичного кода на API маппера не имеется. GT>>Для случая совпадения имен между полями на API маппера вообще ничего не нужно делать. Это определяется автоматически. B>Мне вот подумалось. Это ж мы на каждый запрос ещё и минимум два раза через рефлексию ходим? Для десятков и сотен свойств. Да?
Да, но маппинг объектов не является узким местом. Запросы к базе с последующим маппингом на сущности работают в десятки если не сотни раз медленнее.
Re[7]: Маппинг объектов с помощью java-object-merger
Здравствуйте, GreenTea, Вы писали:
B>>В этом случае 90% кода можно вынести в общие классы. Сюрприз! GT>Не, не, не. Возможно не так выразился. Я имел в виду что для одной и той же вьюхи 90% полей совпадают, а 10% отличаются (типа: берутся из вложенных сущностей, конвертируется представление [к примеру для даты]).
И даже в этом случае 90% кода можно вынести в общие классы.
GT>Поэтому модель делалась очень гибкой... GT>Совершенно не мапится на представление один к одному. Аналитики составляющие требование — класть хотели на нашу супер модель.
Ну, то есть, в итоге, модель оказалась недостаточно гибкой.
GT>https://www.dropbox.com/s/olgcy4vx3grlwl3/123.png
Ага. Теперь понятно чем руководствуются правительственные моделлеры в USA.
GT>А теперь представте что надо вставить данные по сотруднику, его имя, должность, телефон. Это все берется из различный сущностей иерархии модели.
Мне представлять не нужно. В UI нет проблем достать что-то через пару свойств.
GT>Ну представте себе да, а вы бы как делали?
Разбил бы через композицию и наследование в иерархию.
Re[8]: Маппинг объектов с помощью java-object-merger
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, GreenTea, Вы писали:
B>>>В этом случае 90% кода можно вынести в общие классы. Сюрприз! GT>>Не, не, не. Возможно не так выразился. Я имел в виду что для одной и той же вьюхи 90% полей совпадают, а 10% отличаются (типа: берутся из вложенных сущностей, конвертируется представление [к примеру для даты]). B>И даже в этом случае 90% кода можно вынести в общие классы.
GT>>Поэтому модель делалась очень гибкой... GT>>Совершенно не мапится на представление один к одному. Аналитики составляющие требование — класть хотели на нашу супер модель. B>Ну, то есть, в итоге, модель оказалась недостаточно гибкой.
Та нет, модель как раз это самое гибкое. А представление может меняться от итерации к итерации. Что же каждый раз базу менять?
GT>>https://www.dropbox.com/s/olgcy4vx3grlwl3/123.png B>Ага. Теперь понятно чем руководствуются правительственные моделлеры в USA.
Зато теперь вы видите, что модели могут быть сложными. А то такое ощущение у меня сложилось, что вы живете в каком то простом мире
GT>>А теперь представте что надо вставить данные по сотруднику, его имя, должность, телефон. Это все берется из различный сущностей иерархии модели. B>Мне представлять не нужно. В UI нет проблем достать что-то через пару свойств.
Ага, тянуть на представления всю иерархию, и пусть ищут, что им нужно! Отличный подход! А то что лишние данные передаются, то что это как минимум не секюрно, кого это волнует?)
GT>>Ну представте себе да, а вы бы как делали? B>Разбил бы через композицию и наследование в иерархию.
Ок. На одном экране нужны условно поля field1, field2. На другом field2, field3, на третьем field1, field3. На самом деле под полями могут подразумеваться данные которые нужно вытащить из вложенных сущностей. И удачи вам в разбиении "через композицию и наследование в иерархию"
Re[4]: Маппинг объектов с помощью java-object-merger
Здравствуйте, GreenTea, Вы писали:
SK>>Соглашусь. Мэппинг все правно приходтся делать, и накой его делать в конфигах, если можно в коде, не понятно. Только головной боли прибавляет при дебаге. SK>>ЗЫ: Работал в конторе, где нанали дядьку который как раз это самый дозер написал, так как был там фанат этой фигни. Потом одумались, погнали вместе и дядьку и дозер GT>Конфиги прошлый день! Сейчас рулят аннотации
Не вижу приципиальной разницы между одним и другим. Аннотации — тот же конфиг.
А вообще, особенно здорово, выглядят аннотации когда их куча разных понавешано на одном класса. Например, ваши и хибернейтовские сразу. Уж лучше бы уж по разным файлам лежали.
Re[9]: Маппинг объектов с помощью java-object-merger
Здравствуйте, GreenTea, Вы писали:
GT>Та нет, модель как раз это самое гибкое. А представление может меняться от итерации к итерации. Что же каждый раз базу менять?
Хорошо, так если модель гибкая, то зачем менять её и базу для каждого представления?
GT>Зато теперь вы видите, что модели могут быть сложными. А то такое ощущение у меня сложилось, что вы живете в каком то простом мире
Ну, давайте письками меряться: http://www.schemacentral.com/sc/niem21/ss.html
GT>Ага, тянуть на представления всю иерархию, и пусть ищут, что им нужно!
Зачем всю. Только ту часть, которая нужна.
GT>Отличный подход! А то что лишние данные передаются, то что это как минимум не секюрно, кого это волнует?)
Класс. То есть секурити, которая динамически на кладывается на мета-модель, у вас статически зашита в саму модель?
GT>Ок. На одном экране нужны условно поля field1, field2. На другом field2, field3, на третьем field1, field3. На самом деле под полями могут подразумеваться данные которые нужно вытащить из вложенных сущностей. И удачи вам в разбиении "через композицию и наследование в иерархию"
То есть, если я правильно понял, так как вам тяжело на UI работать с иерархией вы её приводите к плоской модели каждый раз? Это специфика UI такая?
Re[10]: Маппинг объектов с помощью java-object-merger
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, GreenTea, Вы писали:
GT>>Та нет, модель как раз это самое гибкое. А представление может меняться от итерации к итерации. Что же каждый раз базу менять? B>Хорошо, так если модель гибкая, то зачем менять её и базу для каждого представления?
Ну если вы предлагаете использовать одну и ту же сущность. И вот представление меняется, занчит и сущность надо поменять, чтобы отдавать чуть другие данные. Но это означает и базу придется менять, тк. представление уже не соответсвует модели.
GT>>Зато теперь вы видите, что модели могут быть сложными. А то такое ощущение у меня сложилось, что вы живете в каком то простом мире B>Ну, давайте письками меряться: B>http://www.schemacentral.com/sc/niem21/ss.html
Честно, не понял что это такое.
GT>>Ага, тянуть на представления всю иерархию, и пусть ищут, что им нужно! B>Зачем всю. Только ту часть, которая нужна.
GT>>Отличный подход! А то что лишние данные передаются, то что это как минимум не секюрно, кого это волнует?) B>Класс. То есть секурити, которая динамически на кладывается на мета-модель, у вас статически зашита в саму модель?
Я к тому что если передавать всю иерархию сущностей как есть, то можно передать ненароком секретные данные.
GT>>Ок. На одном экране нужны условно поля field1, field2. На другом field2, field3, на третьем field1, field3. На самом деле под полями могут подразумеваться данные которые нужно вытащить из вложенных сущностей. И удачи вам в разбиении "через композицию и наследование в иерархию" B>То есть, если я правильно понял, так как вам тяжело на UI работать с иерархией вы её приводите к плоской модели каждый раз? Это специфика UI такая?
Тоесть насколько я понял, вы предлагаете не меняя исходной структуры модели передавать каждый раз только те данные которые нужны представлению. А кто будет решать какие данные нужны а какие нет, для каждого конкретного запроса, и кто это будет разруливать?
Re[11]: Маппинг объектов с помощью java-object-merger
Здравствуйте, GreenTea, Вы писали:
GT>Ну если вы предлагаете использовать одну и ту же сущность. И вот представление меняется, занчит и сущность надо поменять, чтобы отдавать чуть другие данные.
Жесть какая-то. Представление берет любую сущность и представляет её в нужном виде. Почему из задачи поменять представление незаменимо следует "поменять сущность", мне не понятно.
GT>Но это означает и базу придется менять, тк. представление уже не соответсвует модели.
Блин, слои для того и придумали, чтобы изменение одного слоя ограничивало "плюх" эти слоем. Почему у вас при изменении представления нужно менять модель предметной области и базу, мне не понятно.
B>>http://www.schemacentral.com/sc/niem21/ss.html GT>Честно, не понял что это такое.
Это модель предметой области.
GT>Я к тому что если передавать всю иерархию сущностей как есть, то можно передать ненароком секретные данные.
Ненароком можно передать всё что хочешь. Если нужна секурность на уровне свойств, то почему бы её и не реализовать отдельным слоем, который даёт\запрещает достум к свойствам.
Я не вижу смысла хардкодить в модели то что динамически меняеться конфигурацией.
Даже если нужны секурные свойства. ОК.
FullPerson -> SecuredPersonInfo -> PublicPersonInfo -> BasicPersonInfo
GT>Тоесть насколько я понял, вы предлагаете не меняя исходной структуры модели передавать каждый раз только те данные которые нужны представлению. А кто будет решать какие данные нужны а какие нет, для каждого конкретного запроса, и кто это будет разруливать?
Протокол обмена между представлением и бизнес логикой. Мне воот теперь вообще интересно посмотреть на вашу бизнес логику. Она у вас, скорее, выходит совершенно анемичной.
К примеру, у меня на View есть PersonWithName, в котором нет DOB, потому что он в SecuredPersonInfo.
В результате мне чтобы посчитать AGE нельзя просто взять Person.calcAge(), мне нужно дописать Age в PersonWithName, и в маппинге.
Я уже задал этот вопрос выше. Как вы переиспользуете логику бизнес-объектов в слоях, где у вас вместо бизнес-объектов лишь обрубки?
Re[12]: Маппинг объектов с помощью java-object-merger
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, GreenTea, Вы писали:
GT>>Ну если вы предлагаете использовать одну и ту же сущность. И вот представление меняется, занчит и сущность надо поменять, чтобы отдавать чуть другие данные. B>Жесть какая-то. Представление берет любую сущность и представляет её в нужном виде. Почему из задачи поменять представление незаменимо следует "поменять сущность", мне не понятно.
GT>>Но это означает и базу придется менять, тк. представление уже не соответсвует модели. B>Блин, слои для того и придумали, чтобы изменение одного слоя ограничивало "плюх" эти слоем. Почему у вас при изменении представления нужно менять модель предметной области и базу, мне не понятно.
Еще раз, как я вас понял.. Что якобы слои не нужны, надо маппинг доступа к бд, бизнес логикиу, и представление слепить в одну сущность. Сейчас же вы говорите что слои нужны.. Извините если не правильно понял.
B>>>http://www.schemacentral.com/sc/niem21/ss.html GT>>Честно, не понял что это такое. B>Это модель предметой области.
GT>>Я к тому что если передавать всю иерархию сущностей как есть, то можно передать ненароком секретные данные. B>Ненароком можно передать всё что хочешь. Если нужна секурность на уровне свойств, то почему бы её и не реализовать отдельным слоем, который даёт\запрещает достум к свойствам. B>Я не вижу смысла хардкодить в модели то что динамически меняеться конфигурацией. B>Даже если нужны секурные свойства. ОК. B>FullPerson -> SecuredPersonInfo -> PublicPersonInfo -> BasicPersonInfo
GT>>Тоесть насколько я понял, вы предлагаете не меняя исходной структуры модели передавать каждый раз только те данные которые нужны представлению. А кто будет решать какие данные нужны а какие нет, для каждого конкретного запроса, и кто это будет разруливать? B>Протокол обмена между представлением и бизнес логикой. Мне воот теперь вообще интересно посмотреть на вашу бизнес логику. Она у вас, скорее, выходит совершенно анемичной. B>К примеру, у меня на View есть PersonWithName, в котором нет DOB, потому что он в SecuredPersonInfo. B>В результате мне чтобы посчитать AGE нельзя просто взять Person.calcAge(), мне нужно дописать Age в PersonWithName, и в маппинге. B>Я уже задал этот вопрос выше. Как вы переиспользуете логику бизнес-объектов в слоях, где у вас вместо бизнес-объектов лишь обрубки?
Отчего вы решили что вместо бизнес объектов у нас обрубки? "у меня на View есть PersonWithName" это вы про свой проект говорите, или иносказательно про мой?
Допустим про мой.. Итак есть бизнес объект PersonBO, и вьюшка PersonWithNameVO. Делаем в PersonBO метод вычисляющий возраст, и обзываем getAge(). Далее во вьюшке делаем свойство age. Все.
Маппер замапит возраст на вьюшку. Нужен будет этот ворзаст в какой нибудь PersonFullInfoVO — тоже делается свойство age, или наследуется от PersonWithNameVO, тут по ситуации.
