Суть в том чтобы все get-ы и set-ы BO работали с DTO, а не приватными мемберами соответствующих свойств BO.
DTO представяет собой простую структуру (OrderDTO).
Плюсы очевидны:
+ BO не загромождены приватными членами свойств, код зрительно более приятный.
+ Не требуется (или минимальный) маппинг BO->DTO для передачи DTO сервисам и DataAccessLayer-у, так же отпадает необходимость реализации всяких criteria-паттернов (like criteria in CSLA.NET).

Вопрос:
А какие минусы или подводные камни у такого подхода?
Могут ли здесь возникнуть сложности при использовании mapper-helper-ов, того же BusinessToolKit-а?

    public struct OrderDTO
    {
        public int OrderID;
        public System.DateTime OrderDate;
    }


public class Order
    {
        private OrderDTO data;
        

    public System.DateTime OrderDate 
        {
            get 
            {
                return data.OrderDate;
            }
            set 
            {
                data.OrderDate = value;
            }
        }
}

Здравствуйте, снежок, Вы писали:

С>Плюсы очевидны:
С>+ BO не загромождены приватными членами свойств, код зрительно более приятный.
Не очень серъезный плюс. Код достаточно нагляден.
С>+ Не требуется (или минимальный) маппинг BO->DTO для передачи DTO сервисам и DataAccessLayer-у, так же отпадает необходимость реализации всяких criteria-паттернов (like criteria in CSLA.NET).
Обычно объекты хранятся в коллекциях. Какой тип будет у коллекций для DTO и для DAL?

С>>+ Не требуется (или минимальный) маппинг BO->DTO для передачи DTO сервисам и DataAccessLayer-у, так же отпадает необходимость реализации всяких criteria-паттернов (like criteria in CSLA.NET).
GZ>Обычно объекты хранятся в коллекциях. Какой тип будет у коллекций для DTO и для DAL?
Да, с передачей коллекций особый разговор.
Для данной схемы я исхожу из следующих требований/предположений:
-DAL работает только с DTO и понятия не имеет о BO.
-Сервисы отдают и получают также DTO, хотя в своем кеше хранят BO. При передачи/приеме сервисом DTO-объектов, DTO полученный/ отправляемый проходит через Security-фильтр. Происходит двусторонний маппинг (в соответствии с привелегиями) DTO клиента на DTO хранящемся в BO кеша сервиса. BO.DTO на стороне сервиса хранит полные данные. DTO предаваемый клиенту хранит только данные которые доступну клиенту в соответствии с его привелегиями.
Таким образом, достигается не только row-level и operation-level security, но и property-level security без необходимости инстацирования объектов на сервере по ссылке (MarchalByRef) или без необходимости Lazy-load.
-Что с коллекциями? — Как мне пока видится, это задача BO. BO хранит коллекцию DTO-объектов.

Как в данном случае передавать сервису иерархический объект?
-делать ли вызовы сервиса для каждого элемента коллекции, взяв его DTO для передачи (что извращает саму идею DTO как минимизация вызовов и трафика клиент<->сервис)?
-или сформировать массив DTO и предавать его как параметр [insertOrder(OrderDTO orderDTO, OrderItem[] orderItems)] (но тогда как быть с довольно разветвленными объектами, которых не мало)?
-или создавать отдельный класс для разветвленных DTO-объектов (но тогда ценность приведенного подхода "DTO внутри BO" оказывается сомнительной, поскольку опять приходим к маппингу BO->DTO)?

Все это те вопросы на которые я пока не нахожу для себя ответа, хотя сама идея, в общих чертах, мне нравится...

Спасибо.

Здравствуйте, снежок, Вы писали:

С>Суть в том чтобы все get-ы и set-ы BO работали с DTO, а не приватными мемберами соответствующих свойств BO.

Я вот никогда не понимал, в чём вообще смысл разделения на DTO и BO? Потому что Фаулер так сказал?

Здравствуйте, IT, Вы писали:
IT>Я вот никогда не понимал, в чём вообще смысл разделения на DTO и BO? Потому что Фаулер так сказал?
Сокращение трафика, взаимодействие со сторонними сервисами, которые принимают данные по другой схеме чем та на которую завязывается собственная сериализация, чтобы ослабить связь между BO и DAL (иначе BO требует сборку DAL, а DAL требует сборку BO и кроме как динамической загрузкой сборок и фабрикой с синглетонами, или еще какими то хитрыми методами по типу динамических сборок, эту ситуацию не разрешить).

Здравствуйте, снежок, Вы писали:

С>Здравствуйте, IT, Вы писали:
IT>>Я вот никогда не понимал, в чём вообще смысл разделения на DTO и BO? Потому что Фаулер так сказал?
С>Сокращение трафика,

За счёт чего?

С>взаимодействие со сторонними сервисами, которые принимают данные по другой схеме чем та на которую завязывается собственная сериализация,

Для сторонних сервисов обычно пишутся агенты, которые работают по схеме DAL, только не для БД, а для стороннего сервиса.

С>чтобы ослабить связь между BO и DAL (иначе BO требует сборку DAL,

А это ещё с какой радости?

С>а DAL требует сборку BO и кроме как динамической загрузкой сборок и фабрикой с синглетонами, или еще какими то хитрыми методами по типу динамических сборок, эту ситуацию не разрешить).

Да уж. Видимо у нас разное понимание что такое BO и какие у него функции. Ну да ладно.

Здравствуйте, IT, Вы писали:

С>>Сокращение трафика,
IT>За счёт чего?
За счет того что не передаются ненужные данные. Например, если один BO ссылается на другой, то для такой ссылки передается идентификатор, а не весь граф объекта с прочей шелухой (наименования...). Я конечно понимаю что могут существовать различные схемы, например, собственная сериализация, но все это не так прозрачно...
С>>взаимодействие со сторонними сервисами, которые принимают данные по другой схеме чем та на которую завязывается собственная сериализация,
IT>Для сторонних сервисов обычно пишутся агенты, которые работают по схеме DAL, только не для БД, а для стороннего сервиса.
С>>чтобы ослабить связь между BO и DAL (иначе BO требует сборку DAL,
IT>А это ещё с какой радости?
Например, возьмем lazy load.
Если BO работает всегда только через сервисы, независимо от контектса приложения, обращается ли этот BO за данными находясь на клиенте или внутри сервиса, тогда вопрос "А это ещё с какой радости" правомерен.
Но если вы хотите максимально оптимизировать производительность и сократить цепочку вызовов, то находясь на клиенте BO обращается к сервисам, а находясь внутри сервиса BO обращается к DAL (не зачем сервису в данном случае обращаться самому к себе, происходит локальный вызов).
Определить контекст приложения и направить вызов сервису или DAL — дело сервисных агентов или в данном случае более уместно понятие ProxyAgent.
С>>а DAL требует сборку BO и кроме как динамической загрузкой сборок и фабрикой с синглетонами, или еще какими то хитрыми методами по типу динамических сборок, эту ситуацию не разрешить).
IT>Да уж. Видимо у нас разное понимание что такое BO и какие у него функции. Ну да ладно.
Мое понимание BO основывается на книге: Rockford Lhotka. C# Business Object

Здравствуйте, снежок, Вы писали:

IT>>Да уж. Видимо у нас разное понимание что такое BO и какие у него функции. Ну да ладно.
С>Мое понимание BO основывается на книге: Rockford Lhotka. C# Business Object

Мне, например, Lhotka не понравился...
Можешь посмотреть еще книги Eric Evans и Jimmi Nielsen (нажеюсь имена правильно пишу)по Domain-Driven Design. Просто в них описан не один подход (архиетктура), как в "C# Business Object", а несколько...

Здравствуйте, IT, Вы писали:

IT>Я вот никогда не понимал, в чём вообще смысл разделения на DTO и BO? Потому что Фаулер так сказал?

Кстати, кто-то пробовал передавать по WCF дата контракты (DTO) содержащие классы наследованые от EditableObject?
Все хочется попробовать, да руки не дойдут...

Здравствуйте, varely, Вы писали:
V>Просто в них описан не один подход (архиетктура), как в "C# Business Object", а несколько...
Подходов то, по пальцам пересчитать одной руки хватит...

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, снежок, Вы писали:

С>>Суть в том чтобы все get-ы и set-ы BO работали с DTO, а не приватными мемберами соответствующих свойств BO.

IT>Я вот никогда не понимал, в чём вообще смысл разделения на DTO и BO? Потому что Фаулер так сказал?


например сложности с сериализацией BO

Здравствуйте, EM, Вы писали:

IT>>Я вот никогда не понимал, в чём вообще смысл разделения на DTO и BO? Потому что Фаулер так сказал?

EM>например сложности с сериализацией BO

Например?

Здравствуйте, снежок, Вы писали:

С>Суть в том чтобы все get-ы и set-ы BO работали с DTO, а не приватными мемберами соответствующих свойств BO.
С>DTO представяет собой простую структуру (OrderDTO).
С>Плюсы очевидны:
С>+ BO не загромождены приватными членами свойств, код зрительно более приятный.
С>+ Не требуется (или минимальный) маппинг BO->DTO для передачи DTO сервисам и DataAccessLayer-у, так же отпадает необходимость реализации всяких criteria-паттернов (like criteria in CSLA.NET).

С>Вопрос:
С>А какие минусы или подводные камни у такого подхода?
С>Могут ли здесь возникнуть сложности при использовании mapper-helper-ов, того же BusinessToolKit-а?

Ни разу ещё не сталкивался с необходимостью выделять DTO в отдельную сущность. Данные находятся в том же классе где и свойства и нет никакого смысла их разделять.

В Java большинство (если не все) тулкиты справляются с частичной сериализацией. То есть если используется маппинг, то сериализуется только то что намаплено. Если используется сериализатор, то у него всегда есть средства указать какие поля или свойства не надо сериализовать.

Так же, мне кажется, что подобный подход немного нарушает инкапсуляцию слоев. Ведь DTO это интеграционный момент и он зависит от логики слоя интеграции. Тогда как слой бизгнес сущностей и бизнес логики должен быть максимально независим от внешних моментов.

Здравствуйте, Blazkowicz, Вы писали:

B>Ни разу ещё не сталкивался с необходимостью выделять DTO в отдельную сущность.

Я тоже пока ни разу Но есть другие джависты, которые пишут книжки и пропагандируют в них свою точку зрения. А потом эти книжки читают дотнетчики и начинают задавать вот такие вопросы.

Здравствуйте, IT, Вы писали:

IT>Я тоже пока ни разу Но есть другие джависты, которые пишут книжки и пропагандируют в них свою точку зрения. А потом эти книжки читают дотнетчики и начинают задавать вот такие вопросы.

А можно поконкретнее кто именно? По-моему DTO ушли в небитие вместе с EJB2

Здравствуйте, Blazkowicz, Вы писали:

IT>>Я тоже пока ни разу Но есть другие джависты, которые пишут книжки и пропагандируют в них свою точку зрения. А потом эти книжки читают дотнетчики и начинают задавать вот такие вопросы.

B>А можно поконкретнее кто именно? По-моему DTO ушли в небитие вместе с EJB2

Как кто? Дядька Фаулер Ваших кровей, джавист

Здравствуйте, IT, Вы писали:

IT>>>Я тоже пока ни разу Но есть другие джависты, которые пишут книжки и пропагандируют в них свою точку зрения. А потом эти книжки читают дотнетчики и начинают задавать вот такие вопросы.

B>>А можно поконкретнее кто именно? По-моему DTO ушли в небитие вместе с EJB2

IT>Как кто? Дядька Фаулер Ваших кровей, джавист

Да Фаулер. Да джавист. Да пишет про DTO. Но нет не могу согласится с тем что он особо его пропагандирует. Да есть такой паттерн. Да его можно использовать так-то.
"Patterns of Enterprise Application Architecture" опирается во многом на EJB2. Поэтому там про DTO подробно разжевано. Но мир-то изменяется. Уже появился материал вроде этого, который во многом пытается вскрыть недостатки DTO.

Здравствуйте, Blazkowicz, Вы писали:

B>Да Фаулер. Да джавист. Да пишет про DTO. Но нет не могу согласится с тем что он особо его пропагандирует. Да есть такой паттерн. Да его можно использовать так-то.
B>"Patterns of Enterprise Application Architecture" опирается во многом на EJB2. Поэтому там про DTO подробно разжевано. Но мир-то изменяется. Уже появился материал вроде этого, который во многом пытается вскрыть недостатки DTO.

Меня не надо уговаривать. Я не понимал пользы от DTO ни до Фаулера, ни после

Здравствуйте, IT, Вы писали:

IT>Меня не надо уговаривать.
Никто не уговаривает тебя его пользовать. Но отрицать факты что есть паттерн DTO и что у него есть своя ниша не имеет смысла.

IT>Я не понимал пользы от DTO ни до Фаулера, ни после
Счастливчик, ты не имел дело с говноспецификациями вроде EJB? По-моему существует ряд ситуаций, где вполне можно применить DTO. Но я сейчас не хочу высасывать примеры из пальца, так как реально с такой надобностью не сталкивался.

Здравствуйте, Blazkowicz, Вы писали:

IT>>Меня не надо уговаривать.
B>Никто не уговаривает тебя его пользовать. Но отрицать факты что есть паттерн DTO и что у него есть своя ниша не имеет смысла.

Я где-то утверждал обратное?

IT>>Я не понимал пользы от DTO ни до Фаулера, ни после
B>Счастливчик, ты не имел дело с говноспецификациями вроде EJB? По-моему существует ряд ситуаций, где вполне можно применить DTO. Но я сейчас не хочу высасывать примеры из пальца, так как реально с такой надобностью не сталкивался.

DTO очень просто превращаются в Business Entities. Казалось бы разница небольшая, но это уже совсем другое дело.

Здравствуйте, 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 в формат другого лэйера.

Здравствуйте, IT, Вы писали:

IT>Для начала хорошо бы разобраться что ты понимаешь под бизнес сущностью. В моём понимании бизнес логике в бизнес сущностях вообще делать нечего.

Если логика ограничена состоянием этой сущности, то в этой сущности логике самое место. В общем слишком категорично. Да и офтопик, можно просто продожить здесь

Автор: jburden
Дата: 19.07.06

.

IT>Этим должны заниматься мапперы. Ты предлагаешь из формата чуждого приложения всё перекладывать сначала в DTO, а уже затем в бизнес сущности. Учитывая, что у тебя структуры радикально отличные, саму задачу перевода данных из одного формата в другой тебе всё равно придётся мучать. С помощью сериализаторов, мапперов или вручную, без разницы. А если так, то один шаг здесь явно лишний.

IT>Здесь Фаулер пишет не о разных приложениях с радикально отличной структурой, а о разных лэйерах. Добиться significant mismatch в этом случае надо ещё постараться. Если же модели действительно столько различны, то нужен маппер для перевод одной модели в другую, а не DTO, подходящие по структуре к одной из моделей и опять же маппер для трансофрмации этих DTO в формат другого лэйера.

