Здравствуйте, IT, Вы писали:
IT>Это смотря что подразумевать под неверностью. Неоптимальное, избыточное решение тоже можно назвать неверным.
Паттерны также описывают показания к применению.
GZ>>Я говорю именно о кол-ве вызовов и латентности сети. Поясню для примера. Есть у нас задача получить документ с реквизитами и прикрепленными файлами. Можно раздельно вызвать функцию получить документ, а потом функцию получить тот или иной реквизит не входящий в бизнес-объект а потом функцию с файлами. А можно вызвать одну функцию которая возвращает все вышесказанное но в виде единого объекта. И именно этот единый объект (который представляет собой некоторое дерево бизнес-объектов) и есть Data Transfer Object. IT>Entity точно так же может представлять дерево. Не вижу абсолютно никакой разницы.
По крайней мере Entity нужно собирать в некоторое дерево. И дерево это всегда такое-же как оно работает на серваке. Это уже механизм.
GZ>>>>2. Скрытие некоторых не предназначенных для клиента данных. IT>>>Не передавай их и всё. В чём проблема? GZ>>Именно для этого и делается некоторый презентационный слой который генерит DTO для клиента. IT>Т.е. если тебе надо передать 5 полей, то для этого ты заведёшь DTO с 5-ю полями, если 6, то с 6-ю и так для всех 50-ти полей? Согласись, это полная чушь.
Не понял Причем тут это??? Пункт 1 перечитай. А здесь просто бизнес-объект передаваемый на клиента неэквивалентен бизнес-объекту на серваке.
IT>Называй это как угодно, только не завбывай добавлять, что процент задач, где это действительно нужно, от общего числа трудно разглядеть даже в микроскоп.
У меня это процентов 90. Документооборот — эта такая штука в которой очень много слабоструктурированной информации.
GZ>>Это была вынужденная мера. IT>Чем вынужденная?
Потому что ссылка в оперативной памяти не передается через сеть.
GZ>>Давай посмотрим а что такое программная система со слоями и DTO. Программная система — это некоторая трансформация между слоем данных вплоть до формы доступной пользользователю и в обратную сторону. DTO — это всего лишь частный случай выделенный в отдельный паттерн в силу некоторых доп. условий. DTO — есть трансформация модели бизнес-объектов между сервером и клиентом. Она концептуально отличается от других трансформаций так как на нее налагаются требования по пересылке между процессами. Если мы на клиенте можем выдержать полную модель поддерживаемую на сервере — прекрасно. Значит на реализацию DTO мы не прилагаем усилий, и оно реализуется стандартными средсвами сериализации. Если это неэффективно или например, невозможно сделать, тут мы вспоминаем о таковом паттерне.(или же не догадываясь об этом, реализуем его-же ). IT>Ещё раз. Система, построенная на базе лёгких объектов (business entities) не нуждается в дополнительных транпортных объектах, т.к. с точки зрения транспорта такие объяты этими самыми DTO и являются. А с точки зрения объектной модели приложения, если не заниматься такими глупостяими как stateful и person.Save(), то BE ничем не хуже всего остального. В результате, при наличии различий в объектых моделей, лишнее переливание из пустого в порожнее не имеет никакого смысла. Можно сразу делать Model1 -> Mapping -> Model2.
Ну давай попробую описать по другому. Что такое Data Transfer Object. Когда клиент работает с серваком по некоторому контракту. Контракт — это инертефейс вызовов и получаемые или отсылаемые данные. Данные, они же бизнес-объекты, на сервере лежат в виде экземпляров объектов связанные по ссылкам, что при переливе на клиент сделать невозможно. Для перелива на клиент нужно как минимум сформировать из объектов stream. То есть создать Data Transfer Object которые можно передать в другой процесс. Во многих случаях, это делается стандартными средствами сериализации, и мы не особо задумываемся о том, что это есть DTO. Обычно мы их так не называем, так как наши умственные и физические трудозатраты минимальны. Но существуют случаи, когда это или неэффективно, или невозможно сделать. Когда объекты для перелива не совсем равнозначны бизнес-объектам сервера. Тогда приходится уже придумывать механизм формирования DTO, и мы вспоминаем про данный паттерн как таковой. Случаи когда приходилось мне это делать (а в действительности мне чаще именно и приходилось думать над DTO в силу специфики предметной области) я уже описал.здесь
IT>Всё равно не понял. Какое это имеет отношение к DTO? Если у тебя уже есть маленькие объекты, которые ты кешируешь, ну так и гоняй их туда сюда. В чем проблема?
Сервак по внутренней логике не работает с маленькими объектами. Набор полей используемый в серверной логике и на клиентской стороне сильно различается.
IT>Я тоже повторюсь. DTO, как затыкание косяков, может оказаться вполне оправданной вещью. Только давай отдавать себе отчёт, что косяк он и есть косяк. В вашем случае — это использование дремучего ASP. Стоит переписать всё на ASP.NET и необходимость в DTO моментально отпадёт.
Ага. Здоровски. Предлагаешь попросить клиента переписать свою систему которую они строили много лет?
Здравствуйте, GlebZ, Вы писали:
IT>>Это смотря что подразумевать под неверностью. Неоптимальное, избыточное решение тоже можно назвать неверным. GZ>Паттерны также описывают показания к применению.
Я надеюсь, тебе не нужно объяснять, что безграмотное использование паттернов легко превращает их в антипаттерны? Тот же паттерн DTO великолепно это демонстрирует.
IT>>Entity точно так же может представлять дерево. Не вижу абсолютно никакой разницы. GZ>По крайней мере Entity нужно собирать в некоторое дерево. И дерево это всегда такое-же как оно работает на серваке. Это уже механизм.
И в чём проблема?
GZ>>>>>2. Скрытие некоторых не предназначенных для клиента данных. IT>>>>Не передавай их и всё. В чём проблема? GZ>>>Именно для этого и делается некоторый презентационный слой который генерит DTO для клиента. IT>>Т.е. если тебе надо передать 5 полей, то для этого ты заведёшь DTO с 5-ю полями, если 6, то с 6-ю и так для всех 50-ти полей? Согласись, это полная чушь. GZ>Не понял Причем тут это??? Пункт 1 перечитай. А здесь просто бизнес-объект передаваемый на клиента неэквивалентен бизнес-объекту на серваке.
Не понял что? Что сам написал? Пунк 1 мы уже разобрали выше. Здесь мы как раз выясняем почему БО, передаваемый на клиента должен обязательно неэквивалентен БД на сервере. В частности, я утверждаю, что при дизайне, с самого начала учитывающем возможность одновременного использование одних и тех же объектов на всех слоях, этого всего не надо.
IT>>Называй это как угодно, только не завбывай добавлять, что процент задач, где это действительно нужно, от общего числа трудно разглядеть даже в микроскоп. GZ>У меня это процентов 90. Документооборот — эта такая штука в которой очень много слабоструктурированной информации.
Т.е. у тебя всё построено на веб-сервисах и ремоутингах? Всего лишь 10% обычной логики, а остальное всё комуникация? Странно И что такого в документообороте, что его делает столько нетрадиционной задачей?
GZ>>>Это была вынужденная мера. IT>>Чем вынужденная? GZ>Потому что ссылка в оперативной памяти не передается через сеть.
Ссылку и не надо передавать. Она потом будет восстановлена сериализатором.
GZ>Ну давай попробую описать по другому. Что такое Data Transfer Object. Когда клиент работает с серваком по некоторому контракту. Контракт — это инертефейс вызовов и получаемые или отсылаемые данные.
Я в курсе что такое DTO и что такое таконтракт. Меня интересуют примеры оправданного применения DTO. Не затыкание дырок, не обстрактные разговоры о специфике предметной области и правильности выбранного дизайна кем-либо в каком-либо конкретном случае, а толковые примеры, когда без DTO никуда.
GZ>Данные, они же бизнес-объекты, на сервере лежат в виде экземпляров объектов связанные по ссылкам, что при переливе на клиент сделать невозможно.
У тебя там stateful что ли? Ну так бы сразу и сказал
GZ>Для перелива на клиент нужно как минимум сформировать из объектов stream. То есть создать Data Transfer Object которые можно передать в другой процесс. Во многих случаях, это делается стандартными средствами сериализации, и мы не особо задумываемся о том, что это есть DTO. Обычно мы их так не называем, так как наши умственные и физические трудозатраты минимальны. Но существуют случаи, когда это или неэффективно, или невозможно сделать. Когда объекты для перелива не совсем равнозначны бизнес-объектам сервера. Тогда приходится уже придумывать механизм формирования DTO, и мы вспоминаем про данный паттерн как таковой. Случаи когда приходилось мне это делать (а в действительности мне чаще именно и приходилось думать над DTO в силу специфики предметной области) я уже описал.здесь
Глеб, ты меня извини, но разговоры о специфичности предметной области лично мне ничего не доказывают. У меня таких специфичных задач было мильён. При изначальном дизайне, ориентированном на отсутствие всяких промежуточных DTO, потребность в них возникала только в случае затыкания каких-нибудь дыр. А то, что ты привёл по ссылке мы уже разобрали и пока реальной необходимости в DTO там не нашли.
IT>>Всё равно не понял. Какое это имеет отношение к DTO? Если у тебя уже есть маленькие объекты, которые ты кешируешь, ну так и гоняй их туда сюда. В чем проблема? GZ>Сервак по внутренней логике не работает с маленькими объектами. Набор полей используемый в серверной логике и на клиентской стороне сильно различается.
Я уже сто раз говорил, что проблема согласования объектных моделей решается не с помощью DTO, а с помощью мапперов.
IT>>Я тоже повторюсь. DTO, как затыкание косяков, может оказаться вполне оправданной вещью. Только давай отдавать себе отчёт, что косяк он и есть косяк. В вашем случае — это использование дремучего ASP. Стоит переписать всё на ASP.NET и необходимость в DTO моментально отпадёт. GZ>Ага. Здоровски. Предлагаешь попросить клиента переписать свою систему которую они строили много лет?
Твои клинты с их проблемами меня мало интересуют. У меня своих полно. От тебя же здесь нужно всего лишь осознание того, что конкретно в этой ситуации DTO как раз являются вынужденной мерой ака затычкой в дизайне. Именно это я и пытаюсь до тебя донести. Пойми, я не против DTO как паттерна. Я лишь против того, что это хороший паттерн. По моему, теперь уже глубочайшему убеждению, наличие в системе DTO говорит лишь о том, что в дизайне этой системы есть проблемы. Убеждать меня в обратном абстрактными разговорами об уникальности свой предметной области не надо. А вот конкретные примеры, ещё лучше с кусочками кода, я бы с удовольствием посмотрел. А затем мы вместе бы разобрали можно ли там было обойтись без DTO или нет.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Я надеюсь, тебе не нужно объяснять, что безграмотное использование паттернов легко превращает их в антипаттерны? Тот же паттерн DTO великолепно это демонстрирует.
Повторю еще раз. Паттерны также описывают показания к применению. Паттерн рассказывает не только как применять, но и где применять.
IT>>>Entity точно так же может представлять дерево. Не вижу абсолютно никакой разницы. GZ>>По крайней мере Entity нужно собирать в некоторое дерево. И дерево это всегда такое-же как оно работает на серваке. Это уже механизм. IT>И в чём проблема?
Да ни в чем. Сделать некоторую штуку которое маппирует/собирает данные из БО в DTO не так уж сложно.
GZ>>>>>>2. Скрытие некоторых не предназначенных для клиента данных. IT>>>>>Не передавай их и всё. В чём проблема? GZ>>>>Именно для этого и делается некоторый презентационный слой который генерит DTO для клиента. IT>>>Т.е. если тебе надо передать 5 полей, то для этого ты заведёшь DTO с 5-ю полями, если 6, то с 6-ю и так для всех 50-ти полей? Согласись, это полная чушь. GZ>>Не понял Причем тут это??? Пункт 1 перечитай. А здесь просто бизнес-объект передаваемый на клиента неэквивалентен бизнес-объекту на серваке. IT>Не понял что? Что сам написал? Пунк 1 мы уже разобрали выше.
Пункт 1 — это применение некоторого подграфа вместо набора полей. К данному вопросу вышеописанное тобой отношение не имеет.
IT>Здесь мы как раз выясняем почему БО, передаваемый на клиента должен обязательно неэквивалентен БД на сервере.
Почему обязательно? Я описал именно показание когда его нужно делать.
IT>В частности, я утверждаю, что при дизайне, с самого начала учитывающем возможность одновременного использование одних и тех же объектов на всех слоях, этого всего не надо.
Когда тебя обязали хранить в той-же таблице кто и когда создавал/изменял объект, а у пользователя может и не быть прав на просмотр аудита что ты будешь делать?
IT>>>Называй это как угодно, только не завбывай добавлять, что процент задач, где это действительно нужно, от общего числа трудно разглядеть даже в микроскоп. GZ>>У меня это процентов 90. Документооборот — эта такая штука в которой очень много слабоструктурированной информации. IT>Т.е. у тебя всё построено на веб-сервисах и ремоутингах? Всего лишь 10% обычной логики, а остальное всё комуникация? Странно И что такого в документообороте, что его делает столько нетрадиционной задачей?
Типы документов и справочников создаются пользователем в процессе эксплуатации.
GZ>>>>Это была вынужденная мера. IT>>>Чем вынужденная? GZ>>Потому что ссылка в оперативной памяти не передается через сеть. IT>Ссылку и не надо передавать. Она потом будет восстановлена сериализатором.
Если она нужна. Один и тот же объект может передаваться разными интерфейсами в различных интерпретациях.
IT>У тебя там stateful что ли? Ну так бы сразу и сказал
Нет. Всегда делал stateless. Но в том задании была числодробилка и надо было строить граф который быстро работает. А это провязка ссылками так как по идентификатору тормозит.
IT>Глеб, ты меня извини, но разговоры о специфичности предметной области лично мне ничего не доказывают. У меня таких специфичных задач было мильён. При изначальном дизайне, ориентированном на отсутствие всяких промежуточных DTO, потребность в них возникала только в случае затыкания каких-нибудь дыр. А то, что ты привёл по ссылке мы уже разобрали и пока реальной необходимости в DTO там не нашли.
Извини, но по моему ты не совсем понял что-же там было написано. Или все же не понял что-же такое DTO.
IT>Я уже сто раз говорил, что проблема согласования объектных моделей решается не с помощью DTO, а с помощью мапперов.
А DTO в 90 процентов случаев и генерится маппером.
IT>Твои клинты с их проблемами меня мало интересуют. У меня своих полно. От тебя же здесь нужно всего лишь осознание того, что конкретно в этой ситуации DTO как раз являются вынужденной мерой ака затычкой в дизайне. Именно это я и пытаюсь до тебя донести. Пойми, я не против DTO как паттерна. Я лишь против того, что это хороший паттерн.
Я не понимаю что такое хороший паттерн, или плохой. Паттерн должен быть по месту. Это примерно как и вопрос какой паттерн самый красивый.
IT>По моему, теперь уже глубочайшему убеждению, наличие в системе DTO говорит лишь о том, что в дизайне этой системы есть проблемы. Убеждать меня в обратном абстрактными разговорами об уникальности свой предметной области не надо. А вот конкретные примеры, ещё лучше с кусочками кода, я бы с удовольствием посмотрел. А затем мы вместе бы разобрали можно ли там было обойтись без DTO или нет.
Нет. Свои не дам. Недавно сменил работу, а теперешний не могу. Да и разработано многое в нынешнем проекте не мной. А вот к примеру Janus — весьма интересен. Фактически набор в DataSet получаемый с сервера, и набор бизнес объектов используемый внутрях — разный. И есть у меня такое жуткое предположение, что и на серваке что-то третье а DataSet генерится с других объектов. Тебе собственно видней че там делается, можно и обсудить.
Здравствуйте, GlebZ, Вы писали:
IT>>Я надеюсь, тебе не нужно объяснять, что безграмотное использование паттернов легко превращает их в антипаттерны? Тот же паттерн DTO великолепно это демонстрирует. GZ>Повторю еще раз. Паттерны также описывают показания к применению. Паттерн рассказывает не только как применять, но и где применять.
И какие показания к применению DTO? Я когда-ниубдь это услышу?
IT>>И в чём проблема? GZ>Да ни в чем. Сделать некоторую штуку которое маппирует/собирает данные из БО в DTO не так уж сложно.
Вопрос — зачем? Зачем вообще нужен этот лишний этап?
IT>>Не понял что? Что сам написал? Пунк 1 мы уже разобрали выше. GZ>Пункт 1 — это применение некоторого подграфа вместо набора полей. К данному вопросу вышеописанное тобой отношение не имеет.
Это не важно. Мой вопрос можно перефразировать и для подграфа. Суть вопроса в том, стоит ли для разного представления одних и тех же данных создавать новые DTO, максимально подогнанные для этого представления.
IT>>Здесь мы как раз выясняем почему БО, передаваемый на клиента должен обязательно неэквивалентен БД на сервере. GZ>Почему обязательно? Я описал именно показание когда его нужно делать.
Где это ты описал? Ты всего лишь озвучил утверждение, что одна из причин использования DTO "2. Скрытие некоторых не предназначенных для клиента данных.". Я тебе на это отвечаю — вводить DTO для этого не обязательно, достаточно не передавать ненужные данные клиенту.
IT>>В частности, я утверждаю, что при дизайне, с самого начала учитывающем возможность одновременного использование одних и тех же объектов на всех слоях, этого всего не надо. GZ>Когда тебя обязали хранить в той-же таблице кто и когда создавал/изменял объект, а у пользователя может и не быть прав на просмотр аудита что ты будешь делать?
Не передавать пользователю эти данные.
IT>>>>Называй это как угодно, только не завбывай добавлять, что процент задач, где это действительно нужно, от общего числа трудно разглядеть даже в микроскоп. GZ>>>У меня это процентов 90. Документооборот — эта такая штука в которой очень много слабоструктурированной информации. IT>>Т.е. у тебя всё построено на веб-сервисах и ремоутингах? Всего лишь 10% обычной логики, а остальное всё комуникация? Странно И что такого в документообороте, что его делает столько нетрадиционной задачей? GZ>Типы документов и справочников создаются пользователем в процессе эксплуатации.
Гы-гы. Так это другие 90%. В подобных задачах вообще использование статических BO, а следовательно и DTO, минимально. Там в основном упор на связи и динамику. Мы же здесь, судя по сообщению автора топика, вроде как обсуждаем вполне типичный случай применения DTO для статических объектов.
IT>>Ссылку и не надо передавать. Она потом будет восстановлена сериализатором. GZ>Если она нужна. Один и тот же объект может передаваться разными интерфейсами в различных интерпретациях.
OK. И почему для передачи или не передачи ссылки нужно создавать DTO?
IT>>У тебя там stateful что ли? Ну так бы сразу и сказал GZ>Нет. Всегда делал stateless. Но в том задании была числодробилка и надо было строить граф который быстро работает. А это провязка ссылками так как по идентификатору тормозит.
Очень хорошо. Т.е. ты утверждаешь, что DTO нужно использовать в числодробильных задачах. Я правильно понял?
GZ>Извини, но по моему ты не совсем понял что-же там было написано. Или все же не понял что-же такое DTO.
У меня складывается мнение, что это ты не понимаешь что такое DTO. Точнее, явно путаешь data transfer с data transfer object.
IT>>Я уже сто раз говорил, что проблема согласования объектных моделей решается не с помощью DTO, а с помощью мапперов. GZ>А DTO в 90 процентов случаев и генерится маппером.
О! Я же говорю, что путаешь
GZ>Я не понимаю что такое хороший паттерн, или плохой. Паттерн должен быть по месту. Это примерно как и вопрос какой паттерн самый красивый.
А я тебе объясню, что такое плохой паттерн. Это паттерн, основное назначение которого затыкать дыры в дизайне.
GZ>Нет. Свои не дам. Недавно сменил работу, а теперешний не могу. Да и разработано многое в нынешнем проекте не мной.
Да меня не интересуют ваши коммерческие секреты. Просто пару вымышленных, но аналогичных решений.
GZ>А вот к примеру Janus — весьма интересен. Фактически набор в DataSet получаемый с сервера, и набор бизнес объектов используемый внутрях — разный. И есть у меня такое жуткое предположение, что и на серваке что-то третье а DataSet генерится с других объектов. Тебе собственно видней че там делается, можно и обсудить.
Очень хороший пример. Хороший пример плохого дизайна. Пример того, когда легаси код, спешка и "лишь бы работало" затыкаются в результате плохими паттернами. Ещё примеры будут?
Если нам не помогут, то мы тоже никого не пощадим.
IT>И какие показания к применению DTO? Я когда-ниубдь это услышу?
Ну не нравится те показания которые я написал, прочитай MSDN. Его не тупые люди писали. Раздел Forces — описано почему, раздел Benefits — бенефиты, раздел Liabilities — какие недостатки.
Переводить надеюсь не надо?
IT>Вопрос — зачем? Зачем вообще нужен этот лишний этап? MSDN
IT>>>Не понял что? Что сам написал? Пунк 1 мы уже разобрали выше. GZ>>Пункт 1 — это применение некоторого подграфа вместо набора полей. К данному вопросу вышеописанное тобой отношение не имеет. IT>Это не важно. Мой вопрос можно перефразировать и для подграфа. Суть вопроса в том, стоит ли для разного представления одних и тех же данных создавать новые DTO, максимально подогнанные для этого представления.
Иногда другого пути нет.
GZ>>Когда тебя обязали хранить в той-же таблице кто и когда создавал/изменял объект, а у пользователя может и не быть прав на просмотр аудита что ты будешь делать? IT>Не передавать пользователю эти данные.
+1. А для этого нужно сформировать тип BO но для клиента. Который и является DTO.
IT>Гы-гы. Так это другие 90%. В подобных задачах вообще использование статических BO, а следовательно и DTO, минимально. Там в основном упор на связи и динамику. Мы же здесь, судя по сообщению автора топика, вроде как обсуждаем вполне типичный случай применения DTO для статических объектов.
Делались решения и на основе нетипизированных датасетов, и на основе кодогенерации, и вообще без таковой. Я много где этой задачей занимался.
IT>>>Ссылку и не надо передавать. Она потом будет восстановлена сериализатором. GZ>>Если она нужна. Один и тот же объект может передаваться разными интерфейсами в различных интерпретациях. IT>OK. И почему для передачи или не передачи ссылки нужно создавать DTO? IT>О! Я же говорю, что путаешь
Тады что по твоему является DTO?
GZ>>Нет. Свои не дам. Недавно сменил работу, а теперешний не могу. Да и разработано многое в нынешнем проекте не мной. IT>Да меня не интересуют ваши коммерческие секреты. Просто пару вымышленных, но аналогичных решений.
OK. Правда не особо вымышленный.
Сценарий — надо показать форму с документом. Необходимо показать следующее:
1. Основные реквизиты документа
2. Сообщения по документу. Должно показывать тип сообщения, статус сообщения, автор сообщения, наличие/отсутсвие привязанных к сообщению файлов. Сообщения относятся к документу как 1:n. (сообщение содержит также большое поле — текст сообщение )
3. Наименование рубрик привязанных к документу. Отношение n:m.
4. Связанные документы. Нужно показать наименование связанного документа.(отношение n:m)
5. Описание файлов. Наименование, наличие подверсий файлов.(отношение 1:n)
6. Папку к которому документ в данный момент привязан (отношение 1:1)
Учитывать что небольшие по количеству объекты такие как папки и рубрики — кэшируются в оперативной памяти. Все объекты на сервере — entity.
Также существует другой сценарий. Показать список документов отобранных по какому-то критерию. Набор информации по документу в каждой строке определяется настройками пользователя.
Попробуй описать как бы ты это сделал.
GZ>>А вот к примеру Janus — весьма интересен. Фактически набор в DataSet получаемый с сервера, и набор бизнес объектов используемый внутрях — разный. И есть у меня такое жуткое предположение, что и на серваке что-то третье а DataSet генерится с других объектов. Тебе собственно видней че там делается, можно и обсудить. IT>Очень хороший пример. Хороший пример плохого дизайна. Пример того, когда легаси код, спешка и "лишь бы работало" затыкаются в результате плохими паттернами. Ещё примеры будут?
Ух ты. Я просто пищу. Многие наезжали на янус, но чтобы ты????. В данном случае это классический offline-клиент по системе Data Center. Клиент развивался достаточно отдельно от сервера и оперативно решал свои задачи. Посему и модель БД у него расходится с серверной. Это вполне нормальное решение.
Здравствуйте, GlebZ, Вы писали:
IT>>И какие показания к применению DTO? Я когда-ниубдь это услышу? GZ>Ну не нравится те показания которые я написал, прочитай MSDN. Его не тупые люди писали. Раздел Forces — описано почему, раздел Benefits — бенефиты, раздел Liabilities — какие недостатки. GZ>Переводить надеюсь не надо?
От ты блин! Да сколько ж можно
Ещё раз. Business Entities обладают точно такими же бенефитами и не имеют ни одного из перечисленных недостатков. Или надо запускать эту песню по второму кругу?
IT>>Это не важно. Мой вопрос можно перефразировать и для подграфа. Суть вопроса в том, стоит ли для разного представления одних и тех же данных создавать новые DTO, максимально подогнанные для этого представления. GZ>Иногда другого пути нет.
Когда другого пути нет?
GZ>Тады что по твоему является DTO?
DTO — это объект, единственное предназначение которого заключается в переносе данных между частями системы. Я против именно против этой единственности.
GZ>>>Нет. Свои не дам. Недавно сменил работу, а теперешний не могу. Да и разработано многое в нынешнем проекте не мной. IT>>Да меня не интересуют ваши коммерческие секреты. Просто пару вымышленных, но аналогичных решений. GZ>OK. Правда не особо вымышленный. GZ>Сценарий — надо показать форму с документом. Необходимо показать следующее: GZ>1. Основные реквизиты документа GZ>2. Сообщения по документу. Должно показывать тип сообщения, статус сообщения, автор сообщения, наличие/отсутсвие привязанных к сообщению файлов. Сообщения относятся к документу как 1:n. (сообщение содержит также большое поле — текст сообщение ) GZ>3. Наименование рубрик привязанных к документу. Отношение n:m. GZ>4. Связанные документы. Нужно показать наименование связанного документа.(отношение n:m) GZ>5. Описание файлов. Наименование, наличие подверсий файлов.(отношение 1:n) GZ>6. Папку к которому документ в данный момент привязан (отношение 1:1) GZ>Учитывать что небольшие по количеству объекты такие как папки и рубрики — кэшируются в оперативной памяти. Все объекты на сервере — entity.
Ну и в чём проблема. Рисуем entity для этих данных. По запросу клиента выбираем всё нужное из базы, добавляем к результату данные из серверного кеша, передаём клиенту, доабавляем на клиенте данные из клиентского кеша, баиндим результат на форму. Необходимости в специально выделенном DTO я не вижу.
GZ>Также существует другой сценарий. Показать список документов отобранных по какому-то критерию. Набор информации по документу в каждой строке определяется настройками пользователя.
Здесь хорошо бы определиться с тем как ты хранишь настройки пользователя. Но в общем случае схема такая же. Отбираем по критерию данные из базы. Если настройки можно учесть непосредственно в запросе, то одного запроса будет достаточно. Данные мапятся в entity, настройки складываются в коллекции и всё это уезжает клиенту. Клиент отображает эти данные на форме. DTO как отдельный этап не просматривается.
GZ>Ух ты. Я просто пищу. Многие наезжали на янус, но чтобы ты????. В данном случае это классический offline-клиент по системе Data Center. Клиент развивался достаточно отдельно от сервера и оперативно решал свои задачи. Посему и модель БД у него расходится с серверной. Это вполне нормальное решение.
Это не нормальное решенте. Нормальное решение должно учитывать требования клиента при разработке сервера. У нас же получилась примочка сбоку. Как ты думаешь, почему сервис януса переписывался несколько раз?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>От ты блин! Да сколько ж можно IT>Ещё раз. Business Entities обладают точно такими же бенефитами и не имеют ни одного из перечисленных недостатков. Или надо запускать эту песню по второму кругу?
Ну-ну.
GZ>>OK. Правда не особо вымышленный. GZ>>Сценарий — надо показать форму с документом. Необходимо показать следующее: GZ>>1. Основные реквизиты документа GZ>>2. Сообщения по документу. Должно показывать тип сообщения, статус сообщения, автор сообщения, наличие/отсутсвие привязанных к сообщению файлов. Сообщения относятся к документу как 1:n. (сообщение содержит также большое поле — текст сообщение ) GZ>>3. Наименование рубрик привязанных к документу. Отношение n:m. GZ>>4. Связанные документы. Нужно показать наименование связанного документа.(отношение n:m) GZ>>5. Описание файлов. Наименование, наличие подверсий файлов.(отношение 1:n) GZ>>6. Папку к которому документ в данный момент привязан (отношение 1:1) GZ>>Учитывать что небольшие по количеству объекты такие как папки и рубрики — кэшируются в оперативной памяти. Все объекты на сервере — entity.
IT>Ну и в чём проблема. Рисуем entity для этих данных. По запросу клиента выбираем всё нужное из базы, добавляем к результату данные из серверного кеша, передаём клиенту, доабавляем на клиенте данные из клиентского кеша, баиндим результат на форму. Необходимости в специально выделенном DTO я не вижу.
Ну а теперь посчитаем:
1. Мы возвращаем n документов (сам документ так и связанные с ним документы)
2. Мы возращаем полные сообщения (учитывая все остальные поля, это в среднем раз в 10 больше информации).
3. Мы возвращаем описания файлов. В среднем раза в 4 больше информации.
4. Мы возвращаем рубрики. В среднем раза 3 больше информации.
5. Мы возвращаем папку. Думаю в среднем раза в полтора больше информации но это уже не важно, так как она единственная.
Я бы потерпел если бы счет шел раза в два. Тут уже идет счет на порядки. Как результат — вместо нескольких кил информации счет уже идет на сотни кил. Это называется эффективно?
GZ>>Также существует другой сценарий. Показать список документов отобранных по какому-то критерию. Набор информации по документу в каждой строке определяется настройками пользователя. IT>Здесь хорошо бы определиться с тем как ты хранишь настройки пользователя. Но в общем случае схема такая же. Отбираем по критерию данные из базы. Если настройки можно учесть непосредственно в запросе, то одного запроса будет достаточно. Данные мапятся в entity, настройки складываются в коллекции и всё это уезжает клиенту. Клиент отображает эти данные на форме. DTO как отдельный этап не просматривается.
Еще как просматривается. На полной сериализации счет шел на десятки и сотни мегабайт. Тута вообще если все оставить как entity — убивает сервер напрочь.
GZ>>Ух ты. Я просто пищу. Многие наезжали на янус, но чтобы ты????. В данном случае это классический offline-клиент по системе Data Center. Клиент развивался достаточно отдельно от сервера и оперативно решал свои задачи. Посему и модель БД у него расходится с серверной. Это вполне нормальное решение. IT>Это не нормальное решенте. Нормальное решение должно учитывать требования клиента при разработке сервера. У нас же получилась примочка сбоку.
Сервер должен учитывать требования всех возможных клиентов а не одного конкретного. Он должен выдавать наиболее полно и гибко информацию с учетом клиентов которых еще нет в природе. Может это у меня такая специфика, но интеграцию требуют многие клиенты. Поэтому функциональность сервера не должен зависить от конкретного клиента.
IT>Как ты думаешь, почему сервис януса переписывался несколько раз?
Это уж вам видней.
Здравствуйте, GlebZ, Вы писали:
IT>>Ну и в чём проблема. Рисуем entity для этих данных. По запросу клиента выбираем всё нужное из базы, добавляем к результату данные из серверного кеша, передаём клиенту, доабавляем на клиенте данные из клиентского кеша, баиндим результат на форму. Необходимости в специально выделенном DTO я не вижу. GZ>Ну а теперь посчитаем: GZ>1. Мы возвращаем n документов (сам документ так и связанные с ним документы) GZ>2. Мы возращаем полные сообщения (учитывая все остальные поля, это в среднем раз в 10 больше информации). GZ>3. Мы возвращаем описания файлов. В среднем раза в 4 больше информации. GZ>4. Мы возвращаем рубрики. В среднем раза 3 больше информации. GZ>5. Мы возвращаем папку. Думаю в среднем раза в полтора больше информации но это уже не важно, так как она единственная. GZ>Я бы потерпел если бы счет шел раза в два. Тут уже идет счет на порядки. Как результат — вместо нескольких кил информации счет уже идет на сотни кил. Это называется эффективно?
Откуда я знаю? На сколько ты мне выдал информации на столько и получил решений. Давай расписывай подробнее, будем решать детальнее. Например, мне интересна частота обновления всех перечисленных тобой данных, их объем и структура. А пока с учётом моих телепатических способностей, решение которое я тебе выдал можно назвать идеальным
IT>>Здесь хорошо бы определиться с тем как ты хранишь настройки пользователя. Но в общем случае схема такая же. Отбираем по критерию данные из базы. Если настройки можно учесть непосредственно в запросе, то одного запроса будет достаточно. Данные мапятся в entity, настройки складываются в коллекции и всё это уезжает клиенту. Клиент отображает эти данные на форме. DTO как отдельный этап не просматривается. GZ>Еще как просматривается. На полной сериализации счет шел на десятки и сотни мегабайт. Тута вообще если все оставить как entity — убивает сервер напрочь.
Мне кажется, что ты не улавливаешь одну простую вещь. Если нет необходимости в полной сериализации, то её не надо делать. Entity спокойно может быть передана, например без списка рубрик, если эти рубрики уже закешированы на клиенте. Для всего этого не нужно создавать специальные DTO.
IT>>Это не нормальное решенте. Нормальное решение должно учитывать требования клиента при разработке сервера. У нас же получилась примочка сбоку. GZ>Сервер должен учитывать требования всех возможных клиентов а не одного конкретного. Он должен выдавать наиболее полно и гибко информацию с учетом клиентов которых еще нет в природе.
Это совершенно необязательно. Да зачастую и невозможно. У нашего сервера как минимум три клиента: web, янус, nntp. У каждого их них есть своя специфика. Например, для web нужен пейджинг, для януса поиск оборванных веток, для реализации протокола nntp нужно возвращать списки сообщений, отфильтрованных по их порядковым номерам. Если делать универсальный интерфейс, то либо мы не сможем предоставить клиентам часть функционала, либо будем вынуждены написать очень общий функционал, который будет ужасно неэффективен.
GZ>Может это у меня такая специфика, но интеграцию требуют многие клиенты. Поэтому функциональность сервера не должен зависить от конкретного клиента.
Такое тоже бывает. Всё зависит от структуры сервера, клиентов и требуемой функциональности. Можно ведь вообще один метод написать, на входе xml, на выходе xml. В результате очень стабильный внешний интерфейс, правильно?
IT>>Как ты думаешь, почему сервис януса переписывался несколько раз? GZ>Это уж вам видней.
Вот именно.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Не знаем. Но знаем, что речь идёт как минимум о .NET, где реальных причин, озвученных тобой выше, для использования DTO пока не обнаружено. Вывод напрашивается сам собой.
Тоже прошу прощения, что встреваю. Вот по этой ссылке
я описывал стандартнейшую ситуацию, где использование DTO единственный разумный выход. Если следовать твоей логике, то здесь или ошибка в дизайне, или можно все упаковать в entity, или мы по разному понимаем термин DTO. В последнем я сомневаюсь, т.к. данное тобой определение вполне вполне подходит под эту ситуацию.
Здравствуйте, MaximVK, Вы писали:
MVK>Здравствуйте, IT, Вы писали:
IT>>Не знаем. Но знаем, что речь идёт как минимум о .NET, где реальных причин, озвученных тобой выше, для использования DTO пока не обнаружено. Вывод напрашивается сам собой.
Хотел добавить вчера, что DTO бывает полезен в тех случаях, когда уже ничего больше не помогает.
MVK>Тоже прошу прощения, что встреваю. Вот по этой ссылке
я описывал стандартнейшую ситуацию, где использование DTO единственный разумный выход. Если следовать твоей логике, то здесь или ошибка в дизайне, или можно все упаковать в entity, или мы по разному понимаем термин DTO. В последнем я сомневаюсь, т.к. данное тобой определение вполне вполне подходит под эту ситуацию.
Для такой ситуации, очевидно, оверхед по вытаскиванию всех этих данных будет слишком большой(особенно вытащить все продукты в заказе, чтобы узнать их количество). Поэтому лучше создать какой-нить DTO класс, который будет содержать исключительно необходимую информацию.
А как ты будешь узнавать количество продуктов в заказе для DTO?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Mika Soukhov, Вы писали:
MS>Количество продуктов узнается перед тем, как делать запрос по выборке этих самых продуктов. Тот же paging работает по схожему методу.
Это смотря с какой стороны посмотреть. В случае 3-х звенки лучше сразу заказывать количество возвращаемых данных, и чтобы запрос вместе со страницей возвращал общее количество объектов. Потому как иначе нужно будет думать как поведет себя визуалка если между получением количества и получением последней страницы будет вставлен/удален какой-то объект.
Здравствуйте, IT, Вы писали:
IT>Откуда я знаю? На сколько ты мне выдал информации на столько и получил решений. Давай расписывай подробнее, будем решать детальнее. Например, мне интересна частота обновления всех перечисленных тобой данных, их объем и структура. А пока с учётом моих телепатических способностей, решение которое я тебе выдал можно назвать идеальным
Да в принципе ключевую информацию я дал. Система как и почти все системы документооборота чаще используется для чтения/поиска. Каждый объект вполне самостоятелен и имеет дополнительную информацию используюмую в других прецедентах. Основное в вышеуказанном, что сообщения и документы большие. И они обязаны быть актуальными на момент запуска сценария.
IT>Мне кажется, что ты не улавливаешь одну простую вещь. Если нет необходимости в полной сериализации, то её не надо делать. Entity спокойно может быть передана, например без списка рубрик, если эти рубрики уже закешированы на клиенте. Для всего этого не нужно создавать специальные DTO.
Я примерно начал понимать в чем дело. Я практически никогда не использую прямые ссылки. Для меня обобщенно сценарий выполнения запроса сервера — загрузить нужные бизнес-объекты с выполнением бизнес-логики, сериализовать в некоторый stream(который является DTO), и отправить клиенту. Связанные объекты на сервере не связываются по ссылке, а только по идентификаторам и знанием в какой коллекции он находится. Таким образом с каждым объектом можно работать по отдельности, использовать для других прецедентах и механизмах. Он вполне самостоятелен и не несет за собой нагрузку в виде связанных объектов. А затем при отдаче клиенту они сериализуются по порядку в один и тот же стрим(или каким либо другим способом). Когда то делал ссылки и с Lazy Load, но не нравится. Особенные проблемы были с paging связанных объектов.
IT>Это совершенно необязательно. Да зачастую и невозможно. У нашего сервера как минимум три клиента: web, янус, nntp. У каждого их них есть своя специфика. Например, для web нужен пейджинг, для януса поиск оборванных веток, для реализации протокола nntp нужно возвращать списки сообщений, отфильтрованных по их порядковым номерам. Если делать универсальный интерфейс, то либо мы не сможем предоставить клиентам часть функционала, либо будем вынуждены написать очень общий функционал, который будет ужасно неэффективен.
Коли я была царицей...
Вобщем я бы выбрал вариант с единым интерфейсом сервера у которого были бы и paging и фильтрация и сортировка.
GZ>>Может это у меня такая специфика, но интеграцию требуют многие клиенты. Поэтому функциональность сервера не должен зависить от конкретного клиента.
IT>Такое тоже бывает. Всё зависит от структуры сервера, клиентов и требуемой функциональности. Можно ведь вообще один метод написать, на входе xml, на выходе xml. В результате очень стабильный внешний интерфейс, правильно?
Только не надо xml на входе. Видел одно такое решение, очень хотелось кого-нибудь убить. Контракт должен быть ясным и понятным. Еще не видел хоть одного вменяемого решения по своему языку запросов. Лучше минимум универсального языка запросов. Но все-таки, можно потратить некоторое время на унификацию интерфейса сервера. Потом оно обертывается сторицей.
Здравствуйте, IT, Вы писали:
IT>А как ты будешь узнавать количество продуктов в заказе для DTO?
DTO полностью формируются на уровне DAL, т.е. количество продуктов в заказе расчитывается еще в базе и результаты запроса сразу упаковываются в DTO без промежуточных распихиваний по бизнес-объектам. Если это не DTO, то что это?
Назвать это business entity — язык не поворачивается, т.к. один экземпляр этого класса хранит агрегированную информацию о нескольких взаимосвязанных сущностях. Проектировать business-entities так, чтобы они успешно решали еще и эту задачу — глупо, т.к. во-первых это не их дело, а во-вторых появиться зависимость между совершенно двумя различными задачами. Также несколько странно добавлять метод вычисляющий productCount для конкретного заказа, при условии, что нигде кроме этой задачи он не понадобиться.
Здравствуйте, Mika Soukhov, Вы писали:
MS>Хотел добавить вчера, что DTO бывает полезен в тех случаях, когда уже ничего больше не помогает.
Я бы сказал, что DTO бывает полезен тогда, когда он бывает полезен Прошу прощения за софистику. Меня несколько пугают крайности, когда говорят: этот путь единственно верный или никогда так не делайте. Такие декларативные ограничения полезны только для начинающих, т.к. прежде чем отходить от правил, нужно этими правилами научиться пользоваться. Программирование — это искусство возможного и даже реализация самой красивой концепции требует компромисов.
MS>Количество продуктов узнается перед тем, как делать запрос по выборке этих самых продуктов. Тот же paging работает по схожему методу.
В подавляющем большинстве случаев нужна просто коллекция OrderItems, которая запрашивается вся сразу по id заказа. Метод вида GetOrderItemsCount (или поле OrderProductCount у заказа) имеет смысл создавать достаточно редко. Я тут полностью согласен с Глебом, что лучше сделать просто метод вида GetOrderItems(int orderId, int pageNumber, int itemsPerPage) который будет возвращать структуру содержащую коллекцию OrderItems и OrderItemsTotalCount.
Здравствуйте, MaximVK, Вы писали:
MVK>Здравствуйте, IT, Вы писали:
IT>>А как ты будешь узнавать количество продуктов в заказе для DTO?
MVK> DTO полностью формируются на уровне DAL, т.е. количество продуктов в заказе расчитывается еще в базе и результаты запроса сразу упаковываются в DTO без промежуточных распихиваний по бизнес-объектам. Если это не DTO, то что это?
Это зависит от того, что ты дальше будет делать с этим DTO. Что с ним будет делать клиент? Перекладывать данные в свою объектную модель или использовать напрямую?
MVK>Назвать это business entity — язык не поворачивается, т.к. один экземпляр этого класса хранит агрегированную информацию о нескольких взаимосвязанных сущностях. Проектировать business-entities так, чтобы они успешно решали еще и эту задачу — глупо, т.к. во-первых это не их дело, а во-вторых появиться зависимость между совершенно двумя различными задачами. Также несколько странно добавлять метод вычисляющий productCount для конкретного заказа, при условии, что нигде кроме этой задачи он не понадобиться.
Давай попробуем порассуждать. Ты утверждаешь, что добавлять метод/свойство productCount или обучать BE решать эту задачу другим способом странно и глупо, т.к. это нигде кроме этой задачи не понадобится. А создавать отдельную структуру данных (DTO), которая может дублировать 90% информации из BE и тоже использоваться только для этой задачи — это как раз то, что нужно. Где логика?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
ITIT>Это зависит от того, что ты дальше будет делать с этим DTO. Что с ним будет делать клиент? Перекладывать данные в свою объектную модель или использовать напрямую?
Ну в рассматриваемом примере — напрямую, т.к. эти данные нужны для грида. Также, важно, что эти данные не будут меняться. Т.е. клиент не может заслать этот DTO обратно на сервер. Это важное ограничение, т.к. он избавляет нас от написания всяких разборщиков/сборщиков DTO из business entities, что я считаю очень крайней мерой.
IT>Давай попробуем порассуждать. Ты утверждаешь, что добавлять метод/свойство productCount или обучать BE решать эту задачу другим способом странно и глупо, т.к. это нигде кроме этой задачи не понадобится. А создавать отдельную структуру данных (DTO), которая может дублировать 90% информации из BE и тоже использоваться только для этой задачи — это как раз то, что нужно. Где логика?
Я замечу, что эта структура дублирует по 5-10% информации из 10 типов объектов + использует некоторые агрегаты по коллекциям объектов. Т.е. суммарный процент получается даже меньше 5.
Теперь про обучение BE. Подход, который ты предлагаешь, со временем в целях оптимизации, потребует частичного заполнения бизнес-сущностей. Что, в свою очередь, повлечет необходимость добавления методов вида IsOrderNameSpecified(), IsOrderDateCreatedSpecified() и т.д. для каждого поля BE. Далее, код, который использует BE должен будет предварительно вызвать этот метод, чтобы убедиться, что поле, которое он собирается использовать, определено. Также посыпятся методы BE которые используют внутренние поля, например методы вида GetUserFullName(), который из FirstName и LastName делает полное имя, т.к. BE не должна уметь сама себя загружать то от таких методов придется или избавиться, или сделать проверочный метод, или вышвыривать исключение. Частично заполненые объекты требует крайне внимательного с ними обращения и являются потенциальным источником большого количества трудно обнаружимых ошибок.
Пример, который я привел — это DTO которое используется для отображений данных в гриде. Ты предлагаешь мне проектировать мои BE, так чтобы их было удобно изображать на гриде? Но это две совершенно разные задачи. Business entities — суть контейнеры для данных описывающие предметную область, язык на котором общаются другие компоненты системы. Вероятность изменения BE значительно ниже, чем вероятность изменения требований о представлении данных клиентами, т.к. первые отражают значительно более инертную предметную область(я уже молчу про индустриальные стандарты, которые тоже находят отражения в BE).
Здравствуйте, IT, Вы писали:
GZ>>А вот к примеру Janus — весьма интересен. Фактически набор в DataSet получаемый с сервера, и набор бизнес объектов используемый внутрях — разный. И есть у меня такое жуткое предположение, что и на серваке что-то третье а DataSet генерится с других объектов. Тебе собственно видней че там делается, можно и обсудить.
IT>Очень хороший пример. Хороший пример плохого дизайна. Пример того, когда легаси код, спешка и "лишь бы работало" затыкаются в результате плохими паттернами. Ещё примеры будут?
Гм. А как оценивается тобою вот этот вариант? Он как стыкуется с БО, используемыми сервером?
Здравствуйте, GlebZ, Вы писали:
GZ>Ух ты. Я просто пищу. Многие наезжали на янус, но чтобы ты????.
Надо ещё АВК заманить, мало не покажется.
GZ> В данном случае это классический offline-клиент по системе Data Center. Клиент развивался достаточно отдельно от сервера и оперативно решал свои задачи. Посему и модель БД у него расходится с серверной. Это вполне нормальное решение.
Полагаю, тут немалое влияние оказало и то, кто и как развивал проект. Квалификация и опыт самые разные.
И почему, собственно, БО в Янусе должны быть 1-к-одному, как на сервере? Ведь это же оффлайн-клиент всё-таки, он обязан долговременно и функционально работать сам по себе.
Согласись, это полная чушь.
Причем тут это??? Пункт 1 перечитай. А здесь просто бизнес-объект передаваемый на клиента неэквивалентен бизнес-объекту на серваке.
Если нам не помогут, то мы тоже никого не пощадим.
