Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, gandjustas, Вы писали:
G>>Ты на С++ пишешь чтоли? Там уже давно shared_ptr для посчета ссылок придумалию D>Нет, не на C++. Но есть у меня сомнение, что C++ный shared_ptr можно прикрутить к ORM entities, чтобы он записывал обновлённое значение счётчика ссылок в базу.
Зачем счетчик ссылок в базе?
G>>Это полнейший бред. D>Сам дурак.
Риторика — супер.
G>>Все что ты описал сильно снижает mantainability, один и теже изменения делать в разных местах одинаково хреново независимо от того очевидно это или нет. D>Это очевидно. А теперь изволь изложить, как бы ты реализовал мой пример — когда админам и обычным юзерам (и те и другие коннектятся к сайту из swing-клиента) нужно отдавать одни и те же структуры данных, за исключением чувствительной информации, которую юзерам видеть не полагается.
Для целей presentation обычно вводятся структуры, отличающиеся от модели данных. В них и будет различие.
Тольео с БЛ это никак не связно.
G>>В общем случае надо отделять всю логику от данных. Тогда будет меньше дублирования и больше повторного использования. D>То есть, в каждом месте, где выполняется a->setB(b), не забывать добавлять b->countAs++? Да, действительно меньше дублирования. И очень повышает maintainability.
Приведи адекватное обоснование необходимости таких действий.
Здравствуйте, Нахлобуч, Вы писали:
Н>Вообще говоря, DTO ты упомянул совершенно вскользь, так что непонятно, зачем к этому аппеллировать -- разговор совершеннл не про них.
Разговор вроде бы о допустимости запихивания какой-либо логики в entities?
Н>Уже плохо. Сегодня -- toDTO/fromDTO, завтра -- toJSON/fromJSON, послезавтра -- бардак. Ясных критериев-то нет.
Вот послезавтра и отрефакторим. Но я тут отстаиваю активные объекты, а не конкретно вопрос, куда пихать метод toDTO.
D>>Сам я привык руководствоваться следующим правилом: если изменение состояния объекта базы (entity) ведёт к необходимости каскадных изменений состояний других объектов (как в примере со счётчиком ссылок),
Н>Ты отвлекись от счетчиков и ссылок -- это тебе твой же инструмент сложности создает.
Счётчики и ссылки — лишь простой пример. Меня удивляет, что вы все к нему привязались. Извольте, вот пример с миксином TreeNode:
1) он добавляет к классу поля parent, numChildren, numDescendants;
2) при добавлении в иерархию он корректирует numChildren своего родителя и numDescendants своих предков;
3) также он синхронизирует данные таблицы замыкания (PK(ancestorid, descendantid), distance).
Выносить всю логику из пунктов (2) и (3) в контроллеры — значит дублировать её во множестве контроллеров для всех entities, являющихся TreeNode. Или делать отдельные методы в helper-классах, что всё равно дико: всё-таки гораздо понятнее и более ожидаемо написать node1.addChild(node2), чем TreeController.addChild(node1, node2). Все вот эти SomethingController, плодящиеся как грибы после дождя, если отказаться от активных entities, дико раздражают.
D>>В результате entities у меня, так сказать, сами следят за логической целостностью базы. Н>То есть все твои сущности знают о том, как сохранять себя в БД?
Эммм... Как сохранить себя в БД, знают сущности в любом ORM, в том же Hibernate — у всех есть метод save(). Я думаю, мой пример выше разъяснил мою позицию.
Сам же и начал.
D>>Это очевидно. А теперь изволь изложить, как бы ты реализовал мой пример — когда админам и обычным юзерам (и те и другие коннектятся к сайту из swing-клиента) нужно отдавать одни и те же структуры данных, за исключением чувствительной информации, которую юзерам видеть не полагается. G>Для целей presentation обычно вводятся структуры, отличающиеся от модели данных. В них и будет различие.
Эти структуры и являются по сути DTO; неважно, как ты их при этом называешь. Когда я делал сайты, использующие XSLT, промежуточный XML также являлся по сути DTO. И изменения так или иначе приходится делать в разных местах (поменял entity — поменял XSLT).
G>Тольео с БЛ это никак не связно.
Я этого и не утверждал.
D>>То есть, в каждом месте, где выполняется a->setB(b), не забывать добавлять b->countAs++? Да, действительно меньше дублирования. И очень повышает maintainability. G>Приведи адекватное обоснование необходимости таких действий.
Не понял вопроса. В таблице b есть счётчик count_as. Нужно держать его в актуальном состоянии. Всё. Какое ещё тебе нужно обоснование? Можешь посмотреть пример посложнее, я только что запостил
Здравствуйте, dimgel, Вы писали:
D>Извольте, вот пример с миксином TreeNode.
По той причине, что миксины того уровня, которого они есть в Scala, мне технически недоступны, я ничего путного сказать не могу. Повторюсь, однако, что я выступаю против помещения логики в бизнес-объекты.
D>Эммм... Как сохранить себя в БД, знают сущности в любом ORM, в том же Hibernate — у всех есть метод save(). Я думаю, мой пример выше разъяснил мою позицию.
А вот и нет. В том же Hibernate метод save() есть у объекта Session, который суть Identity Map и Unit of Work, все сущности знать не знают о том, что где-то вообще есть БД и что их туда сохраняют. Это не их дело.
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, dimgel, Вы писали:
D>Счётчики и ссылки — лишь простой пример. Меня удивляет, что вы все к нему привязались. Извольте, вот пример с миксином TreeNode: D>1) он добавляет к классу поля parent, numChildren, numDescendants; D>2) при добавлении в иерархию он корректирует numChildren своего родителя и numDescendants своих предков; D>3) также он синхронизирует данные таблицы замыкания (PK(ancestorid, descendantid), distance).
D>Выносить всю логику из пунктов (2) и (3) в контроллеры — значит дублировать её во множестве контроллеров для всех entities, являющихся TreeNode. Или делать отдельные методы в helper-классах, что всё равно дико: всё-таки гораздо понятнее и более ожидаемо написать node1.addChild(node2), чем TreeController.addChild(node1, node2). Все вот эти SomethingController, плодящиеся как грибы после дождя, если отказаться от активных entities, дико раздражают.
Странно... Носить все время с собой деревья? Во-первых, схема хранения деревьев в БД может отличаться от схемы хранения в BL. Во-вторых, практически в 90 процентах случаях ноды как деревья не обрабатываются. Списки и объекты как сущности используются значительно чаще.
Вобщем, моё IMHO — пример плохой.
D>Эммм... Как сохранить себя в БД, знают сущности в любом ORM, в том же Hibernate — у всех есть метод save(). Я думаю, мой пример выше разъяснил мою позицию.
Значит ты говоришь об архитектуре, которая должна быть совместима с конкретной ORM. (я ничего не имею против, ибо главное результат ).
Здравствуйте, Нахлобуч, Вы писали:
Н>Здравствуйте, dimgel, Вы писали:
D>>Извольте, вот пример с миксином TreeNode.
Н>По той причине, что миксины того уровня, которого они есть в Scala, мне технически недоступны, я ничего путного сказать не могу.
Ну типа множественного наследования.
Н>Повторюсь, однако, что я выступаю против помещения логики в бизнес-объекты.
Аргументов пока не вижу.
Забавно, сам я постоянно привожу аргументы "против" (в данном случае — самого IT, посты которого я очччень внимательно прочитал в своё время от самого сотворения RSDN), чтобы привести им контрпримеры. В то же время мои оппоненты до такой мелочи практически никогда не опускаются. Тут не КСВ, товарищи.
Н>А вот и нет. В том же Hibernate метод save() есть у объекта Session, который суть Identity Map и Unit of Work, все сущности знать не знают о том, что где-то вообще есть БД и что их туда сохраняют. Это не их дело.
Да, это я попутал, сам уже вспомнил, что Hibernate работает с POJO. Но то, что я тут защищаю, — тоже не метод save(), внутренняя логика entities у меня может работать только с интерфейсами других entities. (Как в триггеры таблиц — только с данными других таблиц, в этом была моя ранее приведённая аналогия.)
Здравствуйте, GlebZ, Вы писали:
GZ>Странно... Носить все время с собой деревья?
Нет, конечно. Они могут быть большие. Но если вообще отвязаться от факта наличия ORM, логика TreeNode.addChild(x) должна делать именно это — пройтись по своим предкам и увеличить numDescendants, а у себя увеличить numChildren и numDescendants. Так что некий минимум в памяти всё равно будет.
GZ>Во-первых, схема хранения деревьев в БД может отличаться от схемы хранения в BL.
С этим не сталкивался. Но если речь идёт о чём-то в духе паттернов Domain Model + Data Mapper, то как раз в этом случае сам бог велел не замыкаться на разделении данных и логики, а сделать нормальную ООП-систему с инкапсуляцией.
GZ>Во-вторых, практически в 90 процентах случаях ноды как деревья не обрабатываются. Списки и объекты как сущности используются значительно чаще.
Вот этого не понял. Небольшие деревья (например, категории чего-либо) частенько выводятся целиком. Если речь идёт о списке детей конкретного узла, дык никто не заставляет загружать всё остальное.
GZ>Вобщем, моё IMHO — пример плохой.
Жизненный пример плохим быть не может. В кывте вон самая главная вещь — дерево.
D>>Эммм... Как сохранить себя в БД, знают сущности в любом ORM, в том же Hibernate — у всех есть метод save(). Я думаю, мой пример выше разъяснил мою позицию. GZ>Значит ты говоришь об архитектуре, которая должна быть совместима с конкретной ORM. (я ничего не имею против, ибо главное результат ).
Эт я попутал, уже написал выше. По возможности я таких привязок стараюсь не делать. Хотя тот факт, что я из одних entities обращаюсь к другим, приводит к ньюансам в реализации. К примеру спрашивал я когда-то на форуме java, как заинжектить session в entity, чтобы обратиться к другому entity по id.
Здравствуйте, dimgel, Вы писали:
D>>>Это очевидно. А теперь изволь изложить, как бы ты реализовал мой пример — когда админам и обычным юзерам (и те и другие коннектятся к сайту из swing-клиента) нужно отдавать одни и те же структуры данных, за исключением чувствительной информации, которую юзерам видеть не полагается. G>>Для целей presentation обычно вводятся структуры, отличающиеся от модели данных. В них и будет различие. D>Эти структуры и являются по сути DTO; неважно, как ты их при этом называешь. Когда я делал сайты, использующие XSLT, промежуточный XML также являлся по сути DTO. И изменения так или иначе приходится делать в разных местах (поменял entity — поменял XSLT).
Не являются, в MVVM viewmodel не является DTO хотя и содержит данные, при использовании MVP DTO чаще всего не нужны.
Не всегда presentation структуры является DTO по фаулеру.
D>>>То есть, в каждом месте, где выполняется a->setB(b), не забывать добавлять b->countAs++? Да, действительно меньше дублирования. И очень повышает maintainability. G>>Приведи адекватное обоснование необходимости таких действий.
D>Не понял вопроса. В таблице b есть счётчик count_as. Нужно держать его в актуальном состоянии. Всё. Какое ещё тебе нужно обоснование? Можешь посмотреть пример посложнее, я только что запостил
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, GlebZ, Вы писали:
GZ>>Странно... Носить все время с собой деревья?
D>Нет, конечно. Они могут быть большие. Но если вообще отвязаться от факта наличия ORM, логика TreeNode.addChild(x) должна делать именно это — пройтись по своим предкам и увеличить numDescendants, а у себя увеличить numChildren и numDescendants. Так что некий минимум в памяти всё равно будет.
С чего ты это взял что это необходимо? Показщать пример где дерево работет без numChildren и numDescendants.
GZ>>Во-первых, схема хранения деревьев в БД может отличаться от схемы хранения в BL. D>С этим не сталкивался. Но если речь идёт о чём-то в духе паттернов Domain Model + Data Mapper, то как раз в этом случае сам бог велел не замыкаться на разделении данных и логики, а сделать нормальную ООП-систему с инкапсуляцией.
Главное чтобы было ООП... как наивно. Интересно сколько еще неокрепших умов повелось на такой развод?
Здравствуйте, gandjustas, Вы писали:
G>Если count_as можно посчитать из имеющихся данных, то не нужно оно вообще. G>Нарушение нормализации никогда бесплатным не бывает, это не повод делать хреновый дизайн приложения.
Ню-ню. Мы, насяльника, про нормализацию и не слыхивали.
Собственно, я и не сомневался, что щас начнутся съезды с темы. Счётчик нужен, точка. Рассказывать тебе свои задачи я не намерен, но я хорошо посмеюсь, если ты предложишь der Igel-у убрать счётчик постов в форумах RSDN или суммарного количества ответов на сообщение, и расчитывать их динамически, суммируя при каждом запросе.
Здравствуйте, dimgel, Вы писали:
D>Аргументов пока не вижу.
Да какие тут аргументы.
Одна из самых главных задач, возникающих при разработке ПО (кроме собственно его поставки) -- это борьба с Essential Complexity (EC) и сведение Accidental Complexity (AC) к минимуму. Поскольку EC присуща задаче как таковая и никуда от нее не деться, единственный способ "борьбы" с ней -- ее перемещение и растаскивание по уровням абстракции. Для того, чтобы с этими абстракциями было удобно работать и чтобы они не привносили ненужной AC, необходимо уменшьать связность и увеличивать сцепления (Coupling и Cohesion соответственно; возможно, перевод не самый очевидный). Чтобы этого достичь необходимо, как минимум, соблюдать 5 принципов, объединенных аббревиатурой SOLID:
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, gandjustas, Вы писали:
G>>Если count_as можно посчитать из имеющихся данных, то не нужно оно вообще. G>>Нарушение нормализации никогда бесплатным не бывает, это не повод делать хреновый дизайн приложения.
D>Ню-ню. Мы, насяльника, про нормализацию и не слыхивали.
D>Собственно, я и не сомневался, что щас начнутся съезды с темы. Счётчик нужен, точка.
Молодец сам себе придумал проблемы, а потом придумываешь супер-мега архитектурные решения чтобы проблемы побороть.
D>Рассказывать тебе свои задачи я не намерен, но я хорошо посмеюсь, если ты предложишь der Igel-у убрать счётчик постов в форумах RSDN или суммарного количества ответов на сообщение, и расчитывать их динамически, суммируя при каждом запросе.
Пусть расчет будет в триггерах БД, совершенно не нужно это делать в программе.
Н>Single responsibility principle Н>Interface segregation principle Н>
Н>Твой подход с помещением логики в бизнес-объекты нарушает как минимум пункты S и I.
Насчёт S — возможно, хотя зависит от трактовки. То, что сеть объектов сама следит за собственной логической целостностью... Ну, во-первых, так и foreign keys в базе данных можно притянуть как нарушение этого принципа. Мол база должна хранить объекты и точка. А в базе, кроме этого, дохрена ещё всякого, включая триггеры, которые я не жалую, но без которых частенько никуда, если доходит до оптимизаций. Не навернутся ли случаем все эти principles разом при первом же шаге в сторону, если так отчаянно им следовать?
Насчёт I — не понял, где я тут его нарушаю. Скорее наоборот, я упрощаю интерфейсы и минимизирую код контроллеров-прокладок. Вместо SomeController::doOn(SomeEntity _this), я тупо делаю SomeEntity::do(). Уменьшаю лишние сущности, про которые ещё и забыть можно (если не использовать package visibility, чтобы отдельные методы entity можно было вызвать только из контроллера; но это как-то не очень попахивает).
Н>Резюмирую: плюсы пропагандируемого мною подхода в том, что снижается сложность и уменьшается связность.
Пока что это одни слова. Громкие слова, хорошо известные, но без примеров. Я повторю в третий (или четвёртый?) раз свой пример со счётчиком ссылок: где тут снижение сложности и уменьшение связности, если вместо a.setB(b) нужно каждый раз писать { a.setB(b); b.countAs++; } либо abController.aSetB(a, b), м? С деревом (реальным примером) будет дерьмовее в разы — там больше операций и как следствие — больше букаф и больше шансов что-нибудь забыть.
Здравствуйте, dimgel, Вы писали:
D>Нет, конечно. Они могут быть большие. Но если вообще отвязаться от факта наличия ORM, логика TreeNode.addChild(x) должна делать именно это — пройтись по своим предкам и увеличить numDescendants, а у себя увеличить numChildren и numDescendants. Так что некий минимум в памяти всё равно будет.
Но к примеру, перенос веток удобнее делать SQL запросом в БД, а не в оперативной памяти за которым следует лавинообразный update. Вынесенная логика вполне может это обеспечить.
GZ>>Во-первых, схема хранения деревьев в БД может отличаться от схемы хранения в BL. D>С этим не сталкивался.
Например, документы могут быть провязаны несколькими независимыми деревьями рубрик. И уже непонятно, документы — часть рубрики, или рубрики — часть документа.
D>Но если речь идёт о чём-то в духе паттернов Domain Model + Data Mapper, то как раз в этом случае сам бог велел не замыкаться на разделении данных и логики, а сделать нормальную ООП-систему с инкапсуляцией.
Для чего это все надо... Все эти разделения...
Немного теории. Что такое программа. Это трансформация входных данных, в выходные. Только слишком сложно записать сложную программу со многими состояниями в одну трансформацию. Поэтому ее разделяют на компоненты. Компоненты — это те же подпрограммы которые трансформируют входные данные в выходные. Для правильного распределения функций в компоненте, существует понятия Low coupling и HighCohesion. В свою очередь, дабы упорядочить, мы разделяем компоненты на слои. Слой — это набор однотипных программ(компонентов), подчиненных одной концепции, и изолирующие одни компоненты от других. Все ради борьбы со сложностью.
Если мы посмотрим на общение между слоями то он описывается контрактом, который состоит из данных (параметризуемых или entity в том или ином виде), и собственно рычага который мы должны дернуть, чтобы это все зафурычило. Теоретически, каждый слой заказывает данные в формате прошлого слоя, трансформирует, и отдает в формате нужных для следующего слоя. На практике, такая классика — избыточна. Во первых, борьба со сложностью вызывает избыточное кодирование. Во вторых, существуют продукты, которые почти декларативно решают проблему хранения состояния (то бишь ORM). То есть выполняют роль слоя DAL. В случае, если состояние почти освобождено от логики(почти, потому что даже типизация также реализация логики), мы состояние чаще можем проносить в неизменном виде практически через все слои. Прозрачно сериализовать и т.д. В случае если у нас навешана логика на состояние — то у нас меньше шансов перенести объект между слоями. И тут есть вопрос, которые почему-то обходят. Вопрос инструментария. В случае если используется ORM типа Hibernate — провоцируется создание полновесных объектов в стиле OOP. Технологически, в данной ORM все для этого присутсвует. Мы вполне можем реализовать сколь угодно сложную логику в BLL, и все недостатки хранения(а это процесс наиболее сложный и дорогой) решить инструментарием ORM. Он не завязан на BLL компоненты, благо реализуется другими средствами. А наверх из BLL уже выдавливать специализированные DTO. В случае если подобная ORM не используется, то значительно проще использовать entity без логики. Так как в DAL(который строится другими средствами), мы вполне можем их обработать не связываясь с уровнем BLL, и варьировать эффективность получения/сохранения из/в БД.
GZ>>Во-вторых, практически в 90 процентах случаях ноды как деревья не обрабатываются. Списки и объекты как сущности используются значительно чаще. D>Вот этого не понял. Небольшие деревья (например, категории чего-либо) частенько выводятся целиком. Если речь идёт о списке детей конкретного узла, дык никто не заставляет загружать всё остальное.
Выводятся и обрабатываются как список. Типо дай мне детей независимо от уровня вложенности с фильтром таким-то.
GZ>>Вобщем, моё IMHO — пример плохой. D>Жизненный пример плохим быть не может. В кывте вон самая главная вещь — дерево.
Не думаю что оно реализовано именно так.
Здравствуйте, dimgel, Вы писали:
D>То, что сеть объектов сама следит за собственной логической целостностью... Ну, во-первых, так и foreign keys в базе данных можно притянуть как нарушение этого принципа. Мол база должна хранить объекты и точка.
Чтобы сеть могла следить за логической целостностью в общем случае она может вырасти до размеров БД. Мы до сих пор говорим об оптимизации?
Здравствуйте, dimgel, Вы писали:
D>Ну, во-первых, так и foreign keys в базе данных [...] если доходит до оптимизаций.
Куда это тебя понесло?
D>Не навернутся ли случаем все эти principles разом при первом же шаге в сторону, если так отчаянно им следовать?
Смотря что ты подразумеваешь под "навернуться". Если ими руководствоваться, то ничего плохого не случится, а если какой-то случай объективно требует специального неуставного решения -- так тому и быть.
D>Насчёт I — не понял, где я тут его нарушаю. Скорее наоборот, я упрощаю интерфейсы и минимизирую код контроллеров-прокладок. Вместо SomeController::doOn(SomeEntity _this), я тупо делаю SomeEntity::do(). Уменьшаю лишние сущности, про которые ещё и забыть можно (если не использовать package visibility, чтобы отдельные методы entity можно было вызвать только из контроллера; но это как-то не очень попахивает).
Interface Segregation -- это "клиенты не должны зависеть от контрактов, которые они не используют". Контракты должны обладать максимальной степенью сцепления. В твоем случае получив SomeEntity пред глазами возникает ажно целый ворох методов, от do() до save().
D>где тут снижение сложности и уменьшение связности, если вместо a.setB(b) нужно каждый раз писать { a.setB(b); b.countAs++; } либо abController.aSetB(a, b), м?
Коль скоро далее следует "реальный пример", я могу полагать, что этот пример -- нереальный. Так что о нем не будем.
D>С деревом (реальным примером) будет дерьмовее в разы — там больше операций и как следствие — больше букаф и больше шансов что-нибудь забыть.
Сферические деревья в вакууме, да? Я правда не понимаю, как можно что-то забыть, когда у тебя в руках два объекта TreeNode и ссылка на ITreeManipulationService, который умеет делать с деревьями все, что душа пожелает.
Все равно какой-то не очень жизненный пример. Если взять что-то более реальное -- ту же модель файловой системы, то там куда прикажешь заталкивать методы копирования и переименования файлов?
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, dimgel, Вы писали:
D>>Нет, конечно. Они могут быть большие. Но если вообще отвязаться от факта наличия ORM, логика TreeNode.addChild(x) должна делать именно это — пройтись по своим предкам и увеличить numDescendants, а у себя увеличить numChildren и numDescendants. Так что некий минимум в памяти всё равно будет. GZ>Но к примеру, перенос веток удобнее делать SQL запросом в БД, а не в оперативной памяти за которым следует лавинообразный update. Вынесенная логика вполне может это обеспечить.
Да, согласен. То есть, это хороший пример, когда/почему логику операции над объектом НЕ НАДО вгонять внутрь объекта.
Контр-аргумент у меня только один, и для крупных систем он слабоват: как только у меня возникнет необходимость перетащить эту операцию в триггеры, в тот же момент я и перенесу её из entity в контроллер. А до тех пор мне к ней удобнее обращаться по "короткому синтаксису". Front controller, к которому обращаются удалённые клиенты, останется без изменений.
GZ>>>Во-первых, схема хранения деревьев в БД может отличаться от схемы хранения в BL. D>>С этим не сталкивался. GZ>Например, документы могут быть провязаны несколькими независимыми деревьями рубрик. И уже непонятно, документы — часть рубрики, или рубрики — часть документа.
На уровне базы — many-to-meny, на уровне объектов — коллекции рубрик в документах и коллекции документов в рубриках. Вроде бы, тот же hibernate с этим справляется в лоб. Но идею понял, что могут быть ситуации, когда маппинг "в лоб" приведёт к неудобным вспомогательным entity-классам.
GZ>В случае, если состояние почти освобождено от логики(почти, потому что даже типизация также реализация логики), мы состояние чаще можем проносить в неизменном виде практически через все слои.
Угу, именно эту точку зрения отстаивает IT. Но похоже, мы из разных болот квакаем. Из моего болота (сидя в котором, я приводил пример, когда в swing-клиент нужно отдавать разные данные админу и обычному юзеру) напрашивается вопрос: а нужно ли проносить состояние (полное, причём) через все слои в неизменном виде? Мне вот оказалось нужно прямо противоположное. Данная постановка вопроса означает, что BLL frontend сформулирован в терминах DTO. А что там внутри — объекты, прибитые гвоздями к Hibernate, или заумный Data Mapper, это отдельный вопрос, совершенно неважный с точки зрения пользователей BLL. То есть, данный сценарий использования DTO повышает инкапсуляцию.
Что же касается потрохов BLL и ниже, то твой пример выше я (надеюсь) понял. Возможно, в действительно больших системах (если считать в "десятках/сотнях одновременных программистов" ) этот подход безальтернативен, просто я с таковыми не сталкивался.
Ну и если задача такова, что полное состояние можно и нужно отдавать клиентам BLL, тогда да, POJO без логики приведут к очевидному выигрышу, т.к. в них можно будет формулировать и фронтенд, и потроха BLL. Скажем, если речь идёт об обычных сайтах, в которых отсечение лишних (чувствительных) данных выполняется фактически в процессе генерации html-кода, т.е. слоем представления, выполняющемся в том же процессе, что и BL. Гы, но этот случай вырожденный (язвлю, устал от сайтостроительства). Многие десктопные приложения похожи на сайт в том плане, что всё в одном процессе: и данные, и логика представления. А вот в распределённых системах мне такое щастье не встречалось, там DTO рулит.
D>>Жизненный пример плохим быть не может. В кывте вон самая главная вещь — дерево. GZ>Не думаю что оно реализовано именно так.
Дык я этого и не утверждаю. Просто взяли хороший пример задачи — и поехали по вариантам.
Сериализация и маппинг рулят! В Java готовые инструментарии есть практически под всё.
А to/from это вообще предельно неудобный антипаттерн. Я его "изобрел" где-то на первом году профессионального программирования, но быстро обнаружил на сколько он не рулит.
И очень повышает maintainability. 
).