Со всеми доводами согласен. Не согласен только с твоей категоричностью. Так что тему можно дальше не развивать.

Здравствуйте, Blazkowicz, Вы писали:

IT>>Для начала хорошо бы разобраться что ты понимаешь под бизнес сущностью. В моём понимании бизнес логике в бизнес сущностях вообще делать нечего.

B>Если логика ограничена состоянием этой сущности, то в этой сущности логике самое место. В общем слишком категорично.

Тогда хорошо бы разобраться с тем, что ты понимаешь под бизнес логикой

B>Да и офтопик, можно просто продожить здесь

Автор: jburden
Дата: 19.07.06

.

Участникам этого топика продолжение уже не интересно.

IT>>Этим должны заниматься мапперы. Ты предлагаешь из формата чуждого приложения всё перекладывать сначала в DTO, а уже затем в бизнес сущности. Учитывая, что у тебя структуры радикально отличные, саму задачу перевода данных из одного формата в другой тебе всё равно придётся мучать. С помощью сериализаторов, мапперов или вручную, без разницы. А если так, то один шаг здесь явно лишний.

IT>>Здесь Фаулер пишет не о разных приложениях с радикально отличной структурой, а о разных лэйерах. Добиться significant mismatch в этом случае надо ещё постараться. Если же модели действительно столько различны, то нужен маппер для перевод одной модели в другую, а не DTO, подходящие по структуре к одной из моделей и опять же маппер для трансофрмации этих DTO в формат другого лэйера.

B>Со всеми доводами согласен. Не согласен только с твоей категоричностью. Так что тему можно дальше не развивать.

При чём тут категоричность? Это выглядит, как будто ты не согласен с формой высказывания и из-за этого отрицаешь и само содержание.

Здравствуйте, IT, Вы писали:

B>>Если логика ограничена состоянием этой сущности, то в этой сущности логике самое место. В общем слишком категорично.

IT>Тогда хорошо бы разобраться с тем, что ты понимаешь под бизнес логикой

Почитал определение в википедии, ничего нового для себя не открыл, подразумеваю под бизнес логикой то же что и все. И не вижу никаких проблем возникающих при помещении некоторой части этой логики в классы описывающие-бизнес сущности.


B>>Да и офтопик, можно просто продожить здесь

Автор: jburden
Дата: 19.07.06

.
IT>Участникам этого топика продолжение уже не интересно.
Ну, тогда продолжим здесь. Где по-твоему распологается бизнес логика и покакой причине ей не место в сущностях?

Здравствуйте, Blazkowicz, Вы писали:

B>>>Если логика ограничена состоянием этой сущности, то в этой сущности логике самое место. В общем слишком категорично.

IT>>Тогда хорошо бы разобраться с тем, что ты понимаешь под бизнес логикой

B>Почитал определение в википедии, ничего нового для себя не открыл, подразумеваю под бизнес логикой то же что и все.

Бизнес логика, и тем более её определение в википедии, вещь весьма размытая. Но вот то, что можно поместить в business entities имеет очень чёткие ограничения. По-этому я и спрашиваю.

B>И не вижу никаких проблем возникающих при помещении некоторой части этой логики в классы описывающие-бизнес сущности.

Я тоже не вижу. Вопрос только в определении некоторости. Скажу даже больше. Именно наличие логики отличает тупые DTO от business entities.

B>>>Да и офтопик, можно просто продожить здесь

Автор: jburden
Дата: 19.07.06

.
IT>>Участникам этого топика продолжение уже не интересно.
B>Ну, тогда продолжим здесь. Где по-твоему распологается бизнес логика и покакой причине ей не место в сущностях?

Бизнес логика, как общее понятие, распологается везде. В бизнес сущностях (опять же, если мы подразумеваем под этим понятием одно и тоже) не место логике, делающей эти сущности привязанными к другим частям системы. Впрочем, ты утверждаешь тоже самое. Так вот, теперь вернёмся немного назад. Вопрос. Зачем вообще нужны DTO как промежуточный тип контейнеров, если с этой задачей могут прекрасно справиться entitie? Где здесь логика? Может в неверно выбранном дизайне? Или я всё же чего-то не понимаю и действительно бывают случаи где DTO немерянно рулят?

Здравствуйте, IT, Вы писали:

IT>Я тоже не вижу. Вопрос только в определении некоторости. Скажу даже больше. Именно наличие логики отличает тупые DTO от business entities.
Не только. Сущность может не содержать логики и при этом не быть DTO.

IT>Бизнес логика, как общее понятие, распологается везде. В бизнес сущностях (опять же, если мы подразумеваем под этим понятием одно и тоже) не место логике, делающей эти сущности привязанными к другим частям системы. Впрочем, ты утверждаешь тоже самое. Так вот, теперь вернёмся немного назад. Вопрос. Зачем вообще нужны DTO как промежуточный тип контейнеров, если с этой задачей могут прекрасно справиться entitie? Где здесь логика? Может в неверно выбранном дизайне?
В общем я не вижу смысла в продолжении дискуссии, так как мы с тобой высказываем одни и те же мысли разными словами.

IT>Или я всё же чего-то не понимаю и действительно бывают случаи где DTO немерянно рулят?
Ты их не видел, и я их не видел. Но ведь это не значит что их нет?

Здравствуйте, Blazkowicz, Вы писали:

IT>>Или я всё же чего-то не понимаю и действительно бывают случаи где DTO немерянно рулят?
B>Ты их не видел, и я их не видел. Но ведь это не значит что их нет?

Э, нет. В отличии от тебя, мне очень хочется на них посмотреть. Реально взглянуть и увидеть приносимую ими пользу. Пока же я вижу, от DTO никакой пользы нет и их использование является результатом архитектурных косяков. Если это не так, то кто-нибудь убедите меня в обратном.

Здравствуйте, 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>

Здравствуйте, 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, только данные вычитываются не из датаридеров, а из формата внешней системы.

Здравствуйте, 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 моментально отпадёт.

Здравствуйте, 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 слить в одно — описание данных. В таком случае отпадает проблема как транспортировки данных (не ООП-структуры очень хорошо перегоняются через границы процессов), как маппинга данных (тоже самое что и передача данных, так как маппинг и сериализация из одного теста вылеплены), так и манипулирования данных (никаких проблем с кэшами и погрузкой по необходимости, так как все контролируется нами и не чёрти какими недо-мапперами). А переконвертация одного в другое и наоборот только добавляет лишней головной боли.

Здравствуйте, 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 в силу специфики предметной области) я уже описал.здесь

Автор: GlebZ
Дата: 07.01.07

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 в силу специфики предметной области) я уже описал.здесь

Автор: GlebZ
Дата: 07.01.07

Глеб, ты меня извини, но разговоры о специфичности предметной области лично мне ничего не доказывают. У меня таких специфичных задач было мильён. При изначальном дизайне, ориентированном на отсутствие всяких промежуточных DTO, потребность в них возникала только в случае затыкания каких-нибудь дыр. А то, что ты привёл по ссылке мы уже разобрали и пока реальной необходимости в DTO там не нашли.

IT>>Всё равно не понял. Какое это имеет отношение к DTO? Если у тебя уже есть маленькие объекты, которые ты кешируешь, ну так и гоняй их туда сюда. В чем проблема?
GZ>Сервак по внутренней логике не работает с маленькими объектами. Набор полей используемый в серверной логике и на клиентской стороне сильно различается.

Я уже сто раз говорил, что проблема согласования объектных моделей решается не с помощью DTO, а с помощью мапперов.

IT>>Я тоже повторюсь. DTO, как затыкание косяков, может оказаться вполне оправданной вещью. Только давай отдавать себе отчёт, что косяк он и есть косяк. В вашем случае — это использование дремучего ASP. Стоит переписать всё на ASP.NET и необходимость в DTO моментально отпадёт.
GZ>Ага. Здоровски. Предлагаешь попросить клиента переписать свою систему которую они строили много лет?

Твои клинты с их проблемами меня мало интересуют. У меня своих полно. От тебя же здесь нужно всего лишь осознание того, что конкретно в этой ситуации DTO как раз являются вынужденной мерой ака затычкой в дизайне. Именно это я и пытаюсь до тебя донести. Пойми, я не против DTO как паттерна. Я лишь против того, что это хороший паттерн. По моему, теперь уже глубочайшему убеждению, наличие в системе DTO говорит лишь о том, что в дизайне этой системы есть проблемы. Убеждать меня в обратном абстрактными разговорами об уникальности свой предметной области не надо. А вот конкретные примеры, ещё лучше с кусочками кода, я бы с удовольствием посмотрел. А затем мы вместе бы разобрали можно ли там было обойтись без DTO или нет.

Здравствуйте, 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, Вы писали:


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. Клиент развивался достаточно отдельно от сервера и оперативно решал свои задачи. Посему и модель БД у него расходится с серверной. Это вполне нормальное решение.

Это не нормальное решенте. Нормальное решение должно учитывать требования клиента при разработке сервера. У нас же получилась примочка сбоку. Как ты думаешь, почему сервис януса переписывался несколько раз?

Здравствуйте, 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>Это уж вам видней.

Вот именно.

Здравствуйте, IT, Вы писали:

IT>Не знаем. Но знаем, что речь идёт как минимум о .NET, где реальных причин, озвученных тобой выше, для использования DTO пока не обнаружено. Вывод напрашивается сам собой.

Тоже прошу прощения, что встреваю. Вот по этой ссылке

Автор: MaximVK
Дата: 20.10.06

я описывал стандартнейшую ситуацию, где использование DTO единственный разумный выход. Если следовать твоей логике, то здесь или ошибка в дизайне, или можно все упаковать в entity, или мы по разному понимаем термин DTO. В последнем я сомневаюсь, т.к. данное тобой определение вполне вполне подходит под эту ситуацию.

Здравствуйте, MaximVK, Вы писали:

MVK>Здравствуйте, IT, Вы писали:

IT>>Не знаем. Но знаем, что речь идёт как минимум о .NET, где реальных причин, озвученных тобой выше, для использования DTO пока не обнаружено. Вывод напрашивается сам собой.

Хотел добавить вчера, что DTO бывает полезен в тех случаях, когда уже ничего больше не помогает.

MVK>Тоже прошу прощения, что встреваю. Вот по этой ссылке

Автор: MaximVK
Дата: 20.10.06

я описывал стандартнейшую ситуацию, где использование DTO единственный разумный выход.

особенно вытащить все продукты в заказе, чтобы узнать их количество

Количество продуктов узнается перед тем, как делать запрос по выборке этих самых продуктов. Тот же paging работает по схожему методу.

Здравствуйте, MaximVK, Вы писали:

MVK>Тоже прошу прощения, что встреваю. Вот по этой ссылке

Автор: MaximVK
Дата: 20.10.06

я описывал стандартнейшую ситуацию, где использование DTO единственный разумный выход. Если следовать твоей логике, то здесь или ошибка в дизайне, или можно все упаковать в entity, или мы по разному понимаем термин DTO. В последнем я сомневаюсь, т.к. данное тобой определение вполне вполне подходит под эту ситуацию.

Для такой ситуации, очевидно, оверхед по вытаскиванию всех этих данных будет слишком большой(особенно вытащить все продукты в заказе, чтобы узнать их количество). Поэтому лучше создать какой-нить DTO класс, который будет содержать исключительно необходимую информацию.

А как ты будешь узнавать количество продуктов в заказе для DTO?

Здравствуйте, 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 и тоже использоваться только для этой задачи — это как раз то, что нужно. Где логика?

Здравствуйте, 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-к-одному, как на сервере? Ведь это же оффлайн-клиент всё-таки, он обязан долговременно и функционально работать сам по себе.

Здравствуйте, IT, Вы писали:

IT>Нормальное решение должно учитывать требования клиента при разработке сервера. У нас же получилась примочка сбоку.

Про это АВК писал.

IT> Как ты думаешь, почему сервис януса переписывался несколько раз?

А вот про это нет. Было более, чем два раза? Причём второй раз всё ещё not used jet. Правки всяких дыр и проч. как бы не в счёт.

Здравствуйте, MaximVK, Вы писали:

MVK> Теперь про обучение BE. Подход, который ты предлагаешь, со временем в целях оптимизации, потребует частичного заполнения бизнес-сущностей. Что, в свою очередь, повлечет необходимость добавления методов вида IsOrderNameSpecified(), IsOrderDateCreatedSpecified() и т.д. для каждого поля BE. Далее, код, который использует BE должен будет предварительно вызвать этот метод, чтобы убедиться, что поле, которое он собирается использовать, определено. Также посыпятся методы BE которые используют внутренние поля, например методы вида GetUserFullName(), который из FirstName и LastName делает полное имя, т.к. BE не должна уметь сама себя загружать то от таких методов придется или избавиться, или сделать проверочный метод, или вышвыривать исключение. Частично заполненые объекты требует крайне внимательного с ними обращения и являются потенциальным источником большого количества трудно обнаружимых ошибок.

Это всё твои домыслы и ничего более. Никто никаких методов без крайней необходимости писать не будет. Необходимость проверки полей мне не будет нужна по одной простой причине. Если я не включаю данные в объект, то логично предположить, что я не собираюсь их использовать. Неожиданный поворот, не правда ли

MVK>Пример, который я привел — это DTO которое используется для отображений данных в гриде.

После вот этого утверждения дискуссию можно было бы закончить. То, что ты называешь DTO — это вовсе не DTO, это как раз и есть то, о чём я говорю. У DTO одно единственное предназначение — transfer. У тебя же объект, который максимально подогнан не под transfer, а под отображение в гриде. Это нормально, это и есть BE, отражающая твою объектную модель, модель, используемую в UI. Или у UI приложения не может быть своей объектной модели?

В общем, ты теперь сам должен определиться. Либо ты продолжаешь утвеждать, что это DTO, но соглашаешься с тем, что ты грубо нарушил заветы паттерна, либо признать, что на лицо элементарная путаница в терминологии. Выбирать тебе

MVK>Ты предлагаешь мне проектировать мои BE, так чтобы их было удобно изображать на гриде? Но это две совершенно разные задачи. Business entities — суть контейнеры для данных описывающие предметную область, язык на котором общаются другие компоненты системы. Вероятность изменения BE значительно ниже, чем вероятность изменения требований о представлении данных клиентами, т.к. первые отражают значительно более инертную предметную область(я уже молчу про индустриальные стандарты, которые тоже находят отражения в BE).

Давай попробуем разобраться без догм и фанатизма. Что такое контейнеры для данных, описывающие предметную область или что угодно другое? Это объектная модель, на которой строится функциональность приложения. Верно? Верно. У клиентского UI приложения может быть своя объектная модель, на которой строится фукнциональность UI приложения? Может. Тогда какая по сути принципиальная разница между объетной моделью UI приложения и BE, которые есть контейнеры данных, описывающие предметную область? Совершенно верно, ни-ка-кой. И то, и другое суть контейнеры, предназначение которых обеспечить совместно с логикой приложения работу системы в соответствии с функциональными требованиями.

