Здравствуйте, IT, Вы писали:
B>>Никто не уговаривает тебя его пользовать. Но отрицать факты что есть паттерн DTO и что у него есть своя ниша не имеет смысла. IT>Я где-то утверждал обратное?
Да, в следующем же предложении.
IT>>>Я не понимал пользы от DTO ни до Фаулера, ни после B>>Счастливчик, ты не имел дело с говноспецификациями вроде EJB? По-моему существует ряд ситуаций, где вполне можно применить DTO. Но я сейчас не хочу высасывать примеры из пальца, так как реально с такой надобностью не сталкивался.
IT>DTO очень просто превращаются в Business Entities. Казалось бы разница небольшая, но это уже совсем другое дело.
Это не всегда имеет смысл. Например у меня есть бизнес сущности покрывающие необходимую логику моего приложения. И мне надо заинтегрится с другой системой. Сущности которой имеют радикално отличную структуру от моей. Но тем неменее скалярные данные сходны. Мучать сериализаторы так чтобы трансформировать структуру бизнес сущностей может быть очень накладно. Поэтому решение сгенерить DTO и написать трансформацию одних классов в другие может быть более оптимальным.
То же самое и Фаулер пишет:
One case where it is useful to use something like a DTO is when you have a significant mismatch between the model in your presentation layer and the underlying domain model
Здравствуйте, Blazkowicz, Вы писали:
IT>>Я где-то утверждал обратное? B>Да, в следующем же предложении.
Это где же
IT>>DTO очень просто превращаются в Business Entities. Казалось бы разница небольшая, но это уже совсем другое дело.
B>Это не всегда имеет смысл. Например у меня есть бизнес сущности покрывающие необходимую логику моего приложения.
Для начала хорошо бы разобраться что ты понимаешь под бизнес сущностью. В моём понимании бизнес логике в бизнес сущностях вообще делать нечего.
B>И мне надо заинтегрится с другой системой. Сущности которой имеют радикално отличную структуру от моей. Но тем неменее скалярные данные сходны. Мучать сериализаторы так чтобы трансформировать структуру бизнес сущностей может быть очень накладно. Поэтому решение сгенерить DTO и написать трансформацию одних классов в другие может быть более оптимальным.
Этим должны заниматься мапперы. Ты предлагаешь из формата чуждого приложения всё перекладывать сначала в DTO, а уже затем в бизнес сущности. Учитывая, что у тебя структуры радикально отличные, саму задачу перевода данных из одного формата в другой тебе всё равно придётся мучать. С помощью сериализаторов, мапперов или вручную, без разницы. А если так, то один шаг здесь явно лишний.
B>То же самое и Фаулер пишет: B>
B>One case where it is useful to use something like a DTO is when you have a significant mismatch between the model in your presentation layer and the underlying domain model
Здесь Фаулер пишет не о разных приложениях с радикально отличной структурой, а о разных лэйерах. Добиться significant mismatch в этом случае надо ещё постараться. Если же модели действительно столько различны, то нужен маппер для перевод одной модели в другую, а не DTO, подходящие по структуре к одной из моделей и опять же маппер для трансофрмации этих DTO в формат другого лэйера.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Для начала хорошо бы разобраться что ты понимаешь под бизнес сущностью. В моём понимании бизнес логике в бизнес сущностях вообще делать нечего.
Если логика ограничена состоянием этой сущности, то в этой сущности логике самое место. В общем слишком категорично. Да и офтопик, можно просто продожить здесь
.
IT>Этим должны заниматься мапперы. Ты предлагаешь из формата чуждого приложения всё перекладывать сначала в DTO, а уже затем в бизнес сущности. Учитывая, что у тебя структуры радикально отличные, саму задачу перевода данных из одного формата в другой тебе всё равно придётся мучать. С помощью сериализаторов, мапперов или вручную, без разницы. А если так, то один шаг здесь явно лишний.
IT>Здесь Фаулер пишет не о разных приложениях с радикально отличной структурой, а о разных лэйерах. Добиться significant mismatch в этом случае надо ещё постараться. Если же модели действительно столько различны, то нужен маппер для перевод одной модели в другую, а не DTO, подходящие по структуре к одной из моделей и опять же маппер для трансофрмации этих DTO в формат другого лэйера.
Со всеми доводами согласен. Не согласен только с твоей категоричностью. Так что тему можно дальше не развивать.
Здравствуйте, Blazkowicz, Вы писали:
IT>>Для начала хорошо бы разобраться что ты понимаешь под бизнес сущностью. В моём понимании бизнес логике в бизнес сущностях вообще делать нечего.
B>Если логика ограничена состоянием этой сущности, то в этой сущности логике самое место. В общем слишком категорично.
Тогда хорошо бы разобраться с тем, что ты понимаешь под бизнес логикой
B>Да и офтопик, можно просто продожить здесь
Участникам этого топика продолжение уже не интересно.
IT>>Этим должны заниматься мапперы. Ты предлагаешь из формата чуждого приложения всё перекладывать сначала в DTO, а уже затем в бизнес сущности. Учитывая, что у тебя структуры радикально отличные, саму задачу перевода данных из одного формата в другой тебе всё равно придётся мучать. С помощью сериализаторов, мапперов или вручную, без разницы. А если так, то один шаг здесь явно лишний.
IT>>Здесь Фаулер пишет не о разных приложениях с радикально отличной структурой, а о разных лэйерах. Добиться significant mismatch в этом случае надо ещё постараться. Если же модели действительно столько различны, то нужен маппер для перевод одной модели в другую, а не DTO, подходящие по структуре к одной из моделей и опять же маппер для трансофрмации этих DTO в формат другого лэйера.
B>Со всеми доводами согласен. Не согласен только с твоей категоричностью. Так что тему можно дальше не развивать.
При чём тут категоричность? Это выглядит, как будто ты не согласен с формой высказывания и из-за этого отрицаешь и само содержание.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
B>>Если логика ограничена состоянием этой сущности, то в этой сущности логике самое место. В общем слишком категорично.
IT>Тогда хорошо бы разобраться с тем, что ты понимаешь под бизнес логикой
Почитал определение в википедии, ничего нового для себя не открыл, подразумеваю под бизнес логикой то же что и все. И не вижу никаких проблем возникающих при помещении некоторой части этой логики в классы описывающие-бизнес сущности.
. IT>Участникам этого топика продолжение уже не интересно.
Ну, тогда продолжим здесь. Где по-твоему распологается бизнес логика и покакой причине ей не место в сущностях?
Здравствуйте, Blazkowicz, Вы писали:
B>>>Если логика ограничена состоянием этой сущности, то в этой сущности логике самое место. В общем слишком категорично.
IT>>Тогда хорошо бы разобраться с тем, что ты понимаешь под бизнес логикой
B>Почитал определение в википедии, ничего нового для себя не открыл, подразумеваю под бизнес логикой то же что и все.
Бизнес логика, и тем более её определение в википедии, вещь весьма размытая. Но вот то, что можно поместить в business entities имеет очень чёткие ограничения. По-этому я и спрашиваю.
B>И не вижу никаких проблем возникающих при помещении некоторой части этой логики в классы описывающие-бизнес сущности.
Я тоже не вижу. Вопрос только в определении некоторости. Скажу даже больше. Именно наличие логики отличает тупые DTO от business entities.
B>>>Да и офтопик, можно просто продожить здесь
. IT>>Участникам этого топика продолжение уже не интересно. B>Ну, тогда продолжим здесь. Где по-твоему распологается бизнес логика и покакой причине ей не место в сущностях?
Бизнес логика, как общее понятие, распологается везде. В бизнес сущностях (опять же, если мы подразумеваем под этим понятием одно и тоже) не место логике, делающей эти сущности привязанными к другим частям системы. Впрочем, ты утверждаешь тоже самое. Так вот, теперь вернёмся немного назад. Вопрос. Зачем вообще нужны DTO как промежуточный тип контейнеров, если с этой задачей могут прекрасно справиться entitie? Где здесь логика? Может в неверно выбранном дизайне? Или я всё же чего-то не понимаю и действительно бывают случаи где DTO немерянно рулят?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Я тоже не вижу. Вопрос только в определении некоторости. Скажу даже больше. Именно наличие логики отличает тупые DTO от business entities.
Не только. Сущность может не содержать логики и при этом не быть DTO.
IT>Бизнес логика, как общее понятие, распологается везде. В бизнес сущностях (опять же, если мы подразумеваем под этим понятием одно и тоже) не место логике, делающей эти сущности привязанными к другим частям системы. Впрочем, ты утверждаешь тоже самое. Так вот, теперь вернёмся немного назад. Вопрос. Зачем вообще нужны DTO как промежуточный тип контейнеров, если с этой задачей могут прекрасно справиться entitie? Где здесь логика? Может в неверно выбранном дизайне?
В общем я не вижу смысла в продолжении дискуссии, так как мы с тобой высказываем одни и те же мысли разными словами.
IT>Или я всё же чего-то не понимаю и действительно бывают случаи где DTO немерянно рулят?
Ты их не видел, и я их не видел. Но ведь это не значит что их нет?
Здравствуйте, Blazkowicz, Вы писали:
IT>>Или я всё же чего-то не понимаю и действительно бывают случаи где DTO немерянно рулят? B>Ты их не видел, и я их не видел. Но ведь это не значит что их нет?
Э, нет. В отличии от тебя, мне очень хочется на них посмотреть. Реально взглянуть и увидеть приносимую ими пользу. Пока же я вижу, от DTO никакой пользы нет и их использование является результатом архитектурных косяков. Если это не так, то кто-нибудь убедите меня в обратном.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>>>Или я всё же чего-то не понимаю и действительно бывают случаи где DTO немерянно рулят? B>>Ты их не видел, и я их не видел. Но ведь это не значит что их нет?
IT>Э, нет. В отличии от тебя, мне очень хочется на них посмотреть. Реально взглянуть и увидеть приносимую ими пользу. Пока же я вижу, от DTO никакой пользы нет и их использование является результатом архитектурных косяков. Если это не так, то кто-нибудь убедите меня в обратном.
Поковырял J2EE паттерны . Имет ли смысл называть EJB2 архитектурным косяком? Спорный вопрос.
Так вот суть в том что уровень RPC и сериализации отдан полностью на откуп контейнера. И управлять сериализацией, в общем случае, никакого нормального средства нет. Вот тогда DTO и есть единственный нормальный способ трансформировать структуру бизнес сущностей в структуру оптимальную для общения с клиентом.
Кстати там есть интересный вариант "BusinessEntity inherits DTO". А вот первые четрые примера (6.1.1 — 6.2.1) поражают своей "лаконичностью".
Здравствуйте, Blazkowicz, Вы писали:
B>Поковырял J2EE паттерны . Имет ли смысл называть EJB2 архитектурным косяком? Спорный вопрос.
Судя по тому, что ты пишешь ниже, действительно спорный.
B>Так вот суть в том что уровень RPC и сериализации отдан полностью на откуп контейнера. И управлять сериализацией, в общем случае, никакого нормального средства нет. Вот тогда DTO и есть единственный нормальный способ трансформировать структуру бизнес сущностей в структуру оптимальную для общения с клиентом.
Т.е. DTO возникли тут как вынужденная мера. Значит ли это, что DTO как паттерн, закрывающий дырку в архитектуре одной из возможных систем должен теперь перекочёвывать в другие системы, где таких проблем нет?
B>Кстати там есть интересный вариант "BusinessEntity inherits DTO". А вот первые четрые примера (6.1.1 — 6.2.1) поражают своей "лаконичностью".
Мрачное зрелище.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Значит ли это, что DTO как паттерн, закрывающий дырку в архитектуре одной из возможных систем должен теперь перекочёвывать в другие системы, где таких проблем нет?
Не значит. Но мы же не знаем какая у автора ситуация.
Здравствуйте, Blazkowicz, Вы писали:
IT>>Значит ли это, что DTO как паттерн, закрывающий дырку в архитектуре одной из возможных систем должен теперь перекочёвывать в другие системы, где таких проблем нет?
B>Не значит. Но мы же не знаем какая у автора ситуация.
Не знаем. Но знаем, что речь идёт как минимум о .NET, где реальных причин, озвученных тобой выше, для использования DTO пока не обнаружено. Вывод напрашивается сам собой.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Не знаем. Но знаем, что речь идёт как минимум о .NET, где реальных причин, озвученных тобой выше, для использования DTO пока не обнаружено. Вывод напрашивается сам собой.
Oops. Извиняюсь что вмешиваюсь но что-то здесь не есть верно. Возьмем к примеру Microsoft practice&patterns здесьздесь и здесь
Теперь к вопросу о DTO. Может быть вы их не использовали(или просто не замечали что использовали), а вот я использовал достаточно часто. Основная причины которые встречались мне:
1. За один вызов я должен вернуть/обработать объект состоящий из нескольких элементарных бизнес-объектов и снизить зависимость от латентности сети. Это наиболее частое использование DTO.
2. Скрытие некоторых не предназначенных для клиента данных. Эта тема уже поднималась на форумах. Не все данные бизнес-объектов должны быть доступны клиентам или должны быть доступны в режиме read-only. Усложняет архитектуру, и я бы не советовал использовать это без явных требований.
3. Структура используемая в сервере не может быть использована на клиенте. В основном такое встречается в statefull приложениях. Ну например, мне надо было сделать сложновычислимую задачу. Для того, чтобы вся эта шняга быстро вычислялась бизнес-объекты были связаны между собой прямыми указателями. Ессно, на клиенте бизнес-объекты должны быть связаны через идентификаторы. Это и обусловило разность типов на сервере и клиенте.
4. Кэширование. Размер полных бизнес-объектов был достаточно большой. Кэшировались только те части объекта которые наиболее часто используемы, а не полностью объект. Это сильно повысило эффективность кэша, но и обусловило построение управляемого DTO.
5. Независимость сервера. Достаточно редкая вещь. Было еще развивающееся решение когда внезапно поступило срочное требование интеграции чужого web-сервера. Решение также равивалось и по данным (то бишь по бизнес-объектам). Для того чтобы обеспечить независимость по данным был сделан слой DTO который отдавал данные в виде утвержденной сторонами XML.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, снежок, Вы писали:
С>>Суть в том чтобы все get-ы и set-ы BO работали с DTO, а не приватными мемберами соответствующих свойств BO.
IT>Я вот никогда не понимал, в чём вообще смысл разделения на DTO и BO? Потому что Фаулер так сказал?
Это разные концептуальные сущности.
DTO — то, что между чем-то передаётся, BO — то, что внутри бизнес-логики.
Хотя на физическом уровне они могут быть очень похожи, это и понятно, т.к. информацию они представляют одинаковую. Поэтому получается палка о двух концах.
С одной стороны, либо ты даёшь этим двум концептуальным сущностям одно представление в программе, тогда получается меньше кода, причём кода "тупого", с другой стороны приходится затыкать щели типа следующих: в BO это вычисляемое значение хорошо бы закэшировать, а в DTO его, конечно, передавать не надо; в BO хорошо бы это значение хранить в миллисекундах, а в DTO его надо хранить в секундах и т.д.
С другой стороны, ты можешь честно дать этим двум сущностям два представления, и честно писать много "тупого" кода. Тогда можно совершенно "законно" изменять либо одно, либо второе представление. Этот вариант получается "чище".
Самые сложные уже вопросы: когда как делать? когда плюсы варианта перевесят минусы? и т.д.
Гипертрофированная аналогия на твой вопрос: вот у нас есть "треугольник", который характеризуется 3 точками, и есть "круг", который тоже характеризуется 3 точками. Зачем мы будем плодить сущности и писать лишний код — сделам на них один класс с 2 наборами функций, один работает как с треугольником, второй — как с кругом...
Здравствуйте, remark, Вы писали:
IT>>Я вот никогда не понимал, в чём вообще смысл разделения на DTO и BO? Потому что Фаулер так сказал?
R>Это разные концептуальные сущности. R>DTO — то, что между чем-то передаётся, BO — то, что внутри бизнес-логики.
А зачем вообще нужно это разделение? По мне так оно выглядит очень натянуто.
R>Хотя на физическом уровне они могут быть очень похожи, это и понятно, т.к. информацию они представляют одинаковую. Поэтому получается палка о двух концах. R>С одной стороны, либо ты даёшь этим двум концептуальным сущностям одно представление в программе, тогда получается меньше кода, причём кода "тупого", с другой стороны приходится затыкать щели типа следующих: в BO это вычисляемое значение хорошо бы закэшировать, а в DTO его, конечно, передавать не надо;
Решается элементарно атрибутами сериализации и/или маппинга.
R>в BO хорошо бы это значение хранить в миллисекундах, а в DTO его надо хранить в секундах и т.д.
Решается добавлением свойства предоставляющего информацию в секунда.
R>Самые сложные уже вопросы: когда как делать? когда плюсы варианта перевесят минусы? и т.д.
Пока что для меня очевидно следующее: DTO — это лишний и скорее всего ошибочый элемент в архитектуре системы.
R>Гипертрофированная аналогия на твой вопрос: вот у нас есть "треугольник", который характеризуется 3 точками, и есть "круг", который тоже характеризуется 3 точками. Зачем мы будем плодить сущности и писать лишний код — сделам на них один класс с 2 наборами функций, один работает как с треугольником, второй — как с кругом... R>
Не, это аналогия на какой-то другой вопрос
R>
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, GlebZ, Вы писали:
IT>>Не знаем. Но знаем, что речь идёт как минимум о .NET, где реальных причин, озвученных тобой выше, для использования DTO пока не обнаружено. Вывод напрашивается сам собой. GZ>Oops. Извиняюсь что вмешиваюсь но что-то здесь не есть верно. Возьмем к примеру Microsoft practice&patterns GZ>здесьздесь и здесь
Microsoft practice & patterns хорошая пища для размышления, но не рукодство к действию. Например, те же датасеты в своё время тоже были поданы MS как решение всех наших проблем.
GZ>Теперь к вопросу о DTO. Может быть вы их не использовали(или просто не замечали что использовали), а вот я использовал достаточно часто.
Может быть. А может быть я их использовал ещё когда и названия такого не было. А когда назнвание им такое придумали, то я их уже не использовал. Т.е. получается, что действительно не использовал
GZ>Основная причины которые встречались мне: GZ>1. За один вызов я должен вернуть/обработать объект состоящий из нескольких элементарных бизнес-объектов и снизить зависимость от латентности сети. Это наиболее частое использование DTO.
Есть какие-нибудь исследования по этому поводу? Например, насколько менее эффективно вернуть за одни запрос не 100 байт, а 150? А если подкрутить атрибуты сериализации? Или, например, что быстрее, передать 10000 объектов по 100 байт, по 150 байт, а подкрутить, а, в случае реальных проблем, организовать специализированный поток данных прямо из датаридера в объектную модель клиента, минуя ненужные этапы сериализации и, если уж ну очень большие проблемы, упаковывая поток перед отправкой? Кто-нибудь проводил такие тесты? Или 10% мнимого выигрыша стоят повсеместного дублирования кода?
GZ>2. Скрытие некоторых не предназначенных для клиента данных.
Не передавай их и всё. В чём проблема?
GZ>Эта тема уже поднималась на форумах. Не все данные бизнес-объектов должны быть доступны клиентам или должны быть доступны в режиме read-only. Усложняет архитектуру, и я бы не советовал использовать это без явных требований.
О каких клиентах идёт речь? О своих собственных? Тогда это уже, простите, паранойя. Если же речь идёт о клиентах, которые ещё не написаны и будут написаны не нами, то разработка такого интерфейса — это сама по себе отдельная задача и то, что в результате будет использоваться та же объектная модель совсем не факт. Скорее всего вообще будет использоваться XML.
GZ>3. Структура используемая в сервере не может быть использована на клиенте. В основном такое встречается в statefull приложениях. Ну например, мне надо было сделать сложновычислимую задачу. Для того, чтобы вся эта шняга быстро вычислялась бизнес-объекты были связаны между собой прямыми указателями. Ессно, на клиенте бизнес-объекты должны быть связаны через идентификаторы. Это и обусловило разность типов на сервере и клиенте.
Как я понимаю здесь речь идёт о разных объектных моделях. Разные модели совершенно спокой стыкуются между собой по схеме Model1 -> Mapping -> Model2. Конечно можно залудить и Model1 -> Mapping1 -> DTO -> Mapping2 -> Model2, но какой смысл?
GZ>4. Кэширование. Размер полных бизнес-объектов был достаточно большой. Кэшировались только те части объекта которые наиболее часто используемы, а не полностью объект. Это сильно повысило эффективность кэша, но и обусловило построение управляемого DTO.
Не понял.
GZ>5. Независимость сервера. Достаточно редкая вещь. Было еще развивающееся решение когда внезапно поступило срочное требование интеграции чужого web-сервера. Решение также равивалось и по данным (то бишь по бизнес-объектам). Для того чтобы обеспечить независимость по данным был сделан слой DTO который отдавал данные в виде утвержденной сторонами XML.
Для таких вещей на стороне клиента пишутся (в терминологии MS) агенты. То же самое что DAL, только данные вычитываются не из датаридеров, а из формата внешней системы.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Microsoft practice & patterns хорошая пища для размышления, но не рукодство к действию. Например, те же датасеты в своё время тоже были поданы MS как решение всех наших проблем.
Там есть политика где они напирают на определенные решения. Но неверных решений, по крайней мере с моей точки зрения, я не замечал.
GZ>>1. За один вызов я должен вернуть/обработать объект состоящий из нескольких элементарных бизнес-объектов и снизить зависимость от латентности сети. Это наиболее частое использование DTO. IT>Есть какие-нибудь исследования по этому поводу? Например, насколько менее эффективно вернуть за одни запрос не 100 байт, а 150? А если подкрутить атрибуты сериализации? Или, например, что быстрее, передать 10000 объектов по 100 байт, по 150 байт, а подкрутить, а, в случае реальных проблем, организовать специализированный поток данных прямо из датаридера в объектную модель клиента, минуя ненужные этапы сериализации и, если уж ну очень большие проблемы, упаковывая поток перед отправкой? Кто-нибудь проводил такие тесты? Или 10% мнимого выигрыша стоят повсеместного дублирования кода?
Ты не понял написанного. Я говорю именно о кол-ве вызовов и латентности сети. Поясню для примера. Есть у нас задача получить документ с реквизитами и прикрепленными файлами. Можно раздельно вызвать функцию получить документ, а потом функцию получить тот или иной реквизит не входящий в бизнес-объект а потом функцию с файлами. А можно вызвать одну функцию которая возвращает все вышесказанное но в виде единого объекта. И именно этот единый объект (который представляет собой некоторое дерево бизнес-объектов) и есть Data Transfer Object.
GZ>>2. Скрытие некоторых не предназначенных для клиента данных. IT>Не передавай их и всё. В чём проблема?
Именно для этого и делается некоторый презентационный слой который генерит DTO для клиента.
GZ>>Эта тема уже поднималась на форумах. Не все данные бизнес-объектов должны быть доступны клиентам или должны быть доступны в режиме read-only. Усложняет архитектуру, и я бы не советовал использовать это без явных требований. IT>О каких клиентах идёт речь? О своих собственных? Тогда это уже, простите, паранойя. Если же речь идёт о клиентах, которые ещё не написаны и будут написаны не нами, то разработка такого интерфейса — это сама по себе отдельная задача и то, что в результате будет использоваться та же объектная модель совсем не факт. Скорее всего вообще будет использоваться XML.
Прекрасно. И эта задача называется создание DTO.
GZ>>3. Структура используемая в сервере не может быть использована на клиенте. В основном такое встречается в statefull приложениях. Ну например, мне надо было сделать сложновычислимую задачу. Для того, чтобы вся эта шняга быстро вычислялась бизнес-объекты были связаны между собой прямыми указателями. Ессно, на клиенте бизнес-объекты должны быть связаны через идентификаторы. Это и обусловило разность типов на сервере и клиенте. IT>Как я понимаю здесь речь идёт о разных объектных моделях. Разные модели совершенно спокой стыкуются между собой по схеме Model1 -> Mapping -> Model2. Конечно можно залудить и Model1 -> Mapping1 -> DTO -> Mapping2 -> Model2, но какой смысл?
Это была вынужденная мера.
Давай посмотрим а что такое программная система со слоями и DTO. Программная система — это некоторая трансформация между слоем данных вплоть до формы доступной пользользователю и в обратную сторону. DTO — это всего лишь частный случай выделенный в отдельный паттерн в силу некоторых доп. условий. DTO — есть трансформация модели бизнес-объектов между сервером и клиентом. Она концептуально отличается от других трансформаций так как на нее налагаются требования по пересылке между процессами. Если мы на клиенте можем выдержать полную модель поддерживаемую на сервере — прекрасно. Значит на реализацию DTO мы не прилагаем усилий, и оно реализуется стандартными средсвами сериализации. Если это неэффективно или например, невозможно сделать, тут мы вспоминаем о таковом паттерне.(или же не догадываясь об этом, реализуем его-же ).
GZ>>4. Кэширование. Размер полных бизнес-объектов был достаточно большой. Кэшировались только те части объекта которые наиболее часто используемы, а не полностью объект. Это сильно повысило эффективность кэша, но и обусловило построение управляемого DTO. IT>Не понял.
Существует некоторый бизнес-объект который в полной мере содержит пару десятков килобайт данных. На сервере все работает прекрасно, так как там нет хранения состояния как такового. После каждого запроса состояние теряется, и соответсвенно сервер достаточно масштабируем. Но также есть клиент в котором для повышения эффективности есть некоторая система кэширования. Хранить полный объект в кэше — достаточно накладно (поскольку в роли клиента выступает web-сервер). Соответвенно, для того чтобы повысить эффективность, модель работы изменена. Есть объекты в своей полной сущности (то бишь пару десятков килобайт), а есть объекты в которых собраны наиболее часто используемые и важные поля. И кэшируются не полные объекты, а именно маленькие объекты. Соответвенно нагрузка на память была снята. Была также снята некоторая нагрузка на пересылку данных, но на фоне повышения эффективности кэша это было не так уж важно.
GZ>>5. Независимость сервера. Достаточно редкая вещь. Было еще развивающееся решение когда внезапно поступило срочное требование интеграции чужого web-сервера. Решение также равивалось и по данным (то бишь по бизнес-объектам). Для того чтобы обеспечить независимость по данным был сделан слой DTO который отдавал данные в виде утвержденной сторонами XML. IT>Для таких вещей на стороне клиента пишутся (в терминологии MS) агенты. То же самое что DAL, только данные вычитываются не из датаридеров, а из формата внешней системы.
Повторюсь. Данный клиент не наш. Он вообще был на чистом ASP. Для того чтобы отметелиться от зависимости к ним, и развиваться независимо этому клиенту и соорудили определенный свой формат. Формат между сервером и нормальным клиентом продолжал развиваться независимо по мере реализации других требований.
Здравствуйте, GlebZ, Вы писали:
IT>>Microsoft practice & patterns хорошая пища для размышления, но не рукодство к действию. Например, те же датасеты в своё время тоже были поданы MS как решение всех наших проблем. GZ>Там есть политика где они напирают на определенные решения. Но неверных решений, по крайней мере с моей точки зрения, я не замечал.
Это смотря что подразумевать под неверностью. Неоптимальное, избыточное решение тоже можно назвать неверным.
GZ>Ты не понял написанного.
Гы-гы. Конечно не понял. У меня таких проблемм с бизнес сущностями никогда не было. Надо передавать по отдельности — передаём по отдельности, надо всё вместе — передаём всё вместе.
GZ>Я говорю именно о кол-ве вызовов и латентности сети. Поясню для примера. Есть у нас задача получить документ с реквизитами и прикрепленными файлами. Можно раздельно вызвать функцию получить документ, а потом функцию получить тот или иной реквизит не входящий в бизнес-объект а потом функцию с файлами. А можно вызвать одну функцию которая возвращает все вышесказанное но в виде единого объекта. И именно этот единый объект (который представляет собой некоторое дерево бизнес-объектов) и есть Data Transfer Object.
Entity точно так же может представлять дерево. Не вижу абсолютно никакой разницы.
GZ>>>2. Скрытие некоторых не предназначенных для клиента данных. IT>>Не передавай их и всё. В чём проблема? GZ>Именно для этого и делается некоторый презентационный слой который генерит DTO для клиента.
Т.е. если тебе надо передать 5 полей, то для этого ты заведёшь DTO с 5-ю полями, если 6, то с 6-ю и так для всех 50-ти полей? Согласись, это полная чушь.
IT>>Если же речь идёт о клиентах, которые ещё не написаны и будут написаны не нами, то разработка такого интерфейса — это сама по себе отдельная задача и то, что в результате будет использоваться та же объектная модель совсем не факт. Скорее всего вообще будет использоваться XML. GZ>Прекрасно. И эта задача называется создание DTO.
Называй это как угодно, только не завбывай добавлять, что процент задач, где это действительно нужно, от общего числа трудно разглядеть даже в микроскоп.
IT>>Как я понимаю здесь речь идёт о разных объектных моделях. Разные модели совершенно спокой стыкуются между собой по схеме Model1 -> Mapping -> Model2. Конечно можно залудить и Model1 -> Mapping1 -> DTO -> Mapping2 -> Model2, но какой смысл? GZ>Это была вынужденная мера.
Чем вынужденная?
GZ>Давай посмотрим а что такое программная система со слоями и DTO. Программная система — это некоторая трансформация между слоем данных вплоть до формы доступной пользользователю и в обратную сторону. DTO — это всего лишь частный случай выделенный в отдельный паттерн в силу некоторых доп. условий. DTO — есть трансформация модели бизнес-объектов между сервером и клиентом. Она концептуально отличается от других трансформаций так как на нее налагаются требования по пересылке между процессами. Если мы на клиенте можем выдержать полную модель поддерживаемую на сервере — прекрасно. Значит на реализацию DTO мы не прилагаем усилий, и оно реализуется стандартными средсвами сериализации. Если это неэффективно или например, невозможно сделать, тут мы вспоминаем о таковом паттерне.(или же не догадываясь об этом, реализуем его-же ).
Ещё раз. Система, построенная на базе лёгких объектов (business entities) не нуждается в дополнительных транпортных объектах, т.к. с точки зрения транспорта такие объяты этими самыми DTO и являются. А с точки зрения объектной модели приложения, если не заниматься такими глупостяими как stateful и person.Save(), то BE ничем не хуже всего остального. В результате, при наличии различий в объектых моделей, лишнее переливание из пустого в порожнее не имеет никакого смысла. Можно сразу делать Model1 -> Mapping -> Model2.
GZ>>>4. Кэширование. Размер полных бизнес-объектов был достаточно большой. Кэшировались только те части объекта которые наиболее часто используемы, а не полностью объект. Это сильно повысило эффективность кэша, но и обусловило построение управляемого DTO. IT>>Не понял. GZ>Существует некоторый бизнес-объект который в полной мере содержит пару десятков килобайт данных. На сервере все работает прекрасно, так как там нет хранения состояния как такового. После каждого запроса состояние теряется, и соответсвенно сервер достаточно масштабируем. Но также есть клиент в котором для повышения эффективности есть некоторая система кэширования. Хранить полный объект в кэше — достаточно накладно (поскольку в роли клиента выступает web-сервер). Соответвенно, для того чтобы повысить эффективность, модель работы изменена. Есть объекты в своей полной сущности (то бишь пару десятков килобайт), а есть объекты в которых собраны наиболее часто используемые и важные поля. И кэшируются не полные объекты, а именно маленькие объекты. Соответвенно нагрузка на память была снята. Была также снята некоторая нагрузка на пересылку данных, но на фоне повышения эффективности кэша это было не так уж важно.
Всё равно не понял. Какое это имеет отношение к DTO? Если у тебя уже есть маленькие объекты, которые ты кешируешь, ну так и гоняй их туда сюда. В чем проблема?
IT>>Для таких вещей на стороне клиента пишутся (в терминологии MS) агенты. То же самое что DAL, только данные вычитываются не из датаридеров, а из формата внешней системы. GZ>Повторюсь. Данный клиент не наш. Он вообще был на чистом ASP. Для того чтобы отметелиться от зависимости к ним, и развиваться независимо этому клиенту и соорудили определенный свой формат. Формат между сервером и нормальным клиентом продолжал развиваться независимо по мере реализации других требований.
Я тоже повторюсь. DTO, как затыкание косяков, может оказаться вполне оправданной вещью. Только давай отдавать себе отчёт, что косяк он и есть косяк. В вашем случае — это использование дремучего ASP. Стоит переписать всё на ASP.NET и необходимость в DTO моментально отпадёт.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Решается элементарно атрибутами сериализации и/или маппинга. IT>Решается добавлением свойства предоставляющего информацию в секунда. IT>Пока что для меня очевидно следующее: DTO — это лишний и скорее всего ошибочый элемент в архитектуре системы.
Я там видел вы там ниже с Blazkowicz обсуждали — вы говорили про net/java и сериализацию в строки. А если поглядеть шире — например передача объекта через corba/com, структура для передачи (фактически DTO) нужна по определению, и что ты предлагаешь не делать BO, а использовать везде это DTO
Или если например говрить о interop между языками c/c++/pascal/asm и т.д. — использовать в качестве BO объекты, которые можно передавать между языками — сомнительно...
Поэтому я и говорю, что надо смотреть по ситуации — где-то примерение DTO может показаться излишним (net/java и сериализацию в строки), ну тогда можно его и не применять. В каких-то же ситуациях его применение может быть более целесообразным...
R>>
Здравствуйте, remark, Вы писали:
С>>>Суть в том чтобы все get-ы и set-ы BO работали с DTO, а не приватными мемберами соответствующих свойств BO.
IT>>Я вот никогда не понимал, в чём вообще смысл разделения на DTO и BO? Потому что Фаулер так сказал?
R>Это разные концептуальные сущности. R>DTO — то, что между чем-то передаётся, BO — то, что внутри бизнес-логики.
Фаулер, Файлер. Устранил ряд непониманий, ввел новые. Система должна оперировать сущностями (objects, entities). Система может быть разбита на составляющие. Логика может быть реализована с переходом по этим составляющим (см. документооборот). Что в данном случае использовать, DTO или BO? Или нужно смотреть под разным углом на данные, со стороны бизнес логики, или системных нужн (data transferring)?
Лично я для себя давно уже решил, что проще понятия DTO и BO слить в одно — описание данных. В таком случае отпадает проблема как транспортировки данных (не ООП-структуры очень хорошо перегоняются через границы процессов), как маппинга данных (тоже самое что и передача данных, так как маппинг и сериализация из одного теста вылеплены), так и манипулирования данных (никаких проблем с кэшами и погрузкой по необходимости, так как все контролируется нами и не чёрти какими недо-мапперами). А переконвертация одного в другое и наоборот только добавляет лишней головной боли.
Если нам не помогут, то мы тоже никого не пощадим.
Согласись, это полная чушь.
