Здравствуйте, IT, Вы писали:
IT>Я думаю, что не всё так просто. Иначе бы ты привёл такой код сразу. Не так ли?
Да нет. Там все просто. Просто я выполняю некоторый принцип что объекты друг к дружке не клеются по ссылкам, а обращаются по идентификаторам. В контекте запроса хранится Hashtable в которой лежат пары идентификатор-объект. Сначала проверяется Hashtable, если не нашли — то уже запрос. И я на уровне бизнес-логики не обращаю внимание — загружается этот объект или уже был загружен. А уже при нагрузочном тестировании при большом кол-ве данных можно выверять что, где и как лучше.
IT>Гибкость хороша когда она востребована. В моём примере она просто не нужна. А раз так, то учитывая, что плата за гибкость есть усложнение системы, то твоё решение не обладая никакими преимуществами является более сложным и трудно сопровождаемым.
А обычно именно такая гибкость и востребована. Ввели для собаки шкуру. Сами BE собаки я могу не трогать. И вполне могу не тестировать, поскольку при реализации шкурного вопроса — это саму собаку как таковую мы не затрагиваем. Я дополняю функциональность сервера по мере развития — но не переопределяю.
Здравствуйте, GlebZ, Вы писали:
IT>>Да... ещё забыл насчёт связности. Какой из примеров теперь выглядит более связным? GZ>Что значит выглядит? Твой пример более связный. Допустим, оказалось что агрегирующий запрос по количеству писем отправленных пользователем подсаживает базу данных. И неплохо было бы реализовать агрегат тригерами на новое поле в пользователе. Как бы чистая проблема сервера. Но в твоем случае — оно затронет клиента.
А в твоём можно подумать не затронет. Ещё как затронет, но только лишь с той разницей, что мне нужно будет добавить поле, а тебе целый класс. Короче, сколько можно толочь одну и ту же воду в ступе. Надоело уже.
GZ>К тому же не забывай. Если DTO объект полностью равнозначен BE то можно воспользоваться BE для сериализации. Если он перестал нас удовлетворять как DTO, то мы вполне можем ввести свой custom объект.
Блин, мне уже надоело сегодня задавать этот вопрос. Но всё же... И в чём проблема?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Как правило, такая модель содержит минимум необходимых сущностей, которые покрывают 90% функциональности приложения. Остальные 10% — это где-то местами неиспользуемые поля.
Я всё-таки ещё раз уточню, на основе того же примера про пользователя. По-твоему, является нормальным, если в одном случае из десяти класс User, например, будет содержать валидный ID и SystemName и, скажем, инициализированный по умолчанию (null) член DisplayName? Если, к примеру, в этом вызове он "не нужен".
Это не является признаком кривой архитектуры?
(Я не пытаюсь подколоть, я просто хочу разобраться в собственных абстракциях.)
Здравствуйте, GlebZ, Вы писали:
GZ>А обычно именно такая гибкость и востребована. Ввели для собаки шкуру. Сами BE собаки я могу не трогать. И вполне могу не тестировать, поскольку при реализации шкурного вопроса — это саму собаку как таковую мы не затрагиваем. Я дополняю функциональность сервера по мере развития — но не переопределяю.
В прошлый раз выяснилось, что твоя задача, исходя из которой ты придумываешь сценарии вообще может обойтись без объектов. NameValueCollection — вот твой единственный DTO. Думаю, что продолжая этот спор, через 5-10 топиков мы придём к тому же выводу.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>В прошлый раз выяснилось, что твоя задача, исходя из которой ты придумываешь сценарии вообще может обойтись без объектов.
Смотря каких. В данной задаче: Если ты имеешь ввиду BE — то нет. Если ты имеешь ввиду DTO — то если понадобится, можно такое организовать. Я и не буду возражать что это возможно. Я специально не стал вводить такое условие в эту исходную задачу. Пока мне интересен вопрос непротиворечивости полузаполненных объектов.
IT> NameValueCollection — вот твой единственный DTO. Думаю, что продолжая этот спор, через 5-10 топиков мы придём к тому же выводу.
Что значит единственный DTO? Вообще-то DTO — это коллекции объектов. Иногда разнотипных объектов связнных каким-то сценарием.
Я не работаю с большими иерархиями в BE. Я не боюсь большого количества BE, если они максимально просты и непротиворечивы. Я привык получать от этого пользу. У меня, действительно, процентов 90 объектов — плоcкие. Но я не могу сказать что от этого система усложняется. Скорее наоборот, она качественее адаптируется к изменениям. Но это не касается DTO.
Просто не передавай данные, которые не используются
IT>Это не противоречие. У меня нет комплекса передачи лишнего байта с сервера на клиента. Это просто рекомендация фанатикам DTO.
Если бы не эта фраза, то я бы и не стал опять вмешиваться. В остальном твоя позиция мне уже известна — но вот это утверждение мне, не нравится.
Здравствуйте, IT, Вы писали:
IT>А в твоём можно подумать не затронет.
Клиент об этом не узнает. Проблема сервера инкапсулирована в сервере за слоем DTO и никак не затрагивает контракт.
Здравствуйте, akasoft, Вы писали:
A>Это не является признаком кривой архитектуры?
Признаком кривой архитектуры является громоздкое, запутанное, плохо расширяемое решение. Если то о чём ты говоришь приведёт именно к этому, то да, это криво. Если не приведёт, а наоборот сделает решение более простым и лёгким в сопровождении, то нет.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, GlebZ, Вы писали:
IT>>А в твоём можно подумать не затронет. GZ>Клиент об этом не узнает. Проблема сервера инкапсулирована в сервере за слоем DTO и никак не затрагивает контракт.
Как это не узнает. Здрасьте! А поле в грид кто добавлять будет? Сервер?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, GlebZ, Вы писали:
IT>>Как это не узнает. Здрасьте! А поле в грид кто добавлять будет? Сервер? GZ>Перечитай исходное сообщение — Re[15]: DTO внутри BusinessObject
Hello, "adontz" > > IT>Зачем? Просто не передавай данные, которые не используются. > > Во-первых, объявление даже пустых структур анимает место. Кроме того > приписывать к классу кучу комментариев — "если объект этого класса > возвращён методов А, то поле Б не заполнено" дло ИМХО бесперспективное
ADSI именно так и делает. Можно рассмотреть пример реализации ADSI в стиле
"DTO вокруг"?
Posted via RSDN NNTP Server 2.0
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Hello, "GlebZ" > TK>С другой стороны, если посмотреть глубже то вроде как возвращает он не > только собак но и носы, хвосты и т.п... > Не носы и хвосты, а конкретный нос и конкретный хвост(если он вообще есть) > конкретной собаки. > Я просто попросил сделать аналогичную задачу по той методике которую > использует IT. Или, например, ты?
На самом деле не важно возаращается конкретный нос или нет. Важно то, что
метод под названием ДайСобаку возвращает объекты типа Нос. Для данной задачи
метод GetDog должен возвращать собаку. А уж целую или нет — это дело вкуса.
Posted via RSDN NNTP Server 2.0
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>На самом деле не важно возаращается конкретный нос или нет. Важно то, что TK>метод под названием ДайСобаку возвращает объекты типа Нос. Для данной задачи TK>метод GetDog должен возвращать собаку. А уж целую или нет — это дело вкуса.
По правде говоря да. Если следовать данной логике, и носа без животного нет, то отсечение DogLoadMode.Dog — вряд ли будет использоваться.
Здравствуйте, IT, Вы писали:
V>>Ведь дата контракты это чистейшей воды DTO. IT>Кто это сказал?
Ну так Microsoft их проталкивает в таком облике. Не в зубах же ими ковырятся!
V>>Вот возьмем к примеру многоуровневое и распределенное приложение которое использует WCF и "легкие" сущности. Так мы можем дойти до ситуации когда на каждом свойстве наших сущностей будет навешано до десятка атрибутов (валидация, дата контракт, маппинг бд и т.д.). А эти атрибуты определены в других сборках которые тоже надо тащить по всем уровням. Все это увеличивает связность приложения.
IT>Очень хороший вопрос. Главное конкретный, а не высосанный из пальца. На конкретный вопрос можно привести конкретный пример. IT> Имеет ли смысл в этом случае городить огород? Не знаю, надо разбираться с конкретной задачей.
Задача — найти золотую середину для архитектуры приложения работающего с финансовыми данными. Распределенность, Smart & Web clients, серверная часть расчитаная на несколько сот пользователей, разграничение прав/доступа/данных — это главные черты.
И здесь, отсутсвие опыта в это вопросе мне подсказывает подстраховаться... Я не могу как седой мудрец ака Архитектор ткнуть пальцем и сказать: "надо взять вот этот O/R Mapper". Вместо этого, я беру понравившийся мапер, прячу его за еще одним уровнем абстракции чтобы потом, если появятся проблемы было возможно его безболезненно заменить... И так практически со всеми компонентами системы! (включая сущности) Вы скажете паранойя? ДА! Но как по другому обезопасится от ошибок в дизайне при отсутвия опыта и "седого мудреца" за соседним столом?
IT>Конечно увеличит. Давай сравним. Допустим нам нужно отобразить список пользователей на гриде. Вот минимальное решение.
Да, это упрощенный, но тем не менее реальный пример.
IT>Учитывая, что реальные приложения многократно сложнее этого примера, то и количество телодвижений пропорционально увеличивается, увеличивается запутанность кода, что в свою очередь приводит лавинообразному процессу и выхода сложности системы из под контроля.
Да, согласен, некоторые осложнения при поддержке гарантированы — нарушается принцип DRY — Don't repeat yourself.
Но все не так уж и плохо: в некоторых случаях можно совместить например DTO и клиентские сущности и биндить их на формы.
А вобще, следя за развитием этого топика, мне пришла мысль что разногласия не так уж и велики: обе стороны согласны, что обьектная модель не обязательно может совпадать в клиентской и серверной частях приложения. Но если ты, Игорь, (если я правильно понял) за то чтобы серверная часть модели только расширяла клиентскую часть модели предметной области, то мне и другим оппонентам кажется более правильным подход когда существует две разных модели — похожих, но разных. С разными задачами: одна, заточена на прибивание на формы, а другая — для обслуживания нужд серверной бизнес логики... В любом случае мы получаем 2 различных модели. Так не лучше ли разделить их? "Разделяй и властвуй"! Разве нет?
Да, все вышесказаное верно для приложений отличных от "вытащить из базы, протащить по слоям и показать".
Здравствуйте, IT, Вы писали:
IT>Да... ещё забыл насчёт связности. Какой из примеров теперь выглядит более связным?
Для меня, как пример связности является отсутствие прямой связи между клиентскими и серверными уровнями. Они связаны только коммуникационным уровнем. А общие сущности для всех уровней как раз и являются такой связью. И, как я уже говорил, сущности потянут за собой еще несколько сборок всякой шелухи, типа валидаторов...
Как избежать связности?
Например, UI часть работает со своими своими сущностями, ни о DTO, ни о каком-то сервере ничего не знает. Но! У клиента есть манюсенький слой, который знает какой тропой ходить к серверу, как просить у него данные и разруливать исключительные ситуации. Вот этот слой (иногда его называют Service Agent) и производит упаковку в/из DTO. Далее, все это передается на сервер, где висит сервис который отвечает за вызовы к уровню бизнес логики а также отвечает за маппинг DTO в серверную бизнес сущность. Таким образом, клиент у нас абсолютно никак не связан с сервером — он о нем даже не знает. Вот это я называю слабой связностью (low coupling).
При таком подходе, что мы имеем в минусе:
— поддержка трех разных сущностей как следствие усложнение поддержки.
— дублирование некоторой информации
— ручной или полу-автоматический мапинг DTO <-> сущность
В плюсе у нас:
— разделение ответственности (separation of concerns) — каждая часть занимается тем чем надо и сущности не перегружаются функциональностью и метаинформацией.
— полная независимость клиента от сервера. можно:
а) переписать клиента не затрагивая сервер и наоборот
б) написать еще один клиент (есть декстоп клиент, можно написать Web клиент)
в) присоединить клиент напрямую к серверной логике (и получить однопользовательские приложение)
г) разделить разработку сервера и клиета между разными командами.
— в случае использования продвинутой технологии передачи данных это дает возможность использовать все возможности технологии (к примеру, версионность).
PS: я могу быть не прав. "Я не волшебник, я только учусь". Может быть более опытные архитекторы/програмисты могут создать "с наскоку" более удачную структуру приложения учитывая свой предыдущий опыт. У меня такого опыта нет, так что я пытаюсь минимизировать риски и создать универсальную архитектуру, подходящюю под самое главное требование заказчика: "пойди туда не знаю куда, сделай то не знаю что".
Здравствуйте, varely, Вы писали:
V>>>Ведь дата контракты это чистейшей воды DTO. IT>>Кто это сказал?
V>Ну так Microsoft их проталкивает в таком облике. Не в зубах же ими ковырятся!
Не приведёшь ли какую-нибудь ссылочку, чтобы я мог убедиться в том, что MS действительно это проталкивает?
V>И здесь, отсутсвие опыта в это вопросе мне подсказывает подстраховаться... Я не могу как седой мудрец ака Архитектор ткнуть пальцем и сказать: "надо взять вот этот O/R Mapper". Вместо этого, я беру понравившийся мапер, прячу его за еще одним уровнем абстракции чтобы потом, если появятся проблемы было возможно его безболезненно заменить... И так практически со всеми компонентами системы! (включая сущности) Вы скажете паранойя? ДА! Но как по другому обезопасится от ошибок в дизайне при отсутвия опыта и "седого мудреца" за соседним столом?
Обезопасится очень просто. Нужно стремится получить максимально простое решение.
В моей практике дополнительные абстрактные уровни "на всякий случай" оправдывали себя только в одном случае, когда надо было защититься от бестолковости и упёртости других девелоперов. Вот где абстрактные уровни рулят немерянно. Если я UI девелопер и у меня есть список ФТ и мокапы экранов, то делайте в своей бизнес логике что хотите, только выдайте мне нужные данные хоть в каком-нибудь виде. Но это отмороженные ситуации, которых было не так много.
Обычно же, введение дополнительных уровней и усложнение логики их взаимодействия ни к чему хорошему не приводит и никаких преимуществ не даёт. Что ты будешь делать если, например, тебе нужно будет поменять поле Address на список Addresses? Думаешь можно будет безболезненно спрятаться за одним уровнем? Я очень сильно сомневаюсь. Нужно будет протащить это изменение по всем уровням. Но так как твоё решение сложнее, многословнее и запутаннее, то сделать это будет куда труднее.
Я же поступлю проще. Я уберу лишние уровни и лишний код, а когда появятся проблемы, то просто проведу рефакторинг, который на простом коде сделать будет не сложно.
V>Но все не так уж и плохо: в некоторых случаях можно совместить например DTO и клиентские сущности и биндить их на формы.
Можно, но это уже будут не DTO
V>А вобще, следя за развитием этого топика, мне пришла мысль что разногласия не так уж и велики: обе стороны согласны, что обьектная модель не обязательно может совпадать в клиентской и серверной частях приложения. Но если ты, Игорь, (если я правильно понял) за то чтобы серверная часть модели только расширяла клиентскую часть модели предметной области, то мне и другим оппонентам кажется более правильным подход когда существует две разных модели — похожих, но разных. С разными задачами: одна, заточена на прибивание на формы, а другая — для обслуживания нужд серверной бизнес логики... В любом случае мы получаем 2 различных модели. Так не лучше ли разделить их? "Разделяй и властвуй"! Разве нет?
Нет. Я не против разных моделей, я против выделения DTO как объектов, предназначенных исключительно для транспорта. А если DTO не выделять, то окажется, что между этими моделями больше общего, чем разного и многие вещи можно повторно использовать.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Не приведёшь ли какую-нибудь ссылочку, чтобы я мог убедиться в том, что MS действительно это проталкивает?
Ну, по крайней мере у меня сложилось такое впечатление. В документации, статьях и примерах Data Contract (и Message) это прежде всего единицы передачи/упаковки данных...
IT>Обезопасится очень просто. Нужно стремится получить максимально простое решение.
Аксиома! Записать и повторять каждый раз перед тем как
IT>Я же поступлю проще. Я уберу лишние уровни и лишний код, а когда появятся проблемы, то просто проведу рефакторинг, который на простом коде сделать будет не сложно.
Спасибо.
С меня
IT>Нет. Я не против разных моделей, я против выделения DTO как объектов, предназначенных исключительно для транспорта. А если DTO не выделять, то окажется, что между этими моделями больше общего, чем разного и многие вещи можно повторно использовать.
Здравствуйте, GlebZ, Вы писали:
IT>>>>Например, сопровождаемость. GZ>>>Сопровождаемость в разных задачах значат разные вещи. Что ты в данном случае имеешь ввиду под сопровождаемостью? IT>>Готовность системы к будущим изменениям. GZ>К каким изменениям? Для одних это подмена всего сервера, для других версионификация контракта, для третьих возможность добавления новых типов и т.д. и т.п. Low Coupling/High Cohesion — есть свойство любой правильной архитектуры.
Вообще говоря, точно так же, как и при обсуждении масштабируемости, поддерживаемость должна конкретизироваться. Невозможно разработать просто "более готовую к изменениям систему". Нужно хотя бы на элементарном уровне прикинуть, какого рода изменения могут произойти и насколько часто.
Ну вот, например, для бензоколонки цена бензина — очень часто меняющаяся вещь; список действующих дисконтных программ меняется пореже, а новая марка бензина вообще имеет шанс не появиться за время жизни софта.
Это означает, что решение, требующее перекомпиляции для изменения цены идет в топку сразу же, а для внесения нового топлива — нет. Более того, заморачивание над умением системы мгновенно изменять список бензинов чревато тем, что бюрократы называют "нецелевым использованием средств".
Вот, кстати, из моего опыта многие архитекторы совершенно неверно оценивают вот эти перспективы изменений, и получают совершенно ублюдочные системы. Почему?
Да потому, что все эти семь слоев радуги оправдывают "возможностью перейти на другую СУБД с минимальными затратами". А эта возможность не нужна почти никогда. Зато желание "добавить колонку", которое возникает в среднем 20-25 раз в год, требует в 15 раз больше изменений, чем в старой доброй "однослойной" модели. Потому, что надо чинить все 7 слоев и 8 адаптеров между ними.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Если нам не помогут, то мы тоже никого не пощадим.
1.2.0 alpha rev. 655