Здравствуйте, akasoft, Вы писали:

A>Гм. А как оценивается тобою вот этот вариант? Он как стыкуется с БО, используемыми сервером?

С этим сервисом я детально не разбирался.

Здравствуйте, akasoft, Вы писали:

A>Полагаю, тут немалое влияние оказало и то, кто и как развивал проект. Квалификация и опыт самые разные.

Это понятно. Я ни в коем случае никого не осуждаю и не виню. Хотя бы потому, что среди виновных моё место было бы не последним, гы-гы. Но назвать идеальным дизайн сайта в целом и януса в частности я не могу и как пример стройности архитектуры приводить не собираюсь.

A>И почему, собственно, БО в Янусе должны быть 1-к-одному, как на сервере? Ведь это же оффлайн-клиент всё-таки, он обязан долговременно и функционально работать сам по себе.

Дело не в одинаковости моделей. Мы здесь спорим не об этом. Мы пытаемся понять необходимость DTO для переноса данных из одного приложения в другое.

Здравствуйте, IT, Вы писали:

IT>После вот этого утверждения дискуссию можно было бы закончить. То, что ты называешь DTO — это вовсе не DTO, это как раз и есть то, о чём я говорю. У DTO одно единственное предназначение — transfer. У тебя же объект, который максимально подогнан не под transfer, а под отображение в гриде. Это нормально, это и есть BE, отражающая твою объектную модель, модель, используемую в UI. Или у UI приложения не может быть своей объектной модели?

Вот в данном случае не соглашусь. Основная цель DTO, как и всего презентационного слоя является изоляция логики сервера от логики клиента. DTO — является частью презентационного слоя. Эффективная пересылка — это уже другая цель. Какая там логика на клиенте — серверу неизвестно и должно быть по барабану. Это в принципе не должно быть известно и DTO и презентационному слою. Его первичная цель предоставить эффективный доступ к функциональности сервера для всех клиентов.
Идеальным решением было бы связка XQuery/XML/Schema, и отношение к DTO не как объекту, а как набору данных. Тогда каждый клиент мог бы заказать не только какие с какими условиями и в какой последовательности объекты ему нужны. Но и в каком виде. К сожалению это решение достаточно сложное и много проблем при реализации.

Здравствуйте, IT, Вы писали:

IT>Это всё твои домыслы и ничего более. Никто никаких методов без крайней необходимости писать не будет. Необходимость проверки полей мне не будет нужна по одной простой причине. Если я не включаю данные в объект, то логично предположить, что я не собираюсь их использовать. Неожиданный поворот, не правда ли

Отнюдь, вполне ожидаемый , т.к. именно эта аргументация приводиться чтобы оправдать такой подход. Неожиданность в другом — я не ожидал услышать такой, прямо скажем, слабой аргументации от тебя. Для небольшого проекта или прототипирования — это вполне разумный подход, который экономит время, а количество кода, сотрудников и продолжительность времени разработки позволяет не потерять эту информацию из виду. Для больших проектов это, очевидно, не верно. Т.к. если по коду начала гулять не полностью заполненая BE, нет гарантии, что она не попадет в метод, который расчитывает, что некоторое поле в этой BE обязательно должно быть проинициалированным. Другими словами, выполнение правила "Все поля BE должны быть проинициализированы" гораздо легче контролировать, чем выполнения правила "Частично заполненные BE не должны попасть в код, который будет использовать непроинициалированные поля". Т.к. в первом случае, мы должны контролировать только точки создания BE, а во втором все дерево переходов BE по коду. Я могу согласиться с таким подходом лишь в случае проектирования внешнего API к системе, т.к. видел пример хорошего решения(eBay XML и SOAP API). Там в каждом запросе к API передается поле DetailLevel и для каждого запроса в документации определена таблица для каких значений DetailLevel, какие поля будут возвращены.

IT>После вот этого утверждения дискуссию можно было бы закончить.
Ну это утверждение было известно до начала дискуссии, т.к. в посте на который я привел ссылку было сказано

С другой стороны, пусть тебе нужны данные для грида где ты отображаешь информацию...

Впрочем, с остальным я согласен. Отмечу только, что поведение и цели подобных классов слишком сильно отличаются скажем, то тех же Order, Customer или Address. Отличие в следующем:
1. Эти контейнеры предназначены исключительно для передачи информации наружу из бизнес-логики. Т.е. они не принимают участие во внутренних процессах.
2. Вероятность изменения для них значительно выше, т.к. они в большей степени зависят от мимолетных пожеланий клиентов, чем от инертной предментной области.
...
Эти отличия должны быть явно зафиксированы в коде, например введением абстрактного класса или использованием атрибутов, т.к. такой подход значительно упрощает жизнь в дальнейшем. Кроме того, учитывая, что изменения обоих типов зависят от разных требований — они должны быть соотвественно разделены и физически.

IT>Давай попробуем разобраться без догм и фанатизма. Что такое контейнеры для данных, описывающие предметную область или что угодно другое? Это объектная модель, на которой строится функциональность приложения. Верно? Верно. У клиентского UI приложения может быть своя объектная модель, на которой строится фукнциональность UI приложения? Может. Тогда какая по сути принципиальная разница между объетной моделью UI приложения и BE, которые есть контейнеры данных, описывающие предметную область? Совершенно верно, ни-ка-кой. И то, и другое суть контейнеры, предназначение которых обеспечить совместно с логикой приложения работу системы в соответствии с функциональными требованиями.

Тоже согласен, с небольшими "но" описанными выше.

Здравствуйте, GlebZ, Вы писали:

GZ>Вот в данном случае не соглашусь. Основная цель DTO, как и всего презентационного слоя является изоляция логики сервера от логики клиента. DTO — является частью презентационного слоя. Эффективная пересылка — это уже другая цель.

Разве? А если обмен осуществляется не между презентационным слоем и сервером, а между одним сервером и другим? То что такое DTO в данном случае?

Не надо давать свою интерпретацию терминам. DTO — это data transfer object. Заметь — transfer, не DTPO — data transfer & presentation object. Только transfer.

Здравствуйте, IT, Вы писали:

IT>Не надо давать свою интерпретацию терминам. DTO — это data transfer object. Заметь — transfer, не DTPO — data transfer & presentation object. Только transfer.
Presentation — это слой. И DTO является частью его.

Здравствуйте, MaximVK, Вы писали:

IT>>Это всё твои домыслы и ничего более. Никто никаких методов без крайней необходимости писать не будет. Необходимость проверки полей мне не будет нужна по одной простой причине. Если я не включаю данные в объект, то логично предположить, что я не собираюсь их использовать. Неожиданный поворот, не правда ли

MVK>Отнюдь, вполне ожидаемый , т.к. именно эта аргументация приводиться чтобы оправдать такой подход. Неожиданность в другом — я не ожидал услышать такой, прямо скажем, слабой аргументации от тебя.

Ну тогда послушай, что тебе говорят. Все твои опасения напрасны. Минусы у такого подхода конечно есть, но они мизрны по сравнению с теми плюсами, которые он даёт.

MVK>Для небольшого проекта или прототипирования — это вполне разумный подход, который экономит время, а количество кода, сотрудников и продолжительность времени разработки позволяет не потерять эту информацию из виду. Для больших проектов это, очевидно, не верно.

Дать определение большого проекта не затруднит?

MVK>Т.к. если по коду начала гулять не полностью заполненая BE, нет гарантии, что она не попадет в метод, который расчитывает, что некоторое поле в этой BE обязательно должно быть проинициалированным. Другими словами, выполнение правила "Все поля BE должны быть проинициализированы" гораздо легче контролировать, чем выполнения правила "Частично заполненные BE не должны попасть в код, который будет использовать непроинициалированные поля". Т.к. в первом случае, мы должны контролировать только точки создания BE, а во втором все дерево переходов BE по коду.

Тогда вернёмся на несколько постов назад. По-твоему, если у тебя есть объект из 30 полей, но тебе нужно только 5, то ты создаш новый объект. Если же тебе понадобились 6 полей, то ещё один объект, если 6, но других, то по объекту на каждую комбинацию, если 7, то все возможные комбинации и так далее. Я тебя правильно понимаю?

MVK>Я могу согласиться с таким подходом лишь в случае проектирования внешнего API к системе, т.к. видел пример хорошего решения(eBay XML и SOAP API). Там в каждом запросе к API передается поле DetailLevel и для каждого запроса в документации определена таблица для каких значений DetailLevel, какие поля будут возвращены.

Так в чём проблема? Если речь идёт о большом проекте, то сопроводи свой метод спецификаций.

IT>>После вот этого утверждения дискуссию можно было бы закончить.
MVK> Ну это утверждение было известно до начала дискуссии, т.к. в посте на который я привел ссылку было сказано

С другой стороны, пусть тебе нужны данные для грида где ты отображаешь информацию...

Извини, не заметил.

MVK>Впрочем, с остальным я согласен. Отмечу только, что поведение и цели подобных классов слишком сильно отличаются скажем, то тех же Order, Customer или Address. Отличие в следующем:
MVK>1. Эти контейнеры предназначены исключительно для передачи информации наружу из бизнес-логики. Т.е. они не принимают участие во внутренних процессах.

Блин, ну вот опять начинается Как же они не принимают участие во внутренних процессах, если задача внутренных процессов как раз и заключается в том, чтобы создать структуру из таких объектов и вернуть её клиенту. Это и есть работа этих самых внутренных процессов.

MVK>2. Вероятность изменения для них значительно выше, т.к. они в большей степени зависят от мимолетных пожеланий клиентов, чем от инертной предментной области.

Эти изменения прежде всего неразрывно связаны с изменением логики работы сервера.

MVK>Эти отличия должны быть явно зафиксированы в коде, например введением абстрактного класса или использованием атрибутов, т.к. такой подход значительно упрощает жизнь в дальнейшем. Кроме того, учитывая, что изменения обоих типов зависят от разных требований — они должны быть соотвественно разделены и физически.

И почему же они тогда не разделены?

Hello, "GlebZ"
> Здравствуйте, IT, Вы писали:
>
> IT>Не надо давать свою интерпретацию терминам. DTO — это data
> transfer object. Заметь — transfer, не DTPO — data transfer &
> presentation object. Только transfer.
> Presentation — это слой. И DTO является частью его.

А можно, для тех кто в танке? т.е. DTO как часть presentation слоя
используются только в нем и выше? Или, data слой зависит от объектов
presentation слоя и все это дело крепко замешано друг на друга?

Здравствуйте, GlebZ, Вы писали:

IT>>Не надо давать свою интерпретацию терминам. DTO — это data transfer object. Заметь — transfer, не DTPO — data transfer & presentation object. Только transfer.
GZ>Presentation — это слой. И DTO является частью его.

А частью бизнес логики не является?

Здравствуйте, TK, Вы писали:

TK>А можно, для тех кто в танке? т.е. DTO как часть presentation слоя
TK>используются только в нем и выше? Или, data слой зависит от объектов
TK>presentation слоя и все это дело крепко замешано друг на друга?
Для тех кто в танках, самоходках и на доблестных кораблях краснознаменного балтийского флота. Слой — это добровольное обязательство разработчика для изоляции некоторой логики находящейся между другими слоями. Presentation layer, или иногда именуюмый фасадным слоем — это слой предназначенный для защиты независимости реализации бизнес-логики сервера от посягательтв клиентов. Сущности реализуемые в слое — по крайней мере не должны противоречить той цели ради которой построен слой. DTO — снимает проблему зависимости серверной бизнес-логики по данным.
Если мы не ставим себе задачу обеспечить независимость передаваемых данных от реализации бизнес-логики на сервере — хорошо. Баба с возу, кобыле легче. Заботу о формировании DTO обеспечивается стандартными средствами. Если мы должны это сделать по каким-то причинам — то это функция presentation layer.
Что касается смешения соседствующих слоев, а правильнее говорить о зависимости — то они безусловно зависят друг от друга, и это не есть противоречие.

Здравствуйте, IT, Вы писали:

GZ>>Presentation — это слой. И DTO является частью его.

IT>А частью бизнес логики не является?
Смотря что имеется ввиду под бизнес логикой. Если говорить о бизнес-логике как о реализации некоторой предметной логики — то нет. Это сервисная логика.

Здравствуйте, GlebZ, Вы писали:

GZ>>>Presentation — это слой. И DTO является частью его.

IT>>А частью бизнес логики не является?

GZ>Смотря что имеется ввиду под бизнес логикой. Если говорить о бизнес-логике как о реализации некоторой предметной логики — то нет. Это сервисная логика.

Я без понятия что такое предметная логика. Так же не знаком с термином сервисная логика. Поэтому, во избежании терминологической путаницы поясню, что для меня бизнес логика. Бизнес логика в моём понимании — это часть системы, которая занимается реализацией функциональных требований.

Ответь пожалуйста на вопрос, DTO являются частью этой логики? Если можно без изобретения новых терминов.

Здравствуйте, GlebZ, Вы писали:

GZ>Для тех кто в танках, самоходках и на доблестных кораблях краснознаменного балтийского флота. Слой — это добровольное обязательство разработчика для изоляции некоторой логики находящейся между другими слоями. Presentation layer, или иногда именуюмый фасадным слоем — это слой предназначенный для защиты независимости реализации бизнес-логики сервера от посягательтв клиентов.

О как! Presentation у нас уже стал синонимом контракта
Т.е. WPF, по-твоему, это не фреймворк для разработки UI, а нечно для создания фасадов серверов.
Я конечно всё понимаю, и вполне осознаю, что вся эта дискуссия всего лишь терминологический трёп. Но не до такой же степени

GZ>Сущности реализуемые в слое — по крайней мере не должны противоречить той цели ради которой построен слой. DTO — снимает проблему зависимости серверной бизнес-логики по данным.

Тут в соседней ветке MaximVK утверждает, что он использует DTO для того, чтобы поднять данные из базы, отправить их клиенту и там забаиндить их на грид. Т.е. его DTO участвуют в полном цикле запроса, от DAL до UI. Покажи мне здесь, пожалуйста, противоречивость и проблемы, которые снимают DTO.

GZ>Если мы не ставим себе задачу обеспечить независимость передаваемых данных от реализации бизнес-логики на сервере — хорошо. Баба с возу, кобыле легче. Заботу о формировании DTO обеспечивается стандартными средствами. Если мы должны это сделать по каким-то причинам — то это функция presentation layer.

Вообще-то, это называется контрактом. А как я уже говорил, число задач, где возникает реальная, а не высосанная из пальца необходимость в контрактах стремится к нулю.

Hello, "GlebZ"
> TK>Или, data слой зависит от объектов
> TK>presentation слоя и все это дело крепко замешано друг на друга?

> Для тех кто в танках, самоходках и на доблестных кораблях краснознаменного
> балтийского флота. Слой — это добровольное обязательство разработчика
> для изоляции некоторой логики находящейся между другими слоями.
> Presentation layer, или иногда именуюмый фасадным слоем — это слой
> предназначенный для защиты независимости реализации бизнес-логики сервера
> от посягательтв клиентов. Сущности реализуемые в слое — по крайней мере не
> должны противоречить той цели ради которой построен слой. DTO — снимает
> проблему зависимости серверной бизнес-логики по данным.

Круто загнул... Только что были гриды, биндинг на формочки а тут, бац... мы
уже на сервере Какой-то он слишком "жирный" этот presentaion layer при
таком подходе выходит. И данные на формочки маппит и со стороны сервера
доступ предоставляет... Не лучше бы его разделить? На сервере оставить фасад
предоставляющий сервисы, а на клиенте UI т.е. presentation. В любом случае,
не понятно как DTO снимает зависимость от серверной бизнес логики если части
клиентского presentation тоже крутятся на сервере...

> Что касается смешения соседствующих слоев, а правильнее говорить о
> зависимости — то они безусловно зависят друг от друга, и это не есть
> противоречие.

Слои должны смешиваться только в одном направлении. Если же смешение
происходит в обе стороны то, такой подход это однозначный кандидат на
очередной антипаттерн.

Здравствуйте, IT, Вы писали:

IT>Ответь пожалуйста на вопрос, DTO являются частью этой логики? Если можно без изобретения новых терминов.
Без изобретения есть функциональные требования, а есть нефункциональные требования. Генерация DTO — обеспечение нефункциональных требований.

Здравствуйте, GlebZ, Вы писали:

IT>>Ответь пожалуйста на вопрос, DTO являются частью этой логики? Если можно без изобретения новых терминов.
GZ>Без изобретения есть функциональные требования, а есть нефункциональные требования. Генерация DTO — обеспечение нефункциональных требований.

Я не задавал этот вопрос. Мой вопрос был являются ли DTO частью бизнес логики или нет.

Впрочем, твой ответ, если внимательно посмотреть, лишь подтверждает мои слова

Здравствуйте, IT, Вы писали:

IT>Тут в соседней ветке MaximVK утверждает, что он использует DTO для того, чтобы поднять данные из базы, отправить их клиенту и там забаиндить их на грид. Т.е. его DTO участвуют в полном цикле запроса, от DAL до UI. Покажи мне здесь, пожалуйста, противоречивость и проблемы, которые снимают DTO.
Сложность терминологии. У него нет как таковых BE. Он начал интерпретировать данные не как объект, а как данные.

IT>Вообще-то, это называется контрактом.
Правильно. А из чего состоит контракт в общем случае? Каким образом при версионификации серверов — можно публиковать и новый и старый контракты при более новой реализации?

IT>А как я уже говорил, число задач, где возникает реальная, а не высосанная из пальца необходимость в контрактах стремится к нулю.
Повторюсь. Зависит от специфики. Охотно верю что для тебя к нулю.

Здравствуйте, TK, Вы писали:

TK>Круто загнул... Только что были гриды, биндинг на формочки а тут, бац... мы
TK>уже на сервере Какой-то он слишком "жирный" этот presentaion layer при
TK>таком подходе выходит. И данные на формочки маппит и со стороны сервера
TK>доступ предоставляет... Не лучше бы его разделить? На сервере оставить фасад
TK>предоставляющий сервисы, а на клиенте UI т.е. presentation. В любом случае,
TK>не понятно как DTO снимает зависимость от серверной бизнес логики если части
TK>клиентского presentation тоже крутятся на сервере...
Есть у меня подозрение что у нас возникла сложность в терминологии. Под presentation layer не очень хороший термин, поскольку в разных технологиях обозначает разные вещи. Даю синонимы — service interface, remote facade, фасадные классы. UI — тут побоку.

TK>Слои должны смешиваться только в одном направлении. Если же смешение
TK>происходит в обе стороны то, такой подход это однозначный кандидат на
TK>очередной антипаттерн.
Нет. И к тому же это чаще просто невозможно сделать. Зависимости всегда остаются. Вызовы только с одной стороны можно сделать. Но изменение кода на одном слое могут выливаться изменения на соседних слоях.

Здравствуйте, IT, Вы писали:

IT>Я не задавал этот вопрос. Мой вопрос был являются ли DTO частью бизнес логики или нет.
Ты сам дал ответ.

Бизнес логика в моём понимании — это часть системы, которая занимается реализацией функциональных требований.

DTO — это обеспечение operation requirement.

IT>Впрочем, твой ответ, если внимательно посмотреть, лишь подтверждает мои слова
Какие?

Здравствуйте, GlebZ, Вы писали:

IT>>Я не задавал этот вопрос. Мой вопрос был являются ли DTO частью бизнес логики или нет.
GZ>Ты сам дал ответ.

Бизнес логика в моём понимании — это часть системы, которая занимается реализацией функциональных требований.

GZ>DTO — это обеспечение operation requirement.

Только что ты говорил, что DTO — это:

Без изобретения есть функциональные требования, а есть нефункциональные требования. Генерация DTO — обеспечение нефункциональных требований.

IT>>Впрочем, твой ответ, если внимательно посмотреть, лишь подтверждает мои слова
GZ>Какие?

Я теперь даже и сам не знаю. Ещё раз переспрошу, DTO относится к функциональным или нефункциональным требованиям?

Глеб, давай определяйся уже наконец, а то весь этот трёп уже начал утомлять

Здравствуйте, IT, Вы писали:

IT>>>Я не задавал этот вопрос. Мой вопрос был являются ли DTO частью бизнес логики или нет.
GZ>>Ты сам дал ответ.

Бизнес логика в моём понимании — это часть системы, которая занимается реализацией функциональных требований.

GZ>>DTO — это обеспечение operation requirement.

IT>Только что ты говорил, что DTO — это:
IT>

Без изобретения есть функциональные требования, а есть нефункциональные требования. Генерация DTO — обеспечение нефункциональных требований.

IT>
Вообще-то всегда был уверен что нефункциональные требования — являются переводом operation requirement

IT>Я теперь даже и сам не знаю. Ещё раз переспрошу, DTO относится к функциональным или нефункциональным требованиям?
IT>Глеб, давай определяйся уже наконец, а то весь этот трёп уже начал утомлять
Второе. Вроде и не утверждал обратного.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, Mika Soukhov, Вы писали:

MS>>Количество продуктов узнается перед тем, как делать запрос по выборке этих самых продуктов. Тот же paging работает по схожему методу.
GZ>Это смотря с какой стороны посмотреть. В случае 3-х звенки лучше сразу заказывать количество возвращаемых данных, и чтобы запрос вместе со страницей возвращал общее количество объектов. Потому как иначе нужно будет думать как поведет себя визуалка если между получением количества и получением последней страницы будет вставлен/удален какой-то объект.

IList<Items> GetItems(long ownerId, int pageNumber, int itemsPerPage, out totalCount)

Где здесь DTO и где возникнет ошибка?

Здравствуйте, IT, Вы писали:

IT>Дело не в одинаковости моделей. Мы здесь спорим не об этом. Мы пытаемся понять необходимость DTO для переноса данных из одного приложения в другое.

Тогла в Янусе те самые датасеты и есть DTO почти в чистом виде. Наверняка они из чего-то другого собираются на сервере, конечно с учтом параметров, переданных Янусом, и затем по получении в нём переносятся в ЛБД с добавлениями. Напрямую они практически не используются, хотя люську я и прицепил к ним, но это также можно рассматривать как "перенос в ЛБД".

В чём подлог, почему я не с той стороны смотрю и не вижу дыры в архитектуре? Ну да, датасеты можно было заменить коллекциями или массивами, что вроде и попробовали сделать.

Получается, что DTO сделало сайт и Янус менее связными, что позволило развивать их почти независимо друг от дружки. В этом, наверное, смысл. То, что на сервере можно вычислить запросом и не кешировать в Янусе для повышения производительности стали кешировать, как то списки тем. И т.п.

Здравствуйте, akasoft, Вы писали:

A>Тогла в Янусе те самые датасеты и есть DTO почти в чистом виде.

Датасеты передаются через веб-сервис как xml-структура, которая не опысана в WSDL. Это делает их неприменимыми из других платформ кроме .NET.

A>В чём подлог, почему я не с той стороны смотрю и не вижу дыры в архитектуре? Ну да, датасеты можно было заменить коллекциями или массивами, что вроде и попробовали сделать.

Что значит дыры? Речь идёт о том, что дизайн и имплеинтация сервиса для януса мог бы быть значительно лучше, если бы это учитывалось изначально при разработке сайта. Но в 2000 году об офлай клиенте речи вообще не было. Для нас тогда даже форумы имели второстепенное значение, соответственно и появились они лишь бы было.

A>Получается, что DTO сделало сайт и Янус менее связными, что позволило развивать их почти независимо друг от дружки. В этом, наверное, смысл. То, что на сервере можно вычислить запросом и не кешировать в Янусе для повышения производительности стали кешировать, как то списки тем. И т.п.

Менее связными понятие очень относительное. Например, в несколько таблиц на сервере было добавлены поля timestamp исключительно для поддержки януса. Была добавлена таблица, которая отслеживала изменения/удаления топиков. Без этого нормальная синхронизация януса невозможна. При этом работа с этой таблицой делается в местах, не имеющих к янусу прямого отношения. И как это расценивать, как большую связность или как маленькую?

Здравствуйте, GlebZ, Вы писали:

GZ>Второе. Вроде и не утверждал обратного.

Т.е. необходимость в DTO диктуется нефункциональными требованиями. Другими словами с помощью DTO уменьшается трафик и количество обращений к серверу. Другой пользы от DTO нет.

Но дело в том, что без этой "пользы" легко обойтись, а вместе с "пользой" и без вреда. Например, как выяснилось MaximVK называл DTO классы своей объектной модели клиента. Т.е. он совершенно безболезненно исключил DTO, но продолжил так называть то, что уже DTO не является. DTO как паттерн появился в джаве в бинах из-за каких то там проблем сериализации. Из-за пробем, которых в .NET никогда не было. Фаулер об этом паттерне расказал, забыв при этом упомянуть реальные проблемы, и вот уже все благодарные читатели пихают DTO куда ни попадя или же называют так всё, что уходит за пределы сервера.

Здравствуйте, IT, Вы писали:

IT>Т.е. необходимость в DTO диктуется нефункциональными требованиями. Другими словами с помощью DTO уменьшается трафик и количество обращений к серверу. Другой пользы от DTO нет.
Ну я бы так не сказал. Лучше более обще — повышает эффективность взаимодействия клиента с сервером. Любую фичу можно описать в чистых BE, но не всегда это эффективно.

IT>Но дело в том, что без этой "пользы" легко обойтись, а вместе с "пользой" и без вреда.
Мало того. У меня есть смутное подозрение что в большинстве приложений бизнес-логика так проста, что понятие BE избыточно. А работают с "совокупностью данных заказываемых/полученных клиентом".
IT>Например, как выяснилось MaximVK называл DTO классы своей объектной модели клиента. Т.е. он совершенно безболезненно исключил DTO, но продолжил так называть то, что уже DTO не является.
Честно говоря я сам грешен. Сам из так иногда называю. Не могу подобрать нормального термина под объекты пришедшие с сервера чтобы не путаться.
IT>DTO как паттерн появился в джаве в бинах из-за каких то там проблем сериализации. Из-за пробем, которых в .NET никогда не было.
Не уверен что нету.
IT>Фаулер об этом паттерне расказал, забыв при этом упомянуть реальные проблемы, и вот уже все благодарные читатели пихают DTO куда ни попадя
+1
IT> или же называют так всё, что уходит за пределы сервера.
Мне стыдно, и я промолчу.

Здравствуйте, IT, Вы писали:

IT>Ну тогда послушай, что тебе говорят. Все твои опасения напрасны. Минусы у такого подхода конечно есть, но они мизрны по сравнению с теми плюсами, которые он даёт.
Мои опасения — результат практического опыта. Основная проблема таких ошибок — они трудно уловимы, т.к. ислючение не вылетит, а поломается бизнес-логика. Т.к. частично проинициализированный объект ничем не отличается от объекта с такими же пустыми полями. Особенно активно такие ошибки вылазят в процессе поддержки приложения. Когда тут надо что-то подкрутить, там подправить, здесь учесть еще одно требование. Когда программист добавляет один маленький if по какому-то полю в одном из бизнес-компонентов, а потом выясняется, что это поле в 1% случаев бывает непроинициализированным. Твой аргумент "минусы мизерны по сравнению с плюсами" — ну никак не отвечает на вопрос, т.к. неизмерим. А на практике выясняется, что "плюсы" — это быстрое снятие 1% нагрузки на сервер, а "мизерные минусы" — это несколько баг репортов, затертые поля в базе, 3 дня работы саппорта и пара ушедших клиентов. Резюмируя:

1. Ошибки которые влечет такой подход трудно обнаружимы и не покрываются юнит-тестами.
2. Снижается универсальность бизнес-компонент в системе. Т.к. если при условии выполнения правила "все поля проинициализированы" предусловие контракта компонента выглядит как "дайте мне на вход экземпляр класса MyBE", то в случае отказа от этого правила выглядит как "дайте мне на вход экземпляр класса MyBE с проинициализированными полями p1,...pn". Думаю, не нужно пояснять, что контролировать выполнение такого контракта значительно труднее.
3. Снижается устойчивость кода к модификации, т.к. изменения совершаемые на уровне оперирования объектами должны учитывать более низкоуровневые сущности (поля объектов).
4. Попустительствование ошибкам в дизайне, связанным с удовлетворением такого нефункционального требования к системе, как производительность.
5. Усложняется паралельная разработка кода, т.к. увеличивается количество неявных условий, которые должны быть учтены программистом.
6. Усложняется процесс введения в проект новых людей, тоже по причине названной в пункте пять.

IT>Дать определение большого проекта не затруднит?
Большой проект термин, конечно, относительный. Поэтому определения не дам. Я опишу проект в котором эта проблема сказалась. Проект занял 4 года, коллектив рос от 5 до 12 человек(я считаю только программистов). Количество BE в проекте превышает 1000, не считая сторонних SDK, база состоит где-то из 500 таблиц, все это дело крутиться на 9 серверах. Большим проект назвать, конечно, трудно, а маленьким язык тоже не поворачивается.

IT>Тогда вернёмся на несколько постов назад. По-твоему, если у тебя есть объект из 30 полей, но тебе нужно только 5, то ты создаш новый объект. Если же тебе понадобились 6 полей, то ещё один объект, если 6, но других, то по объекту на каждую комбинацию, если 7, то все возможные комбинации и так далее. Я тебя правильно понимаю?

Нет, не правильно. Это крайность, которая, как и любая другая, популярна, потому что избавляет от необходимости думать, утверждая: делай всегда так и будет тебе счастье.
Для принятия правильного решения в твоем примере недостаточно информации. Для полноты картины нужно знать:
1. Процент таких случаев от общего числа использования объекта или более полно — статистика использования полей объекта на достаточно протяженном интервале работы системы.
2. Контекст использования объекта(см. мой пример с гридом).
3. Статистика распределения данных по полям объекта. Упрощенно говоря, может выясниться, что в 99% случаев использования объекта нужно поле, вес которого составляет 99% от всех данных в объекте.
Но, даже обладая такой информацией у тебя не будет формализованного механизма принятия решения(хотя его можно значительно упростить). Нахождение удачного решения — задача проектировщика и насколько успешно он с ней справиться зависит от его опыта и таланта.

Я отмечу несколько полезных, с моей точки зрения, моментов/правил при разработке классов BE которые я учитываю:
1. Есть такой эмпирический факт, что в подавляющем большинстве случаев 90% данных находяться в 10% полей класса.
2. На этапе проектирования можно выделять особо жирные поля в отдельные классы. Например, в классах часто встречается поле Description, которое весит в десятки или сотни раз больше чем все остальные поля класса вместе взятые. Скорее всего, этот самый Descrption будет востребован лишь когда его будет редактировать/просматривать пользователь. Создайте отдельный класс для таких desciption-ов и вместо поля string в BE используйте его.
3. По возможности избегать создания классов с большим количеством полей.
4. Если есть плоский класс с большим количеством полей, то имеет смысл его отрефакторить и сделать композитным. Наиболее часто используемые поля оставить в самом классе, а остальные поля разбить на группы и вынести в другие классы.
5. Используйте или напишите средство профилирования, которое позволит оценить как часто и какие группы полей используются для каждой BE. В каком контексте они используются. Эти данные позволяют обоснованно(sic!) принять решение о необходимости рефакторинга кода.
6. Ну и уже заезженное правило, не оптимизировать пока не появиться в этом необходимость.


IT>Так в чём проблема? Если речь идёт о большом проекте, то сопроводи свой метод спецификаций.
Если мы говорим о внешнем API — то это само-собой разумеющийся факт. А вот для кода внутри системы — это ничего не даст, все равно придется анализировать цепочку возможных вызовов. Я правлю какой-нить метод бизнес логики который получает на вход BE. В результате правки в методе используется на одно поле этой BE больше. Следуя твоей логике, я должен просмотреть все цепочки вызовов этого метода от момента создания и инициализации BE. После чего прочитать спецификацию по методам инициализации.

IT>Блин, ну вот опять начинается Как же они не принимают участие во внутренних процессах, если задача внутренных процессов как раз и заключается в том, чтобы создать структуру из таких объектов и вернуть её клиенту. Это и есть работа этих самых внутренных процессов.
IT>Эти изменения прежде всего неразрывно связаны с изменением логики работы сервера.

Требования к таким классам близки к требованиям к внешнему API системы. Изменения API и изменение внутренней логики, бесспорно, могут зависеть друг от друга, но это не является правилом. В данном случае я делаю допущение, что изменения в коде связанные с изменением ответа от API(скажем, еще одно поле в ответ добавили) не относятся к изменению "внутренней логики работы сервера".

IT>И почему же они тогда не разделены?
Где они не разделены?


P.S. Напоследок позволю себе небольшую аналогию, раз уж в топике поднялся вопрос о функциональных и нефункциональных требованиях. Я думаю, многим доводилось крутить в руках деталь какого-нибудь хитрого механизма. Эта деталь может иметь какую-нибудь загогулистую форму, а ее назначение, скажем, хитро передавать вращательный момент. "Хитро передавать вращательный момент" — это функциональные требования к этой детали и ее форма определяется именно им. Если расмотреть деталь поближе, то выясняется что она композитна и состоит из каких-то дополнительных втулок, хомутов и т.д. На первый взгляд, необходимости в этих сложностях нет, можно было отлить все единой загогулиной. Но если присмотреться, то выясняется, что эти самые втулки, хомуты, прокладки находяться в местах повышенного трения или усиленной нагрузки. Сделано это с целью удовлетворения уже нефункциональных требований: износостойкость, ремонтопригодность, надежность. Замечу, что необходимость многих этих втулок выяснилась уже в ходе эксплуатации механизма, т.к. при первичном проектировании все учесть крайне тяжело. В проектировании классов наших BE фактически все тоже самое. Первоначально класс появляется в результате анализа функциональных требований. Это может быть обыкновенный плоский класс из 20 полей. В дальнейшем этот класс может быть разбит на несколько классов, у него появяться дополнительные поля, а некоторые поля будут сгруппированы в новые классы. Все эти изменения произойдут с целью удовлетворения нефункциональных требований и необходимость многих из них выяснится только в ходе эксплуатации системы.

Здравствуйте, MaximVK, Вы писали:

MVK> Мои опасения — результат практического опыта. Основная проблема таких ошибок — они трудно уловимы, т.к. ислючение не вылетит, а поломается бизнес-логика. Т.к. частично проинициализированный объект ничем не отличается от объекта с такими же пустыми полями. Особенно активно такие ошибки вылазят в процессе поддержки приложения. Когда тут надо что-то подкрутить, там подправить, здесь учесть еще одно требование. Когда программист добавляет один маленький if по какому-то полю в одном из бизнес-компонентов, а потом выясняется, что это поле в 1% случаев бывает непроинициализированным. Твой аргумент "минусы мизерны по сравнению с плюсами" — ну никак не отвечает на вопрос, т.к. неизмерим. А на практике выясняется, что "плюсы" — это быстрое снятие 1% нагрузки на сервер,

1% нагрузки, даже 5% лично меня вообще не волнуют. Если бороться, то за минимум за 20. Плюсы — это maintenance. Если у меня одно представление данных, то мне нужно сопровождать ровно одно, если у меня их пять, то работы будет в пять раз больше.

MVK>а "мизерные минусы" — это несколько баг репортов, затертые поля в базе, 3 дня работы саппорта и пара ушедших клиентов.

Давай я тебе другую страшилку расскажу. Предположим у тебя не одно представление данных, а несколько. В процессе разработки поменялся тип, имя поля, размерность, правило валидации или что-то ещё. Изменение должен сделать программист, которые не очень осведомлён о всех представлениях одной и той же сущности. А теперь страшилка:

Мои опасения — результат практического опыта. Основная проблема таких ошибок — они трудно уловимы, т.к. ислючение не вылетит, а поломается бизнес-логика. Т.к. частично проинициализированный объект ничем не отличается от объекта с такими же пустыми полями. Особенно активно такие ошибки вылазят в процессе поддержки приложения. Когда тут надо что-то подкрутить, там подправить, здесь учесть еще одно требование. Когда программист добавляет один маленький if по какому-то полю в одном из бизнес-компонентов, а потом выясняется, что это поле в 1% случаев бывает непроинициализированным.

Твои слова один в один применимы к данной ситуации.

Забытый класс гораздо труднее найти, особенно, если он писался не тобой. В этом случае ты фактически вообще без понятия есть ли ещё какие-либо представления тех же самых данных в программе. На сегодняшний день мы имеем два места в коде, где у нас полностью отсутствует типизация и можно полагаться только на себя — это DAL и баиндинг типов на формы. Первое возможно в скором времени можно будет решить с помощью метапрограммирования, со вторым пока сложнее. Так вот, увеличивая количество типов в программе, связанных с этими вещами ты пропорционально увеличиваешь проблемы при сопровождении.

Твои сопровождения тоже справедливы, но они не так страшны. Попробуй добавить ещё одно поле в любой из своих типов и ты увидишь, что не изменилось ровным счётом ничего. Вообще ничего. А теперь попробуй переименовать одно поле в базе данных и сравни количество работы, необходимой для корректировки этого изменения по всему коду для одного типа данных и, например, для пяти.

MVK>Резюмируя:

MVK>1. Ошибки которые влечет такой подход трудно обнаружимы и не покрываются юнит-тестами.

Обнаруживаются элементарно даже если тестируются сценарии.

MVK>2. Снижается универсальность бизнес-компонент в системе. Т.к. если при условии выполнения правила "все поля проинициализированы" предусловие контракта компонента выглядит как "дайте мне на вход экземпляр класса MyBE", то в случае отказа от этого правила выглядит как "дайте мне на вход экземпляр класса MyBE с проинициализированными полями p1,...pn". Думаю, не нужно пояснять, что контролировать выполнение такого контракта значительно труднее.

Это выглядит как дайте мне данные и никак иначе. Добавление нового и изменение старого функционала должно вообще-то хотя бы как-нибудь тестироваться. Проблемы, о которых ты говоришь вылезут моментально. Но скорее всего ничего не случится, т.к. добавление нового поля в сущность не ломает старого кода.

MVK>3. Снижается устойчивость кода к модификации, т.к. изменения совершаемые на уровне оперирования объектами должны учитывать более низкоуровневые сущности (поля объектов).

Этого утверждения не понял.

MVK>4. Попустительствование ошибкам в дизайне, связанным с удовлетворением такого нефункционального требования к системе, как производительность.

При чём тут производительность тоже не понял.

MVK>5. Усложняется паралельная разработка кода, т.к. увеличивается количество неявных условий, которые должны быть учтены программистом.
MVK>6. Усложняется процесс введения в проект новых людей, тоже по причине названной в пункте пять.

Это всё ерунда, по сравнению с введением новых типов на каждый чих.

IT>>Тогда вернёмся на несколько постов назад. По-твоему, если у тебя есть объект из 30 полей, но тебе нужно только 5, то ты создаш новый объект. Если же тебе понадобились 6 полей, то ещё один объект, если 6, но других, то по объекту на каждую комбинацию, если 7, то все возможные комбинации и так далее. Я тебя правильно понимаю?

MVK>Нет, не правильно. Это крайность, которая, как и любая другая, популярна, потому что избавляет от необходимости думать, утверждая: делай всегда так и будет тебе счастье.

Т.е. в некоторых случаях ты всё же добавишь поле вместо создания нового типа

MVK>Для принятия правильного решения в твоем примере недостаточно информации. Для полноты картины нужно знать:
MVK>1. Процент таких случаев от общего числа использования объекта или более полно — статистика использования полей объекта на достаточно протяженном интервале работы системы.

Случаи всегда возникают по одному. Второй всегда возникает после первого, третий после второго. Сколько их будет никому заранее не известно. А если бы было известно, то это надо бы было заранее учитывать в дизайне.

MVK>2. Контекст использования объекта(см. мой пример с гридом).
MVK>3. Статистика распределения данных по полям объекта. Упрощенно говоря, может выясниться, что в 99% случаев использования объекта нужно поле, вес которого составляет 99% от всех данных в объекте.
MVK>Но, даже обладая такой информацией у тебя не будет формализованного механизма принятия решения(хотя его можно значительно упростить). Нахождение удачного решения — задача проектировщика и насколько успешно он с ней справиться зависит от его опыта и таланта.

Проектировщик не всегда обладает всей информацией. Точнее почти всегда ей не обладает. Дизайн системы не только должен удовлетворять текущим функциональным требованиям, но и быть готовым к добавлению новых и изменению существующих. Обилие типов в системе вовсе не способствует этому требованию.

MVK>Я отмечу несколько полезных, с моей точки зрения, моментов/правил при разработке классов BE которые я учитываю:
MVK>1. Есть такой эмпирический факт, что в подавляющем большинстве случаев 90% данных находяться в 10% полей класса.
MVK>2. На этапе проектирования можно выделять особо жирные поля в отдельные классы. Например, в классах часто встречается поле Description, которое весит в десятки или сотни раз больше чем все остальные поля класса вместе взятые. Скорее всего, этот самый Descrption будет востребован лишь когда его будет редактировать/просматривать пользователь. Создайте отдельный класс для таких desciption-ов и вместо поля string в BE используйте его.
MVK>3. По возможности избегать создания классов с большим количеством полей.
MVK>4. Если есть плоский класс с большим количеством полей, то имеет смысл его отрефакторить и сделать композитным. Наиболее часто используемые поля оставить в самом классе, а остальные поля разбить на группы и вынести в другие классы.
MVK>5. Используйте или напишите средство профилирования, которое позволит оценить как часто и какие группы полей используются для каждой BE. В каком контексте они используются. Эти данные позволяют обоснованно(sic!) принять решение о необходимости рефакторинга кода.
MVK>6. Ну и уже заезженное правило, не оптимизировать пока не появиться в этом необходимость.

Всё это лишь способстует увеличению количества типов в системе, что само по себе есть зло. Да и не понимаю я, зачем мне разбивать сущность на три типа, если они никогда не используются раздельно. Глупости это всё. Хотя если вам платят за строчки кода, то why бы и not.

IT>>Так в чём проблема? Если речь идёт о большом проекте, то сопроводи свой метод спецификаций.
MVK>Если мы говорим о внешнем API — то это само-собой разумеющийся факт. А вот для кода внутри системы — это ничего не даст, все равно придется анализировать цепочку возможных вызовов. Я правлю какой-нить метод бизнес логики который получает на вход BE. В результате правки в методе используется на одно поле этой BE больше. Следуя твоей логике, я должен просмотреть все цепочки вызовов этого метода от момента создания и инициализации BE. После чего прочитать спецификацию по методам инициализации.

Ну откуда я знаю? Приводи код будем разбираться что с ним делать.

IT>>Блин, ну вот опять начинается Как же они не принимают участие во внутренних процессах, если задача внутренных процессов как раз и заключается в том, чтобы создать структуру из таких объектов и вернуть её клиенту. Это и есть работа этих самых внутренных процессов.
IT>>Эти изменения прежде всего неразрывно связаны с изменением логики работы сервера.

MVK>Требования к таким классам близки к требованиям к внешнему API системы. Изменения API и изменение внутренней логики, бесспорно, могут зависеть друг от друга, но это не является правилом. В данном случае я делаю допущение, что изменения в коде связанные с изменением ответа от API(скажем, еще одно поле в ответ добавили) не относятся к изменению "внутренней логики работы сервера".

И в чём проблема?

IT>>И почему же они тогда не разделены?
MVK>Где они не разделены?

Да, где?

MVK>В проектировании классов наших BE фактически все тоже самое. Первоначально класс появляется в результате анализа функциональных требований. Это может быть обыкновенный плоский класс из 20 полей. В дальнейшем этот класс может быть разбит на несколько классов, у него появяться дополнительные поля, а некоторые поля будут сгруппированы в новые классы. Все эти изменения произойдут с целью удовлетворения нефункциональных требований и необходимость многих из них выяснится только в ходе эксплуатации системы.

Такая необходимость возникает крайне редко и связана она в основном, простите за каламбур, со связями внутри объекта, которые пораждаются обилием и разнообразием типов в приложении. Меньше типов — меньше связности. Добавление одного поля — это детский сад по сравнению с добавлением новго типа.

ЗЫ. Впрочем, мы уже отвлеклись от заданной темы. DTO к этому отношения не имеет. Добавление поля vs. добавление типа это уже совсем другая история. И если я категорически против DTO, то добавление нового типа, в случае необходимости, не считаю жутким преступлением.

Здравствуйте, GlebZ, Вы писали:

GZ>Нет. И к тому же это чаще просто невозможно сделать. Зависимости всегда остаются. Вызовы только с одной стороны можно сделать. Но изменение кода на одном слое могут выливаться изменения на соседних слоях.

Зависимости остаются, но они должны быть односторонними. Ты же выше сказал "зависят друг от друга", что подразумевает двухстороннюю зависимость и не есть хорошо.

Здравствуйте, IT, Вы писали:

Видимо происходит некоторое непонимание. Есть единственный случай, когда я считаю разумным дублирование полей в новых сущностях — это опять же мой пример с гридом. Т.е. классов, которые, фактически, эквиваленты view в базе данных. Я против создания классов вида MyClassView1, MyClassView2 и т.д. которые будут описывать разные наборы полей одного и того же класса MyClass — т.к. это действительно увеличивает сложность. Я утверждаю, что при грамотном подходе частичной загрузки объекта можно избежать через разбиение (а не создание различных представлений) класса на несколько и использовании композита. Т.е. был MyClass с 30 полями, а стал скажем класс MyClass c 12 полями из которых два MyClassPart1 и MyClassPart2 содержат остальные поля. Более того, частичная загрузка до того простой механизм, что им пользуются даже не особо задумываясь — даст ли это хоть какое-то преимущество.

IT>Давай я тебе другую страшилку расскажу. Предположим у тебя не одно представление данных, а несколько. В процессе разработки поменялся тип, имя поля, размерность, правило валидации или что-то ещё. Изменение должен сделать программист, которые не очень осведомлён о всех представлениях одной и той же сущности. А теперь страшилка:

Как я говорил выше, я против нескольких представлений одной и той же сущности. Исключение составляет опять же случай с гридом. В случае создания такого класса на него налагаются достаточно строгие ограничения, в частности для него нет стандартного набора CRUD операций в DAL, его можно только прочитать.

IT>Твои сопровождения тоже справедливы, но они не так страшны. Попробуй добавить ещё одно поле в любой из своих типов и ты увидишь, что не изменилось ровным счётом ничего. Вообще ничего. А теперь попробуй переименовать одно поле в базе данных и сравни количество работы, необходимой для корректировки этого изменения по всему коду для одного типа данных и, например, для пяти.
Опять же в свете сказанного выше такая проблема не возникнет.

IT>Обнаруживаются элементарно даже если тестируются сценарии.
IT>Это выглядит как дайте мне данные и никак иначе. Добавление нового и изменение старого функционала должно вообще-то хотя бы как-нибудь тестироваться. Проблемы, о которых ты говоришь вылезут моментально. Но скорее всего ничего не случится, т.к. добавление нового поля в сущность не ломает старого кода.

Определенно, такой код сложнее поддается тестированию.

MVK>>3. Снижается устойчивость кода к модификации, т.к. изменения совершаемые на уровне оперирования объектами должны учитывать более низкоуровневые сущности (поля объектов).
IT>Этого утверждения не понял.
Следуя правилу "все поля объекта должны быть загружены" я могу оперировать объектами, забыв о полях. А ты фактически оперируешь группами полей, хотя передаешь везде объекты.

IT>При чём тут производительность тоже не понял.
Частичная загрузка объектов призвана снизить нагрузку на сервер с целью увеличения производительности. Необходимость частичной загрузки может быть вызвана кривизной дизайна класса (ну скажем, в классе Order поля отвечающие за доставку заказа не выделены в отдельный класс), но вместо того чтобы правильно перепроектировать класс мы заткнем проблему частичной загрузкой.

IT>Т.е. в некоторых случаях ты всё же добавишь поле вместо создания нового типа
Разумеется.

IT>Случаи всегда возникают по одному. Второй всегда возникает после первого, третий после второго. Сколько их будет никому заранее не известно. А если бы было известно, то это надо бы было заранее учитывать в дизайне.
Это верно и для частичной загрузки класса за исключением дизайна.

IT>Проектировщик не всегда обладает всей информацией. Точнее почти всегда ей не обладает. Дизайн системы не только должен удовлетворять текущим функциональным требованиям, но и быть готовым к добавлению новых и изменению существующих. Обилие типов в системе вовсе не способствует этому требованию.

На самом деле количество типов в системе не так сильно увеличивается. Ну было 100, стало 120-130. Наиболее жирные классы представлены как композиты. Для наиболее жирных полей(аля Description) определены свои типы и унифицированы механизмы работы с такими типами. При этом выделения нескольких полей класса ClassA в новый класс ClassB приводит лишь к появлению связи класса ClassB с классом ClassA.

IT>Всё это лишь способстует увеличению количества типов в системе, что само по себе есть зло. Да и не понимаю я, зачем мне разбивать сущность на три типа, если они никогда не используются раздельно. Глупости это всё. Хотя если вам платят за строчки кода, то why бы и not.
Если никогда не используется раздельно — то и не надо

IT>Такая необходимость возникает крайне редко и связана она в основном, простите за каламбур, со связями внутри объекта, которые пораждаются обилием и разнообразием типов в приложении. Меньше типов — меньше связности. Добавление одного поля — это детский сад по сравнению с добавлением новго типа.
Я не согласен с "меньше типов лучше". Мы же разносим по каким-то загадочным причинам тип Address и тип Order, создавая в Order-e поле ShippingAddress типа Address. Появление нового типа должно быть обоснованным. Я считаю, что первичное выделение типов основывается на анализе функциональных требований к системе и предметной области, а затем еще раз, но уже основанное на анализе нефункциональных требований.


IT>ЗЫ. Впрочем, мы уже отвлеклись от заданной темы. DTO к этому отношения не имеет. Добавление поля vs. добавление типа это уже совсем другая история. И если я категорически против DTO, то добавление нового типа, в случае необходимости, не считаю жутким преступлением.

Да, согласен. Тем не менее беседа получилась для меня познавательная

Здравствуйте, Blazkowicz, Вы писали:

B>Зависимости остаются, но они должны быть односторонними. Ты же выше сказал "зависят друг от друга", что подразумевает двухстороннюю зависимость и не есть хорошо.
Хоть не всегда получается как хотелось бы, но в принципе ты прав.

Здравствуйте, IT, Вы писали:

IT>Датасеты передаются через веб-сервис как xml-структура, которая не опысана в WSDL. Это делает их неприменимыми из других платформ кроме .NET.

Почему? Можно же парсить вручную. Впрочем, это не та тема.

IT>Что значит дыры?

Ну, я так понял, что ты утверждаешь

Автор: IT
Дата: 09.01.07

, что ДТО обычно используется для затыкания дыр в архитектуре. Вот, я её не вижу. Потому интересуюсь, куда глядеть, чтобы увидеть то же, что и ты.

IT> Речь идёт о том, что дизайн и имплеинтация сервиса для януса мог бы быть значительно лучше, если бы это учитывалось изначально при разработке сайта. Но в 2000 году об офлай клиенте речи вообще не было.

Это понятно.

IT>Менее связными понятие очень относительное. Например, в несколько таблиц на сервере было добавлены поля timestamp исключительно для поддержки януса. Была добавлена таблица, которая отслеживала изменения/удаления топиков. Без этого нормальная синхронизация януса невозможна. При этом работа с этой таблицой делается в местах, не имеющих к янусу прямого отношения.

Ты мне расказываешь про развитие, как принято говорить, "движка форума". Само собой появившияся Янус потребовал учитывать свой собственный минимальный набор, при котором ещё возможно его функционирование. Но ведь Янус не мог появится без этого минимума в принципе. А в пределах контракта сервер и клиент (Янус) могли развиваться неортогонально друг другу.

Ну и кроме того, разве система отслеживания изменений в сообщениях не нужна для вебинтерфейса и, в частности, для модерирования/администрирования? Ведь без надлежащего учёта будет бардак.

IT> И как это расценивать, как большую связность или как маленькую?

Есть система со своим движком форумов. Она предоставляет вебслужбу (контракт) для удалёного взимодействия с собой. Есть Янус, который этот контракт использует. Развитие обоих взаимодействующих по контракту частей может идти и без учёта друг дружки, но при условии соблюдения контракта.

Связность имеет место быть. Сильная она или слабая? А вот шут его. Я ещё путаюсь в терминологии. Хотел с твоей помощью разобраться.

Если при изменениях (сервера, Януса) не затрагивается контракт, то зависимость слабая. Если же изменения требуют больших затрат на приведение кода в соответсвие контрату, то зависимость сильная.

У меня логическое (или терминологическое) противоречие. Помоги разрешить.

Здравствуйте, akasoft, Вы писали:

IT>>Датасеты передаются через веб-сервис как xml-структура, которая не опысана в WSDL. Это делает их неприменимыми из других платформ кроме .NET.
A>Почему? Можно же парсить вручную. Впрочем, это не та тема.

Как минимум это косяк.

IT>>Что значит дыры?

A>Ну, я так понял, что ты утверждаешь

Автор: IT
Дата: 09.01.07

, что ДТО обычно используется для затыкания дыр в архитектуре. Вот, я её не вижу. Потому интересуюсь, куда глядеть, чтобы увидеть то же, что и ты.

В этом смысле? Насколько мне известно, в янусе используются нетипизированные датасеты, что уже само по себе дырка в дизайне. На сервере сервис не следует простейшим правилам разбиения на слои, маппинг делается в ручную. На клиенте маппинг тоже делается в ручную. Но всё это, ещё раз повторяю, ни в коем случае не умоляет заслуг разработчиков. Просто это всё писалось давным давно. А сегодня вполне можно было бы задизайнить всё так, что бы и на сервере и на клиенте код методов сервиса и сохранение этого дела на клиенте занимало бы по паре строк.

A>Ты мне расказываешь про развитие, как принято говорить, "движка форума". Само собой появившияся Янус потребовал учитывать свой собственный минимальный набор, при котором ещё возможно его функционирование. Но ведь Янус не мог появится без этого минимума в принципе. А в пределах контракта сервер и клиент (Янус) могли развиваться неортогонально друг другу.

Против это никто не возражает, пусть себе развиваются. Только вот без изменения сервера работа януса была бы не возможна в принципе. Т.е. любая независимость весьма условная вещь. А раз так, то нет никакого смысла бороться за эту независимость изо всех сил. Если что-то проще и эффективнее сделать для януса на сервере, то это надо делать на сервере. Об этом я и говорю.

A>Ну и кроме того, разве система отслеживания изменений в сообщениях не нужна для вебинтерфейса и, в частности, для модерирования/администрирования? Ведь без надлежащего учёта будет бардак.

В существующей архитектуре не нужна. Зато для веба нужен пейджинг почти для всех методов. Для януса не нужен, а для веба нужен. Это опять к слову о независимости клиентов от сервера.

IT>> И как это расценивать, как большую связность или как маленькую?

A>Есть система со своим движком форумов. Она предоставляет вебслужбу (контракт) для удалёного взимодействия с собой. Есть Янус, который этот контракт использует. Развитие обоих взаимодействующих по контракту частей может идти и без учёта друг дружки, но при условии соблюдения контракта.

У нас не стоит задачи предоставить вебслужбу (контракт) для удалённого взаимодействия с собой. У нас стоит задача обеспечить соответствующими сервисами янус, веб и NNTP клиентов. Контракт — это очень здорово, это позволяет максимально изолировать различные части системы друг от друга. Мне это всё очень нравится как правильный паттерн и хороший инструмент для достижения обеспечения более простого сопровождения. Но при всём при этом это всего лишь инструмент и относится к нему нужно соответственно.

A>Связность имеет место быть. Сильная она или слабая? А вот шут его. Я ещё путаюсь в терминологии. Хотел с твоей помощью разобраться.

A>Если при изменениях (сервера, Януса) не затрагивается контракт, то зависимость слабая. Если же изменения требуют больших затрат на приведение кода в соответсвие контрату, то зависимость сильная.

A>У меня логическое (или терминологическое) противоречие. Помоги разрешить.

Я думаю, что у тебя наблюдается некоторая путаница с системой твоих приоритетов. Это потребует некоторого объяснения. Я уже много раз об этом безуспешно говорил, например, здесь

Автор: IT
Дата: 10.11.05

, здесь

Автор: IT
Дата: 21.08.06

, здесь

Автор: IT
Дата: 07.05.05

. Но можно попробовать ещё раз

Итак, проблема в том, что нам постоянно, решая те или иные задачи, приходится выбирать между двумя или более решениями. Чаще всего этот выбор тривиален, иногда довольно труден, а порой вообще невозможно спрогнозировать к чему приведёт то или иное решение. Всё это усугубляется ещё и тем, что одно и тоже решение в разных ситуациях может оказаться как плохим так и хорошим. Однажды мне всё это надоело и я разработал для себя набор простых правил, которые в 99% случаев позволяют быстро принять более менее адекватное решение. А так же уже после принятия какого-либо решения при изменении определённых условий с чистой совестью "поступиться принципами", отменить ранее принятое решение и принять другое.

Базируется это хозяйство на очень простой системе приоритетов и разрешения противоречий. Список приоритетов у меня такой:

1. Функциональные требования.
2. Нефункциональные требования.
3. Сопровождаемость системы.

Это наши цели. Всё остальное должно быть подчинено достижению этих целей. Заметь, у меня нет в этом списке паттернов, контрактов, строгости объектной модели и прочего. Нет, потому что это не является целью, это всего лишь инструменты достижения наших целей. А инструментов, чем их больше и они разнообразнее, тем всегда лучше. Но они никогда не должны становится выше целей. Это очень важное правило и очень важно его понимать.

Противоречия разрешаются очень просто. Если решение не противоречит первому пункту, то проверяется непротиворечивасть со вторым. Если решение не противоречит второму, то должно строго следовать третьему. Неудовлетворение первого пункта может быть обусловлено только соображениями нецелесообразности. В этом случае вообще ничего не делается.

Что это значит? Это значит, что наша главная задача — это реализация функционала. Не создание объектной модели, не определение контракта, не использование паттернов, а реализация функционала. Если у нас есть какой-то контракт и для добавления нового функционала его нужно изменить или переделать, то его нужно изменить или переделать. Вообще, неследование этому правилу очень часто наблюдается у молодёжи. Зачастую паттерны, polymorphic behaviour, контракты, структура базы данных или объектной модели и т.п. ставятся выше главных целей, выше разработки функциональности системы. В результате функционал начинает подгоняться под контракты и модели, что в свою очередь ведёт к краху. Типичная подмена целей и приоритетов.

Наша вторая задача — обеспечение приемлемой работоспособности системы. Т.е., если для реализации нового функционала наш контракт можно не менять и не переделывать, но система будет работать существенно медленнее, то контракт нужно изменить или переделать. Справедливо и обратное. Если добавление фичи на скорость не влияет, то не надо заниматься ненужной оптимизацией. Это практически в ста процентах случаев повредит следующему пункту.

Наша треться задача — обеспечение сопровождаемости и готовности системы к изменениям в будущем. Так, если ни функциональные, ни нефункциональные требования не требуют переделки контракта, но его изменение позволит повысить сопровождаемость, то контракт нужно изменить или переделать. Вообще, вынесение сопровождаемости в категорию целей позволяет освободиться от многих догм, начать смотреть на мир проше и перестать обожествлять отвёртки и молотки, ака паттерны и модели. С этой точки зрения DTO (вернёмся не на долго к теме топика) не имеют абсолютно никакого смысла. Они только порождают новые типы, не решая при этом абсолютно никаких проблем, а значит не имеют права на жизнь.

Так же стоит понимать, что иногда наши изменения могут стоить слишком дорого, в этом случае стоит задуматься о их целесообразности вообще.

Возникает вопрос, а бывают ли исключения? Нет, исключений не бывает. Бывает переход задач в категорию функциональных / нефункциональных требований. Например, в некоторых системах публичный контракт является тем, для чего собственно сама система и делается. Тогда контракт со всеми вытекающими последствиями переводится в разряд функциональных требований и ему начинает подчиняться всё остальное. Бывает, когда чистота и непротиворечивость объектной модели становятся так же функциональным требованием. Возьмём к примеру .NET Framework или любые другие публичные библиотеки. В таких случаях, к объектным моделям и интрефейсам предъявляются особые требованмя. Например, для обеспечения согласованности объектной модели в .NET в своё время в MS была организована целая группа, главной задачей которой была разработка рекомендаций и обеспечение надзора за соблюдением требованмй к публичным интерфейсам.

Очевидно, что в твоём случае ты не можешь определиться с тем, как ты позиционируешь для себя веб-сервис януса. Является ли он для тебя чем-то вроде функциональных требований или нет. Лично для меня он таковым не является. Для меня это всего лишь инструмент для достижения необходимой функциональности. А раз так, то я не вижу большого смысла с ним церемониться. Я за то, чтобы контракт был, чтобы он был продуман и удобен в использовании, но это для меня не главный приоритет, это лишь следствие из моих правил, и до тех пор пока оно не противоречит самим правилам, я буду ему следовать, но принесу его в жертву более приоритетным вещам не задумываясь. Если же ты, например, решишь для себя, что веб-сервим януса должен быть вынесен на уровень функциональных требований, то нам с тобой договариваться о деталях уже не будет иметь никакого смысла. Бесполезно спорить о мелочах, не договорившись о главных приоритетах. Если же ты решишь наоборот, то очень скоро увидишь, что гораздо важнее не сам по себе контракт, а простота сопровождения интерфеса между сервером и янусом.

Вот такой набор правил. Пожалуй главное, что он мне даёт — это возможность быстро принимать решения и также быстро от них отказываться и принимать другие, наиболее подходящие, если меняются требования или появляется дополнительная информация. Это не значит, что я вот такой непостоянный. Это значит, что у меня нет идолов в коробке с инструментами, моя главная и единственная задача — написать требуемый функционал, который бы хорошо работал и который было бы легко сопровождать. И этому всё подчинено.

Здравствуйте, IT, Вы писали:

IT>Всё это лишь способстует увеличению количества типов в системе, что само по себе есть зло. Да и не понимаю я, зачем мне разбивать сущность на три типа, если они никогда не используются раздельно. Глупости это всё. Хотя если вам платят за строчки кода, то why бы и not.

Читаю я тут все это, читаю... По-моему, тут просто терминологическая путаница. Сам же писал

Автор: IT
Дата: 06.09.06

, еще недавно:

Бизнес сущности, они же Domain Entities, они же Data Transfer Objects (DTO).

Видимо конечно правильно определять DTO как сущности, введенные только для того, чтобы передавать данные. Но вот я лично до того как прочел эту дискуссию считал BE и DTO синонимами По-моему отсюда и происходит путаница, ты говоришь про одно, а твои собеседники про другое.

Здравствуйте, Gollum, Вы писали:

G>Читаю я тут все это, читаю... По-моему, тут просто терминологическая путаница.

100%. При чём, заметь, я постоянно пытаюсь уточнить что я под этим понимаю.

Сам же писал

Автор: IT
Дата: 06.09.06

, еще недавно:

G>

Бизнес сущности, они же Domain Entities, они же Data Transfer Objects (DTO).

Когда я это писал ещё не все дочитали до конца Фаулера.

G>Видимо конечно правильно определять DTO как сущности, введенные только для того, чтобы передавать данные. Но вот я лично до того как прочел эту дискуссию считал BE и DTO синонимами По-моему отсюда и происходит путаница, ты говоришь про одно, а твои собеседники про другое.

Посмотри на название топика. Как ты думаешь, что оно означает? Из-за этого я и завёлся. А потом уже началась неразбериха с терминологией.

Здравствуйте, IT, Вы писали:

IT>Сам же писал

Автор: IT
Дата: 06.09.06

, еще недавно:

G>>

Бизнес сущности, они же Domain Entities, они же Data Transfer Objects (DTO).

IT>Когда я это писал ещё не все дочитали до конца Фаулера.

Сейчас-то дочитал до конца?

Здравствуйте, Mika Soukhov, Вы писали:

IT>>Когда я это писал ещё не все дочитали до конца Фаулера.

MS>Сейчас-то дочитал до конца?

Типа подколол, молодец, смешно.

Фаулер, конечно, грамотный мужик, но его всегда выдавало его джавовское прошлое. Лучше читать майкрософтовские практики, особенно ранние. Они и появились раньше и чуши типа DTO в них поначалу не было.

Здравствуйте, IT, Вы писали:

IT>Фаулер, конечно, грамотный мужик, но его всегда выдавало его джавовское прошлое.

На архитектуру это не особо влияет. Мне больше мелкие моменты у него не нравились, да и все, что связано с Remote Interfaces.

IT>Лучше читать майкрософтовские практики, особенно ранние. Они и появились раньше и чуши типа DTO в них поначалу не было.

Тут тоже не все так гладко. В начале практики напирали на ООП подход, затем на сервисный. + для меня была в свое время путаница с оракловой терминологией (у них есть свой СОА).

Фаулер все же более понятливый автор. Не боится засучить рукава, и полезть разгребать. Плюс обилие примеров помогает легче понять, нежели тот же практик от МС, где демо идет в конце, а не поэтапно.

Здравствуйте, Mika Soukhov, Вы писали:

IT>>Фаулер, конечно, грамотный мужик, но его всегда выдавало его джавовское прошлое.

MS>На архитектуру это не особо влияет.

На архитектуру влияет всё и уж тем более платформа. Другое дело, что у .NET и джавы много общего, больше, например, чем у .NET и COM. Но разница есть и уши местами торчат.

MS>Фаулер все же более понятливый автор. Не боится засучить рукава, и полезть разгребать. Плюс обилие примеров помогает легче понять, нежели тот же практик от МС, где демо идет в конце, а не поэтапно.

Мне у него больше всего нравятся определения. То же определение архитектуры — кратко, ёмко и удивительно точно.

Здравствуйте, IT, Вы писали:

IT>Насколько мне известно, в янусе используются нетипизированные датасеты, что уже само по себе дырка в дизайне. На сервере сервис не следует простейшим правилам разбиения на слои, маппинг делается в ручную. На клиенте маппинг тоже делается в ручную. Но всё это, ещё раз повторяю, ни в коем случае не умоляет заслуг разработчиков. Просто это всё писалось давным давно. А сегодня вполне можно было бы задизайнить всё так, что бы и на сервере и на клиенте код методов сервиса и сохранение этого дела на клиенте занимало бы по паре строк.

Понятно, что со временем появляются новые знания, и всё старое можно сделать по-другому. Но это уже вопрос приоритетов, что переделывать, когда, а что пока оставить, и быть может надолго.

А новый сервис был сделан уже с учётом этого? Хотя, ты уже писал, что с ним не разбирался...

IT>Зато для веба нужен пейджинг почти для всех методов. Для януса не нужен, а для веба нужен. Это опять к слову о независимости клиентов от сервера.

Пейджинг — разбиение на страницы?


IT>У нас не стоит задачи предоставить вебслужбу (контракт) для удалённого взаимодействия с собой. У нас стоит задача обеспечить соответствующими сервисами янус, веб и NNTP клиентов. Контракт — это очень здорово, это позволяет максимально изолировать различные части системы друг от друга. Мне это всё очень нравится как правильный паттерн и хороший инструмент для достижения обеспечения более простого сопровождения. Но при всём при этом это всего лишь инструмент и относится к нему нужно соответственно.

Насчёт задачи согласен. А разве контракт не является способом её решения? Или так: есть другие способы решения этой задачи?

Поверь, у меня нет иллюзий на счёт использования правильных инструментов, лично я использую те, которыми владею и настолько, насколько владею. Если цель в принципе достижима с их использованием.

IT>Я думаю, что у тебя наблюдается некоторая путаница с системой твоих приоритетов. Это потребует некоторого объяснения. Я уже много раз об этом безуспешно говорил, например, здесь

Автор: IT
Дата: 10.11.05

, здесь

Автор: IT
Дата: 21.08.06

, здесь

Автор: IT
Дата: 07.05.05

. Но можно попробовать ещё раз

Большое спасибо за ссылки и за объяснение.

IT>1. Функциональные требования.
IT>2. Нефункциональные требования.
IT>3. Сопровождаемость системы.

Функциональные — значат, что должен делать или чего не делать разрабатываемый продукт.

Нефункциональные — где он это должен делать или не делать. Выбор платформы (ОС, среда программирования, язык, библиотеки, алгоритмы, ...) для реализации функциональных требования относится к нефункциональным требованиям?

С сопровождением мне как бы всё понятно.

Эти определения подходят или нужно уточнить?


IT>Очевидно, что в твоём случае ты не можешь определиться с тем, как ты позиционируешь для себя веб-сервис януса.

Для меня он жизненно необходим. Т.е. в случае его отключения наступит ломка, и придётся забыть о форумах РСДН. Ну, либо домогаться по нескольким хорошо известным адресам его включения. После тех удобств, что предоставляет мне лично Янус, веб-мордой пользоваться я просто не могу.


Но возвращаясь к вопросу большей и меньшей связанности, не хочешь ли ты мне так длинно сказать (ну, чтобы я сам попробовал сделать вывод), что собствеено пофигу, есть или нет этой связности. Что это для функционала Януса и сервера вовсе не важно и дело сотого порядка. И собственно, обсуждать такие малозначимые вопросы — просто терять время, ну или мозг разминать, если больше нечем занятся.

Т.е. есть какая связанность между Янусом и сервером, нету ли её, это не имеет ни малейшего значения с точки зрения изложенной базы из трёх пунктов выше.

IT> ...моя главная и единственная задача — написать требуемый функционал, который бы хорошо работал и который было бы легко сопровождать. И этому всё подчинено.

Это надо написать большими буковами и поместить на самое видное место.

Здравствуйте, akasoft, Вы писали:

A>Понятно, что со временем появляются новые знания, и всё старое можно сделать по-другому. Но это уже вопрос приоритетов, что переделывать, когда, а что пока оставить, и быть может надолго.

Со временем ещё нарабатываются и появляются соответствующие инструменты, с помощью которых аналогичные задачи решаются значительно легче.

A>Пейджинг — разбиение на страницы?

Да.

A>Насчёт задачи согласен. А разве контракт не является способом её решения?

Является.

A>Или так: есть другие способы решения этой задачи?

Если под контрактом понимать веб-сервис и WSDL, то другие способы, конечно же есть. В том числе более эффективные, но менее кошерные. Например, избыточность XML можно убрать с помощью своего доморощенного формата передачи, допустим по записи на строку с запятой в качестве разделителя. Объём передаваемых данных уменьшиться в несколько раз. Можно применить маппер, который не будет создавать промежуточных структур данных. Т.е. прямо из ридера рекордсета данные будут прямиком уходит в html стрим. Т.е. на сервере не будет тратится лишнее время и память на преобразование данных из формата БД в формат объектной модели. На клиенте html стрим также без лишних ресурсов можно мапить прямо в БД клиента.

У этого решения есть свои недостатки, но есть и свои преимущества. Но как минимум это альтернативный способ.

A>Поверь, у меня нет иллюзий на счёт использования правильных инструментов, лично я использую те, которыми владею и настолько, насколько владею. Если цель в принципе достижима с их использованием.

Это хорошо

A>Эти определения подходят или нужно уточнить?

Сойдёт.

IT>>Очевидно, что в твоём случае ты не можешь определиться с тем, как ты позиционируешь для себя веб-сервис януса.

A>Для меня он жизненно необходим. Т.е. в случае его отключения наступит ломка, и придётся забыть о форумах РСДН. Ну, либо домогаться по нескольким хорошо известным адресам его включения. После тех удобств, что предоставляет мне лично Янус, веб-мордой пользоваться я просто не могу.

Жизненно необходим именно веб-сервис или та функциональность, которую предоставляет янус?

A>Но возвращаясь к вопросу большей и меньшей связанности, не хочешь ли ты мне так длинно сказать (ну, чтобы я сам попробовал сделать вывод), что собствеено пофигу, есть или нет этой связности. Что это для функционала Януса и сервера вовсе не важно и дело сотого порядка. И собственно, обсуждать такие малозначимые вопросы — просто терять время, ну или мозг разминать, если больше нечем занятся.

Нет, я не это хочу сказать. Всё это не пофигу и это дело не сотого порядка. Выбор средств, дизайн и имплементация функционала напрямую влияют на третий пункт — на сопровождаемость. Веб-сервис можно реализовать многими способами, я предпочту тот, который мне даст более лёгкую сопровождаемость и при этом не войдёт в противоречие с функциональными/нефункциональными требованиями. Я хочу сказать, что такие вещи как связность — это инструмент для достижения главных целей, это та разменная монета, которой я готов легко пожертвовать, если я увижу другое, более приемлемое решение. Сама по себе связность не является для меня целью, это лишь средство достижения цели. Цель — сопровождаемоесть. Но при этом надо чётко понимать, что сопровождаемость складывается из правильных средств, грамотного дизайна и приличной имплементации.

Опять, блин, получилось как-то путанно

A>Т.е. есть какая связанность между Янусом и сервером, нету ли её, это не имеет ни малейшего значения с точки зрения изложенной базы из трёх пунктов выше.

Это не является целью. Говорить о связанности можно и нужно только в контексте сопровождаемости.

Здравствуйте, IT, Вы писали:

IT>Речь идёт о том, что дизайн и имплеинтация сервиса для януса мог бы быть значительно лучше, если бы это учитывалось изначально при разработке сайта. Но в 2000 году об офлай клиенте речи вообще не было. Для нас тогда даже форумы имели второстепенное значение, соответственно и появились они лишь бы было.

Что-то я пропустил этот пункт.

А вот интересно, что имело первостепенное значение в 2000 году?

И какое значение, с твоей точки зрения, имеют форумы сейчас?

(Если ответы на эти вопросы не потребуют раскрытия какой-либо тайны.)

Здравствуйте, IT, Вы писали:

IT>Если под контрактом понимать веб-сервис и WSDL, то другие способы, конечно же есть. В том числе более эффективные, но менее кошерные. Например, избыточность XML можно убрать с помощью своего доморощенного формата передачи, допустим по записи на строку с запятой в качестве разделителя. Объём передаваемых данных уменьшиться в несколько раз. Можно применить маппер, который не будет создавать промежуточных структур данных. Т.е. прямо из ридера рекордсета данные будут прямиком уходит в html стрим. Т.е. на сервере не будет тратится лишнее время и память на преобразование данных из формата БД в формат объектной модели. На клиенте html стрим также без лишних ресурсов можно мапить прямо в БД клиента.

Собственно под контрактом я подразумевал нечто в стиле interface, т.е. формулирование и документирование некоторого набора методов, порядка их вызова и форматов данных, которыми будут обмениваться Янус и сервер. Не имея оговоренного набора этого самого interface мне предствляется затруднительным решить задачу взаимодействия.

В то же время, сам контракт можно модифицировать, модернизировать и быть может не требовать совместимости между предыдущими версиями, если это не скажется на сопровождении.

IT>Жизненно необходим именно веб-сервис или та функциональность, которую предоставляет янус?

Конечно же Янус. А что, есть способ поднять Янус "по воздуху"? Читай, не через вебслужбу?

IT>Нет, я не это хочу сказать. Всё это не пофигу и это дело не сотого порядка. Выбор средств, дизайн и имплементация функционала напрямую влияют на третий пункт — на сопровождаемость. Веб-сервис можно реализовать многими способами, я предпочту тот, который мне даст более лёгкую сопровождаемость и при этом не войдёт в противоречие с функциональными/нефункциональными требованиями. Я хочу сказать, что такие вещи как связность — это инструмент для достижения главных целей, это та разменная монета, которой я готов легко пожертвовать, если я увижу другое, более приемлемое решение. Сама по себе связность не является для меня целью, это лишь средство достижения цели. Цель — сопровождаемоесть. Но при этом надо чётко понимать, что сопровождаемость складывается из правильных средств, грамотного дизайна и приличной имплементации.

Получается, что на реализацию вебслужбы Януса большее влияние оказало именно требование сопровождаемости? Т.е. по другому — умения и навыки разработчиков вебслужбы нарабатывались и развивались по мере реализации вебслужбы? Потом пересматривались, переделывались. В то время как с функциональными и нефункциональными требованиями вопросов не возникало.

Здравствуйте, akasoft, Вы писали:

A>А вот интересно, что имело первостепенное значение в 2000 году?

Предполагалось делать упор на контент, а именно:

RSDN создан программистами для программистов. Главная цель создателей сайта заключается в том, чтобы хоть как-то компенсировать нехватку материалов по программированию на русском языке.

A>И какое значение, с твоей точки зрения, имеют форумы сейчас?

С моей точки зрения только общение может сделать из просто сайта комьюнити. Так что форумы тут имеют первостепенное значение.

Здравствуйте, akasoft, Вы писали:

A>Собственно под контрактом я подразумевал нечто в стиле interface, т.е. формулирование и документирование некоторого набора методов, порядка их вызова и форматов данных, которыми будут обмениваться Янус и сервер. Не имея оговоренного набора этого самого interface мне предствляется затруднительным решить задачу взаимодействия.

Я задам другой вопрос. Имеет ли смысл создавать такой интерфейс между сервером и веб-интерфейсом? Они ведь тоже должны как-то взаимодействовать?

A>В то же время, сам контракт можно модифицировать, модернизировать и быть может не требовать совместимости между предыдущими версиями, если это не скажется на сопровождении.

IT>>Жизненно необходим именно веб-сервис или та функциональность, которую предоставляет янус?

A>Конечно же Янус. А что, есть способ поднять Янус "по воздуху"? Читай, не через вебслужбу?

Например, через WCF или банально через HTTP

A>Получается, что на реализацию вебслужбы Януса большее влияние оказало именно требование сопровождаемости? Т.е. по другому — умения и навыки разработчиков вебслужбы нарабатывались и развивались по мере реализации вебслужбы? Потом пересматривались, переделывались. В то время как с функциональными и нефункциональными требованиями вопросов не возникало.

RSDN — это вообще тренировочный полигон для девелоперов, народ тут и технологии изучал и идеи отрабатывал. По-этому, сказать чем руководствовались разработчики веб-службы сказать крайне сложно.

Здравствуйте, IT, Вы писали:

IT>Посмотри на название топика. Как ты думаешь, что оно означает? Из-за этого я и завёлся. А потом уже началась неразбериха с терминологией.

Слона то я и не заметил Согласен, название такого двоякого толкования не допускает.

Здравствуйте, IT, Вы писали:

IT>Я задам другой вопрос. Имеет ли смысл создавать такой интерфейс между сервером и веб-интерфейсом? Они ведь тоже должны как-то взаимодействовать?

Попробую ответить.

На мой взгляд, при работе через вебморду мы фактичекски работаем с трёхзвенкой. Имеется клиентский броузер со скриптовыми языками, имеется IIS с ASP.NET и языками программирования, имеется БД с хранимыми процедурами. За слой бизнеспроцессов отвечает прослойка с IIS, он же осуществляет проверку данных, вводимых пользователем, аудит работы. Долговременным и кратковременным хранилищем данных выступает серверная БД. Интерфейсом для броузера выступает набор URL, передаваемые данные представляют собой XHTML с JavaScript (или C#), принимаемые данные обусловлены протоколом HTTP и тоже поддаются описанию, как то имена полей, ограничения, содержимое.

Попробую оценить эту конструкцию с точки зрения трёх правил. У меня нет опыта эксплуатации IIS под серьёзной нагрузкой, но вот опыт использования виртуального хостинга на базе Апача и php говорит мне, что быстродействие и взаимодействие с базой является узким местом. Поэтому быстродействие (способность обслужить нужное количество клиентов за приемлимое время) я ставлю в функциональные требования. А красивость кода и его количество — в сопровождение.

С моей точки зрения необходимость делать ещё один слой между БД и IIS будет означать потерю быстродействия, хотя возможно, при этом уменьшится количество кода, приходящегося на слой IIS (ASP.NET, C#), что будет означать лучшую сопровождаемость.

Но предположим, что я всё-таки введу ещё один слой между БД и IIS. Что я с этого могу иметь? Могу поднять быстродействие за счёт кеширования в памяти каких либо данных, наиболее часто выбираемых. Могу централизованно управлять аудитом, причём не только от вебморды, но и от других возможных служб, взаимодействующих с этим слоем вместо непосредственной работы с БД. Если я начну кешировать не только на чтение, но и на запись в БД, то могу понизить надёжность системы. Электроэнергия теоретически может пропасть. Могу получить некий framework, с которым будет удобно и приятно работать мне, разработчику. Я могу стянуть весь теоретически общий код для всех предоставляемых служб во вне в один framework, отладить его и забыть. Но ведь это будет просто напоминать некоторую библиотеку функций, которой будет удобно пользоваться как для обслуживания веб-запросов, так и Януса, NNTP и того, что ещё может появиться. Разве это слой? Чем он будет отличаться от кода, написанного и работающего под IIS.

С тем же Янусом будет взаимодействовать опять же вебслужба, работающая под управлением IIS, а значит опять же ASP.NET и C#. Опять будет 4 слоя вместо трёх.

Если IIS и SQL Server умеют продуктивно настраиваться и работать с кешированием и частозапрашиваемыми данными нет особого смысла дублировать их работу. Это будет сопровождаемость по части кода, ведь при этом не понадобиться писать и отлаживать свой framework. И нефункциональные требования по части надёжности.

Ну а теперь ты мне скажи, зачем на самом деле нужен ещё один слой между "сервером и веб-интерфейсом"?

Здравствуйте, akasoft, Вы писали:

A>С моей точки зрения необходимость делать ещё один слой между БД и IIS будет означать потерю быстродействия, хотя возможно, при этом уменьшится количество кода, приходящегося на слой IIS (ASP.NET, C#), что будет означать лучшую сопровождаемость.

Ещё один слой, если он работает в том же процессе, никакой потери быстродействия не даёт вообще. Потери могут возникнуть при взаимдействии между процессами, но на одной машине они ничтожно малы, по сравнению с доступом к базе данных.

A>Я могу стянуть весь теоретически общий код для всех предоставляемых служб во вне в один framework, отладить его и забыть. Но ведь это будет просто напоминать некоторую библиотеку функций, которой будет удобно пользоваться как для обслуживания веб-запросов, так и Януса, NNTP и того, что ещё может появиться. Разве это слой? Чем он будет отличаться от кода, написанного и работающего под IIS.

А что в твоём понимании слой?

A>Ну а теперь ты мне скажи, зачем на самом деле нужен ещё один слой между "сервером и веб-интерфейсом"?

Речь шла не о слое, а о контракте. Например, между янусом и сервером имеется веб-служба с определённым контрактом. Вопрос нужен ли такой контракт между сервером и веб-мордой, точнее между ASP.NET и сервером. Теоретически это может дать определённые преимущества, практически — кучу проблем. Иногда может перевесить одно, иногда другое. Вот я и хотел узнать твоё мнение.

Здравствуйте, IT, Вы писали:

Мои телепатические возможности подвели меня. Вместо того, чтобы прямо тебя спросить, что ты имеешь ввиду, говоря "сервер" в контекстах "между сервером и Янусом" и "между сервером и веб-интерфейсом", я начал фантазировать и смоделировал трёхзвенку. Чтобы не фантазировать дальше, так и спрошу: что такое сервер?

IT>А что в твоём понимании слой?

Со слоями я впервые столкнулся в графике при использовании Corel Draw, оттуда вышло понимание слоя как нечта логически выделенного и изолированного, взаимодействующего с др. слоями с помощью контрактов (интерфейсов), слой можно "выключить" и заменить на другой, реализующий такой же контракт.

Библиотеки же, с которыми мне приходилось иметь дело, обычно предоставляли пользователю свой собственный контракт каждая, хотя могли делать примерно одно и то же.

Гугль сказал, что слой:

Совокупность категорий классов или подсистем одного уровня абстракции.

Так что, скорее всего я путаю и смешиваю понятия.

IT>Речь шла не о слое, а о контракте. Например, между янусом и сервером имеется веб-служба с определённым контрактом. Вопрос нужен ли такой контракт между сервером и веб-мордой, точнее между ASP.NET и сервером. Теоретически это может дать определённые преимущества, практически — кучу проблем. Иногда может перевесить одно, иногда другое. Вот я и хотел узнать твоё мнение.

Я перешёл на слои потому, что плохо понимаю, что ты называешь сервером. Ну, не про ОС Windows 2003 Server же ты говоришь? В озвученной мною трёхзвенной модели и БД (SQL Server), и IIS, и ASP.NET, и вебслужба работают "на сервере", и только Янус работает "на клиенте".

Здравствуйте, IT, Вы писали:


IT>Базируется это хозяйство на очень простой системе приоритетов и разрешения противоречий. Список приоритетов у меня такой:
IT>1. Функциональные требования.
IT>2. Нефункциональные требования.
IT>3. Сопровождаемость системы.

Вот в данном случае я абсолютно не согласен. Во первых "Сопровождаемость системы" — часть нефункциональных/функциональных требований. Во вторых, если ты не выполнил наиболее важные нефункциональные требования, то значит проект провален и клиент убежит от тебя. Ну и в третьих, приоритеты должны расставляться внутри функциональных/нефункциональных требования.
IMHO Возьмем, к примеру, rsdn. Основным нефункциональным требованием к нему должна быть масштабируемость. То есть работоспособность при пиковой нагрузке. Если сервер будет неработоспособен, то всем будет наплевать какие у нас остальные функциональные/нефункциональные требование. Всем будет абсолютно по фигу с каким быстродействием может отвечать сервер, насколько красива архитектура, и как мало на это времени потратили разработчики. Под это бывает (и наверняка случалось на rsdn) нельзя сделать некоторые функциональные требования.
Поэтому приоритеты нужно расставлять по каждому пункту в функциональных и нефункциональных требованиях.

Здравствуйте, GlebZ, Вы писали:

GZ>Вот в данном случае я абсолютно не согласен. Во первых "Сопровождаемость системы" — часть нефункциональных/функциональных требований. Во вторых, если ты не выполнил наиболее важные нефункциональные требования, то значит проект провален и клиент убежит от тебя. Ну и в третьих, приоритеты должны расставляться внутри функциональных/нефункциональных требования.

Т.е. ты хочешь свалить всё в одну кучу, а потом уже в ней расставить приоритеты? В результате у тебя получатся те же 1, 2, 3

GZ>Поэтому приоритеты нужно расставлять по каждому пункту в функциональных и нефункциональных требованиях.

Выше я упомянул, что требования могут переходить из одной категории в другую. Давай скажем так, наша задача разработать софт для поддержки большого портала. Большой — это уже требование, являющееся одной из наших основных задач и к нему следует относиться как к функциональному требованию.

Здравствуйте, IT, Вы писали:

IT>Т.е. ты хочешь свалить всё в одну кучу, а потом уже в ней расставить приоритеты? В результате у тебя получатся те же 1, 2, 3
Нет. Приоритеты расставляются отдельно для функциональных требований, и отдельно для нефункциональных. И делятся на три группы по степени важности.

IT>Выше я упомянул, что требования могут переходить из одной категории в другую.
Нет. Не могут. Функциональные требования — это достаточно строгая конструкция которая определяет сценарии/действия пользователя. Они могут зависить друг от друга (например требования по администрированию), но они совершенно разные по форме и содержанию.
IT>Давай скажем так, наша задача разработать софт для поддержки большого портала. Большой — это уже требование, являющееся одной из наших основных задач и к нему следует относиться как к функциональному требованию.
Игорь. Откуда такое требование ты взял? Это нормально для пользователя, но для разработчика это ничего не значит. Что такое большой портал? Относительно кого? В чем измеряется? В количестве форм, в количестве строк, или просто формы показываемые порталом должны быть большими? Все равно что, делайте что хотите, но решение должно быть большим и красивым.