Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Sinclair.
S>Ндя... По ходу читать с середины дискуссии вредно вообще.
S>Была цепочка: S>-EF малоприменимо в десктоп-приложениях/ S>-почему? S>-например, тяжело писать partial-disconnected apps-а/ S>-что такого в этих partial-disconnected? Вы неправильно готовите EF!
Я разве говорил о partial-disconnected apps?
Я говорил о применимости EF в connected n-tier приложениях.
Для partial-disconnected есть sync services и локальная БД.
По ходу мы говорим вообще о разных вещах: вы — о верификации, т.е. гарантированной проверке на нерассогласованность.
Я — о возможном обнаружении ошибок, единственная цель этого обнаружения — выдать варнинг на месте и помочь пользователю их исправить.
Кстати под юз-кейзом 4 у нас также оказались два варианта — я имел в виду именно глобальную верификацию, которая как раз не нужна и не осуществима. Сорри
Верификация требует наличия соединения с сервером и гарантирует корректность только если проверка и изменение являются частью одной транзакции, или, другими словами, проверка — часть процесса внесения изменений. Это абсолютно очевидно, всё что ниже я пишу только для того, чтобы синхронизировать точки зрения.
Проверка силами СУБД без внесения изменений возможна для примитивных сценариев типа "а нет ли у нас уже такого имени?" — объём передаваемых данных мизерен. Если объём накопленных изменений на клиенте большой — а это довольно типичный сценарий, то каждое новое действие пользователя для проверки требует передачи всех изменённых данных. Конеш, можно оптимизировать, строя граф сущностей, которых затрагивает новое изменение и передавать для проверки только их, или проверяя только элементарные сценарии. Впрочем, даже для элементарных проверок могут возникать забавные грабли — типа внесения в контекст двух сущностей с одинаковыми именами.
Опять-таки, одновременная работа множества клиентов порождает нехилые волны проверок, которые выносят кэш СУБД, вытесняя страницы, что используются для редких, но ресурсоёмких операций.
Часть из проверок можно производить локально, если сответствующие данные есть на клиенте. Эти проверки разумеется не дадут гарантированного результата, это не верификация — боже упаси, а только предварительное прощупывание на предмет возможных ошибок. С другой стороны, проверка данных в СУБД без внесения изменений тоже не даёт гарантий корректности данных, так что здесь оба способа предварительной проверки равноправны.
А дальше начинается обычная оценка — какие проверки выгодней оосуществлять локально, а какие придётся делегировать субд. Для десктоп-клиентов число проверок, которые можно проводить локально обычно очень велика. Ещё раз: мы говорим не о 100%-й уверенности "у тебя здесь ошибка" а о предупреждении "при сохранении будут внесены неверные данные".
Самый тупой пример — папки + документы. При переходе пользователя в папку в кэше оказываются все документы (естественно, метаданные, а не содержимое документов). Зная этот факт, можно поставить ограничение на уникальность {id_папки; имя документа} и наслаждаться жизнью. Тема о уникальности была поднята как самый очевидный пример локальных проверок. Оказалось — не такой очевидный.
Главаная грабля в написании partial disconnected софта — соблюдать баланс, чтобы с одной стороны клиент не захлебнулся от жадности, а с другой — не нагружать по возможности сервер. При должной степени аккуратности получается дешёвое и масштабируемое решение.
Естественно нет никакого правила большого пальца типа "все FK проверяются локально, любое UQ требует пинка серверу".
Тем не менее dal должен предоставлять способ валидации изменений вне зависимости от способа, которым эта препроверка будет осуществляться. Если dal умеет описывать часть локальных проверок декларативно — то это вообще замечательно
К сожалению, EF прям таки заставляет или отказываться от локальных проверок, или заводить свой viewmodel, который в значительной степени будет дублировать функционал датасетов.
Сорри, не имел вас в виду — вопрос про partial disconnected мы начали обсуждать с cyberax.
SyncServices предназначены для offline clients|occansionally connected clients. Это слегка другой сценарий: http://msdn.microsoft.com/en-us/sync/bb887608.aspx
Для эффективной работы SyncServices требуют хоть-какой нибудь change tracking и (для провайдера искаропки) прямой доступ к таблицам. Для partial disconnected типичный режим работы "коннектимся-заливаем небольшой объём данных-рабьотаем-синхронизация-работаем..." И здесь local db получается излишним оверкиллом.
Здравствуйте, Sinix, Вы писали:
S>По ходу мы говорим вообще о разных вещах:
Да. И если вы не начнете отвечать на вопросы, ситуация никак не изменится. Не нужно пытаться угадать, о чем я толкую.
Просто отвечайте на вопросы, и задавайте свои, если что-то непонятно.
Иначе у нас получается два несвязанных монолога.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, gandjustas!
S>Сорри, не имел вас в виду — вопрос про partial disconnected мы начали обсуждать с cyberax. S>SyncServices предназначены для offline clients|occansionally connected clients. Это слегка другой сценарий: S>http://msdn.microsoft.com/en-us/sync/bb887608.aspx
Это точно такой же сценарий, не вижу разницы.
S>Для эффективной работы SyncServices требуют хоть-какой нибудь change tracking и (для провайдера искаропки) прямой доступ к таблицам.
Можно работать через сервисы, а change-tracking дается бесплатно.
Работает это все гораздо лучше, чем change-tracking датасетов.
S>Для partial disconnected типичный режим работы "коннектимся-заливаем небольшой объём данных-рабьотаем-синхронизация-работаем..." И здесь local db получается излишним оверкиллом.
не вижу почему будет оверкиллом?
Персистентность локальной копии данных + возможность обращаться к ней с помощью SQL (следовательно тот же EF или Linq2SQL) очень даже полезна.
Извиняюсь за временное отсутствие наличия. Поскольку попытки изложить свои мысли связно и одним постом явно не находят понимания — вернёмся к цитатам на цитаты
S>Я не понимаю, каков глубокий смысл проверять локальный граф объектов на уникальность.
Проверка силами СУБД без внесения изменений возможна для примитивных сценариев типа "а нет ли у нас уже такого имени?" — объём передаваемых данных мизерен. Если объём накопленных изменений на клиенте большой — а это довольно типичный сценарий, то каждое новое действие пользователя для проверки требует передачи всех изменённых данных. Конеш, можно оптимизировать, строя граф сущностей, которых затрагивает новое изменение и передавать для проверки только их, или проверяя только элементарные сценарии. Впрочем, даже для элементарных проверок могут возникать забавные грабли — типа внесения в контекст двух сущностей с одинаковыми именами.
Опять-таки, одновременная работа множества клиентов порождает нехилые волны проверок, которые выносят кэш СУБД, вытесняя страницы, что используются для редких, но ресурсоёмких операций.
Часть из проверок можно производить локально, если сответствующие данные есть на клиенте. Эти проверки разумеется не дадут гарантированного результата, это не верификация — боже упаси, а только предварительное прощупывание на предмет возможных ошибок. С другой стороны, проверка данных в СУБД без внесения изменений тоже не даёт гарантий корректности данных, так что здесь оба способа предварительной проверки равноправны.
S>Прекрасно решается в асинхронной модели. Вон, гугл же успевает "глобально" проверять, нет ли поисковых запросов, похожих на то, что ты вводишь. Какие проблемы?
1) Валидация с учётом всех невнесённых изменений на практике неосуществима (вы этого конеш не утверждали, я об этом писал — бред о когерентности кэшей именно к этому и относился)
2) Примитивные проверки работают прекрасно, но плохо масштабируются из-за выноса кэша СУБД. Сложные непрактичны из-за резкого роста трафика — приходится строить и передавать граф изменённых сущностей.
S>Нереализуемо только в случае искусственного придумывания локальных кэшей. Все глобальные проверки делают только одно: проверяют "еще несохранённые" данные относительно "уже сохраненных".
Вроде никто не говорил о том, что локальные проверки отменяют или подменяют глобальные. Они их просто дополняют, а при аккуратном подходе хорошо снижают нагрузку на сервер. Ничего большего я и не утверждал вроде, нет?
S>Непонятно. Если каждый пользователь работает в своей песочнице, то у вас нет общей базы и повода для конфликтов.
Нихт-нихт. Речь шла о том, что можно организовать работу пользователей с данными таким образом, что для каждого из них в базе нет никаких данных кроме тех, с которыми они работают. Для этого нужно как можно больше конфликтов предупреждать локально. Здесь локальные проверки и рулят.
S>Я продолжаю непонимать. Слишком абстрактно написано. Какие именно проверки "можно провести локально"? Неоднократно звучал пример про уникальность. Я в очередной раз прошу объяснить, каким образом это собирается работать.
Работать будет в двух сценариях:
1. Если известно, что данных в кэше всегда будет достаточно для проведения проверки. Пример про уникальность по составному ключу (имена документов в папке) приводился выше.
2. Если объём изменённых данных будет достаточно большим — массовые вставки или сеанс редактирования сложного графа объхектов.
S>Я не очень понимаю, что такое "сложный граф объектов". Какого рода ограничения вы хотите проверять? В RDBMS приняты всего четыре типа ограничений:
... S>Я могу придумать еще много видов, но в большинстве случаев они сведутся к развитию 3 и 4. Ну, например, foreign key будет проверять не наличие значения в целой таблице, а в каком-то подмножестве.
Речь шла о комплексных ограничениях — когда проверки при изменении одной сущности затрагивают ряд других сущностей. (возможно, даже не напрямую). Самая нетривиальная штука что мне приходилось решать — разруливание возможных циклов при обновлениях (пример условный, на практике было забавней)
Дано: в некоторй папке живут подпапки a,b, имена подпапок должны различаться.
Сначала a перенесли в b, затем создали новую папку с именем a и перенесли старую a в новую:
a -> -> a (new) -> a (new)
b b b |-a (old)
|-a |-a (old) b
В каждый отдельный момент граф находится в валидном состоянии. Теперь попробуйте внести изменения в базу данных, если change tracking хранит только 2 состояния: старое и новое. На практике всё было куда забавнее — циклы обновлений появлялись регулярно, захватывали десятки разнотипных сущностей и по требованиям должны были обнаруживаться немедленно.
Даже если бы этого требования не было, самое простое решение "записывать изменения" и "проигрывать их на сервере" не прошло бы — в промежуточных состояниях данные нарушали уже ограничения СУБД. Там было ещё много весёлых моментов. Например, составной частью процесса был импорт из зашифрованных файлов экселя. Единственный способ выгрести данные из такого файла по odbc — сначала открыть его в самом экселе и только после этого коннектиться. Вот только сам процесс экселя оставался висеть в памяти даже после закрытия окошка, а если его прибить — выдавал диалоговое окошко при следующем открытом файле и останавливал нафиг импорт (который работать по идее должен был автоматически). COM interop не проходил по каким-то полурелигиозным причинам — я тогда плюнул и не стал спорить.
И подобные ситуации — не экзотика, а нормальные побочные эффекты автоматизации уже сложившегося workflow. Так что локальные проверки бывают ой как нужны.
S>А зачем тут глобальная валидация? Мы же это обсуждали. Почему в ответ на вопрос про ограничения типа 3 и типа 4 приводится пример типа 2?
Уже писалось — под глобальной валидацией я наивно понимал проверку с учётом всех невнесённых изменений.
S>Нет, я говорю именно о проверке до сохранения. Вот я набрал в форме "700р". Клиент сбегал проверил — баланс на счету достаточный, можно нажимать Ok. Но я не нажимаю. Значит, клиент будет вынужден иногда бегать на сервер за обновлениями. Почему? Да потому, что могло быть наоборот — я набрал "2000р". Да, я в курсе, что в момент открытия формы там было 1000. Но я знаю, что с минуты на минуту мне на счет положат еще 5000р. Клиент не должен запрещать мне попытку провести деньги — он может быть не в курсе, что там происходит на другом конце.
Варнинг он хоть должен выдать-то? Ещё раз: локальные ограничения нужны в первую очередь для обнаружения и исправления возможных ошибок ввода — чтобы пользователю не пришлось откручивать назад стек и вспоминать что именно вызвало ошибку при сохранении.
S>Какой-то он очень неявный, этот признак. Я не верю в то, что возможно спроектировать UI с гарантией выполнения таких требований. Он бы потребовал удержания транзакции на уровне serializable с самого начала перехода в режим редактирования и до самого коммита. Технически это возможно, но будет очень-очень хреново масштабироваться. S>Поэтому на мой взгляд имеет смысл несколько снизить требования к UI. И я полагал, что именно этот вариант мы и обсуждаем — клиент старается сделать как можно больше, но ничего не гарантирует до сохранения. S>>Чтобы избежать подобных проблем, можно например ввести проверку, что товарищ уже не залогинился где-либо ещё. S>Зачем? Кому нужны эти ограничения?
Дык вроде никто и не замахивался на /*завоевание галактики*/ написание сверхнадёжного клиента — речь шла именно о предотвращении ошибок пользователя.
И с этой точки зрения запрет на одновременную работу нескольких товарищей под одним пользователем — довольно разумная вешь. Особенно если задачи, выполняемые пользователями распарралеливаются так, чтобы конфликты при редактировании возникали как можно реже. Ну и не стоит понимать запрет буквально — достаточно проверки с предупреждением.
S>>При одновременном редактировании одних и тех же сущностей неизбежны конфликты. Поэтому работа пользователей организуется таким образом, чтобы один товарищ не мешал другому — это чисто административные меры. Отсюда и берутся "почти непересекающиеся" песочницы. S>Но ведь ограничения-то выходят за пределы песочниц! Если мы говорим об уникальности в пределах песочницы — так и говорите. Но у меня сложилось впечатление, что речь идет о глобальной уникальности. S>>Тем не менее, при редактировании своих данных каждый товарищ может внести сложные ошибки, которые можно обнаружить, только проверив весь граф объектов. Если граф уже есть на клиенте (а часть его скорее всего там есть, раз уж мы его изменяем), то по возможности такие ошибки надо проверять на месте. S>Вот мне и непонятно, каким образом вы выполняете "проверку всего графа", когда на клиенте скорее всего его часть.
S>>На всякий. Речь идёт не о вытягивании всей базы на клиента, а об организации работы так, чтобы каждый пользователь мог работать с небольшим сегментом данных и не заботиться о том, что он кому-то что-то поломает. S>Это понятно. Намерения ваши были ясны еще с первого постинга. Я просто не понимаю, как вы собираетесь их выполнять.
Часть из проверок можно производить локально, если сответствующие данные есть на клиенте. Эти проверки разумеется не дадут гарантированного результата, это не верификация — боже упаси, а только предварительное прощупывание на предмет возможных ошибок. С другой стороны, проверка данных в СУБД без внесения изменений тоже не даёт гарантий корректности данных, так что здесь оба способа предварительной проверки равноправны.
А дальше начинается обычная оценка — какие проверки выгодней оосуществлять локально, а какие придётся делегировать субд. Для десктоп-клиентов число проверок, которые можно проводить локально обычно очень велика. Ещё раз: мы говорим не о 100%-й уверенности "у тебя здесь ошибка" а о предупреждении "при сохранении будут внесены неверные данные".
...
Главаная грабля в написании partial disconnected софта — соблюдать баланс, чтобы с одной стороны клиент не захлебнулся от жадности, а с другой — не нагружать по возможности сервер. При должной степени аккуратности получается дешёвое и масштабируемое решение.
Естественно нет никакого правила большого пальца типа "все FK проверяются локально, любое UQ требует пинка серверу".
Тем не менее dal должен предоставлять способ валидации изменений вне зависимости от способа, которым эта препроверка будет осуществляться. Если dal умеет описывать часть локальных проверок декларативно — то это вообще замечательно
Если на что-то не ответил — извиняйте. Поскольку размер постов с взаимными разъяснениями потихоньку подбирается к бесконечности, а постов по теме — к нулю, предлагаю закрыть тему.
Здравствуйте, gandjustas.
S>>Сорри, не имел вас в виду — вопрос про partial disconnected мы начали обсуждать с cyberax. S>>SyncServices предназначены для offline clients|occansionally connected clients. Это слегка другой сценарий: S>>http://msdn.microsoft.com/en-us/sync/bb887608.aspx G>Это точно такой же сценарий, не вижу разницы.
Тем не менее разница есть: offline clients предполагают, что клиент способен самостоятельно жить в офлайне и что эта жизнь имеет какой-никакой смысл. Главный критерий здесь мобильность.
А partial-disconnected apps это всего лишь способ снизить нагрузку на сеть/сервер и заодно реализовать сценарии, что трудно реализовать без локального кэша. Здесь данные постоянно находятся в памяти — in-memory db просто не нужна.
S>>Для эффективной работы SyncServices требуют хоть-какой нибудь change tracking и (для провайдера искаропки) прямой доступ к таблицам. G>Можно работать через сервисы, а change-tracking дается бесплатно. G>Работает это все гораздо лучше, чем change-tracking датасетов.
Я как-то не понимаю, как чанжтракинг становится бесплатным. И каким боком он будет лучше датасетов. Разжуйте плиз.
Ну вот смотрите:
Вариант 1: Используем датасеты.
Деплоймент клиента: всё искаропки.
Особые требования к СУБД: никаких.
Передача данных: Данные заливаются с базы данных как tds, обратно — изменённые данные как параметры RPC (если хранимые процедуры, если ad-hoc sql — +текст команды).
Вариант 2: EF + SQL CE + ADO.NET DataServices или SSDS (если их таки выпустят). Вы ведь это имели в виду
Деплоймент клиента: помимо фреймворка ставится sql ce — xcopy install уже не катит. // пустая придирка — решается install policies.
Особые требования к СУБД:
1) Наличие rowversion столбца.
2) прямой доступ к таблицам или к представлениям.
Передача данных:
субд — сервисы: tds;
сервисы — sql ce: xml по rest -> ??? -> сохранение в sql ce;
sql ce — клиент: ef -> shared memory.
А как вы собираетесь подружить SyncServices и DataServices? В мсдн нет ни слова по поводу их скрещивания. Первые используют датасеты для передачи данных между sql ce и провайдером, вторые — ef + wcf. Писать свой провайдер имхо получится слишком дорого. Если есть наводки — поделитесь.
S>>Для partial disconnected типичный режим работы "коннектимся-заливаем небольшой объём данных-рабьотаем-синхронизация-работаем..." И здесь local db получается излишним оверкиллом. G>не вижу почему будет оверкиллом? G>Персистентность локальной копии данных + возможность обращаться к ней с помощью SQL (следовательно тот же EF или Linq2SQL) очень даже полезна.
Про оверкилл написал выше. Персистентность для partial connected нужна разве что для бэкапа на случай пропажи питания/выгрузки данных на случай нехватки памяти. Для датасетов есть Linq2DataSets.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, gandjustas.
S>>>Сорри, не имел вас в виду — вопрос про partial disconnected мы начали обсуждать с cyberax. S>>>SyncServices предназначены для offline clients|occansionally connected clients. Это слегка другой сценарий: S>>>http://msdn.microsoft.com/en-us/sync/bb887608.aspx G>>Это точно такой же сценарий, не вижу разницы.
S>Тем не менее разница есть: offline clients предполагают, что клиент способен самостоятельно жить в офлайне и что эта жизнь имеет какой-никакой смысл. Главный критерий здесь мобильность. S>А partial-disconnected apps это всего лишь способ снизить нагрузку на сеть/сервер и заодно реализовать сценарии, что трудно реализовать без локального кэша. Здесь данные постоянно находятся в памяти — in-memory db просто не нужна.
Все равно разницы нету. Разница между вашими offline clients и partial-disconnected apps только в персистентности кеша. Все остальное окажется точно таким же.
S>>>Для эффективной работы SyncServices требуют хоть-какой нибудь change tracking и (для провайдера искаропки) прямой доступ к таблицам. G>>Можно работать через сервисы, а change-tracking дается бесплатно. G>>Работает это все гораздо лучше, чем change-tracking датасетов.
S>Я как-то не понимаю, как чанжтракинг становится бесплатным. И каким боком он будет лучше датасетов. Разжуйте плиз.
Ничего не надо делать чтобы получить чанжтракинг. Лучше датасетов за счет полноценного SQL.
S>Вариант 2: EF + SQL CE + ADO.NET DataServices или SSDS (если их таки выпустят). Вы ведь это имели в виду
Не мешайте все в одну кучу.
Можно EF на серврере и ADO.NET DataServices на клиенте при наличиии постоянного соединения.
Для offline работы Sync Services. на клиенте и сервере можно использовать любую технологию доступа к данным.
SSDS вообще из другой оперы.
S>Деплоймент клиента: помимо фреймворка ставится sql ce — xcopy install уже не катит. // пустая придирка — решается install policies.
Фигня, SQL CE нормально xcopy ставится.
S>Особые требования к СУБД: S> 1) Наличие rowversion столбца.
Делается автоматически
S> 2) прямой доступ к таблицам или к представлениям.
Можно работать через вебсервисы.
S>А как вы собираетесь подружить SyncServices и DataServices? В мсдн нет ни слова по поводу их скрещивания. Первые используют датасеты для передачи данных между sql ce и провайдером, вторые — ef + wcf. Писать свой провайдер имхо получится слишком дорого. Если есть наводки — поделитесь.
Пока никак. Сейчас MS делает возможности иснхронизации через DataServices.
А вообще зачем их сомещать в Disconnected режиме?
S>>>Для partial disconnected типичный режим работы "коннектимся-заливаем небольшой объём данных-рабьотаем-синхронизация-работаем..." И здесь local db получается излишним оверкиллом. G>>не вижу почему будет оверкиллом? G>>Персистентность локальной копии данных + возможность обращаться к ней с помощью SQL (следовательно тот же EF или Linq2SQL) очень даже полезна.
S>Про оверкилл написал выше. Персистентность для partial connected нужна разве что для бэкапа на случай пропажи питания/выгрузки данных на случай нехватки памяти.
От частого повторения утверждение не становится истинным.
S>Для датасетов есть Linq2DataSets.
Ну и зачем он нужен?
Здравствуйте, gandjustas.
G>Все равно разницы нету. Разница между вашими offline clients и partial-disconnected apps только в персистентности кеша. Все остальное окажется точно таким же.
Нет. Есть принципиальные отличия: offline client — самостоятельное приложение, что обращается к серверу только для загрузки свежих данных/изредка запихнуть что-то своё (на десктопе как пример — оутглюк/рсс ридер). А Partial disconnected — всего лишь фронтенд к реальной системе. Он не предназначен для работы без соединения, а всего лишь не держит соединение постоянно открытым. Сценарии использования у софтин соответственно разные.
S>>Я как-то не понимаю, как чанжтракинг становится бесплатным. И каким боком он будет лучше датасетов. Разжуйте плиз. G>Ничего не надо делать чтобы получить чанжтракинг. Лучше датасетов за счет полноценного SQL.
Энееет. Вы писали "Работает это все гораздо лучше, чем change-tracking датасетов". Теперь расскажите как чанжтракинг выиграет от возможности выгребать данные при помощи sql? Или вы имеете в виду отслеживание изменений в анонимных типах — результатах запросов (которые by design readonly вообще-то) ?
Дальше. "Ничего не надо делать чтобы получить чанжтракинг.". Ничего не надо делать где? Если на сервере, чтобы получить свежие изменения — как раз надо. Если на клиенте — то датаадаптеры используют чанжтракинг датасетов и работают из коробки. Кстати в EF v2 будут Self-Tracking Entities — datarow вид сбоку (на самом деле ни разу не datarow конеш): http://blogs.msdn.com/efdesign/archive/2009/03/24/self-tracking-entities-in-the-entity-framework.aspx
Кажется, я просто вас здесь не понял...
G>Не мешайте все в одну кучу. G>Можно EF на серврере и ADO.NET DataServices на клиенте при наличиии постоянного соединения. G>Для offline работы Sync Services. на клиенте и сервере можно использовать любую технологию доступа к данным.
Ок, не будем. С какими технологиями доступа к данным работают Sync Services кроме дефолтного варианта "sql ce — sync services — sql server"?
Чтобы я не перевирал несказанное вами, предложите вашу альтернативу варианту 1
G>SSDS вообще из другой оперы.
Таки не совсем из другой оперы — ёжиков решено скрещивать. http://visualstudiomagazine.com/blogs/weblog.aspx?blog=3577:
A. We are looking into our future roadmap to make sure that Astoria [ADO.NET Data Services] can be leveraged on top of SDS and Entity Data Model continues to exist, and we will continue to provide for that through Astoria. We will continue to work with the Astoria framework and figure out how SDS can support that.
Как уже писалось, некритично — ставится один фиг через AD setup policies.
S>>Особые требования к СУБД: S>> 1) Наличие rowversion столбца. G>Делается автоматически
Изменение схемы базы данных не всегда допустимо. Точнее, как правило недопустимо.
S>> 2) прямой доступ к таблицам или к представлениям. G>Можно работать через вебсервисы.
Как я понял, sync services не умеют работать с вебсервисами. Даже если и умел бы, DataServices потребуют доступа к таблицам/view, что не всегда возможно — на тебе хранимки и не выкобенивайся... Насколько помню, других способов из коробки выставить БД как сервисы сейчас у МС нет. Пишем своё или ждём SDS?
S>>А как вы собираетесь подружить SyncServices и DataServices? В мсдн нет ни слова по поводу их скрещивания. Первые используют датасеты для передачи данных между sql ce и провайдером, вторые — ef + wcf. Писать свой провайдер имхо получится слишком дорого. Если есть наводки — поделитесь. G>Пока никак. Сейчас MS делает возможности иснхронизации через DataServices. G>А вообще зачем их сомещать в Disconnected режиме?
Имелось в виду именно использование DataServices для синхронизации через вебсервисы. DataServices пока поддерживает только ef. Потому и спросил.
G> G>От частого повторения утверждение не становится истинным.
Ну вы ведь не будете утверждать, что "EF<->sql ce<->syncservices (+возможно вебсервисы)<->sqlserver" эффективнее чем "DataSet<->sqlserver"? Основной режим работы "Залил данные — поработал — сохранил — залил данные...".
S>>Для датасетов есть Linq2DataSets. G>Ну и зачем он нужен?
Для псевдо-sql запросов к датасетам — как просили.
Здравствуйте, Sinix, Вы писали:
S>Извиняюсь за временное отсутствие наличия. Поскольку попытки изложить свои мысли связно и одним постом явно не находят понимания — вернёмся к цитатам на цитаты
Прекрасно, спасибо. S>
S>Часть из проверок можно производить локально, если сответствующие данные есть на клиенте. Эти проверки разумеется не дадут гарантированного результата, это не верификация — боже упаси, а только предварительное прощупывание на предмет возможных ошибок. С другой стороны, проверка данных в СУБД без внесения изменений тоже не даёт гарантий корректности данных, так что здесь оба способа предварительной проверки равноправны.
Ок, давайте поговорим о равноправии. Я уже предлагал — вы проигнорировали. Попробуем еще раз.
Раз мы отказываемся от стопроцентных гарантий, значит речь идет о вероятностном подходе. Никто не отрицает его полезность и важность. Но он тоже должен поддаваться учету и контролю.
Итак, у нас есть N данных. Из них K в кэше. Предположим, что существует ровно один дубликат. С вероятностью K/N он окажется в кэше (и проверка его найдет), с вероятностью 1-K/N он окажется вне кэша.
Итак, шансы на то, что "предварительное прощупывание" имет смысл, примерно равны K/N. Чему у вас равно это отношение?
Теперь давайте оценим полезность предварительной проверки в СУБД. Очевидно, что никакого шанса "пропустить" дубликат у нее нету, и единственный шанс облажаться — это получить дубликат за время T между проверкой и коммитом.
Предположим, остальные пользователи вносят изменения в интересующие нас данные с частотой F. При этом разнообразие значений примерно M, то есть вероятность для каждого отдельного изменения внести дубликат ~1/M. Итак, за время T было проведено T*F изменений, вероятность того, что ни одно из них не оказалось дубликатом = (1-1/M)^(T*F).
Значит, вероятность наличия дубликата растет со временем как 1-(1-1/M)^(T*F). Если сильно хочется, то можно разложить в ряд Тейлора по T, но и так понятно, что первый член будет равен T*F/M.
Итак, нам нужно сравнить P1 = K/N, и P2 = 1-(1-1/M)^(T*F).
S>1) Валидация с учётом всех невнесённых изменений на практике неосуществима (вы этого конеш не утверждали, я об этом писал — бред о когерентности кэшей именно к этому и относился)
Я повторно объясняю: нет задачи валидировать "с учетом невнесённых изменений". Невнесённых изменений вообще нет, с точки зрения теории транзакций. Потому, что если их не закоммитить, то их и не было никогда.
S>2) Примитивные проверки работают прекрасно, но плохо масштабируются из-за выноса кэша СУБД. Сложные непрактичны из-за резкого роста трафика — приходится строить и передавать граф изменённых сущностей.
Не понимаю, при чём тут кэш СУБД. Намекаю, что проверка на уникальность по индексированному ключу стоит порядка 0 обращений к диску. В плохих случаях — 1 обращение к диску.
S>Вроде никто не говорил о том, что локальные проверки отменяют или подменяют глобальные. Они их просто дополняют, а при аккуратном подходе хорошо снижают нагрузку на сервер. Ничего большего я и не утверждал вроде, нет?
Можно в студию формулы про снижение нагрузки? Мы же не стилисты, у нас "хорошо" должно иметь какое-то количественное выражение.
S>Нихт-нихт. Речь шла о том, что можно организовать работу пользователей с данными таким образом, что для каждого из них в базе нет никаких данных кроме тех, с которыми они работают.
Ну так я об этом и говорю — раз для него в базе нет никаких чужих данных, значит можно просто завести ему отдельную базу. S>Для этого нужно как можно больше конфликтов предупреждать локально. Здесь локальные проверки и рулят.
Откуда взялись конфликты?
S>Работать будет в двух сценариях: S>1. Если известно, что данных в кэше всегда будет достаточно для проведения проверки. Пример про уникальность по составному ключу (имена документов в папке) приводился выше.
А, я наверное не уловил про документы в папке. Вот теперь я начинаю понимать — это да, если гарантировать, что все Иваны у нас в кэше, то проверка уникальности фамилии даст корректный результат. А есть еще какие-нибудь проверки, которые можно вот так сегментировать? Только, пожалуйста, без абстракций. S>2. Если объём изменённых данных будет достаточно большим — массовые вставки или сеанс редактирования сложного графа объхектов.
Я не понимаю, что такое "сложный граф объектов" и почему при нём локальная проверка уникальности будет хоть сколько-нибудь полезна.
S>Дано: в некоторй папке живут подпапки a,b, имена подпапок должны различаться. S>Сначала a перенесли в b, затем создали новую папку с именем a и перенесли старую a в новую:
S>
S>a -> -> a (new) -> a (new)
S>b b b |-a (old)
S> |-a |-a (old) b
S>
S>В каждый отдельный момент граф находится в валидном состоянии. Теперь попробуйте внести изменения в базу данных, если change tracking хранит только 2 состояния: старое и новое.
Ок, давайте посмотрим, что произошло: S>
a -> a (new)
|-a (old)
b -> b
S>
простите, я не понимаю в чем проблема. Все изменения свелись к добавлению подпапки с именем a в папку с именем a.
Если важно сохранение суррогатных ключей, и СУБД не умеет откладывать проверки до окончания транзакции, то есть тупой и гарантированно рабочий алгоритм двухстадийного переименования.
В нем переименовываемые объекты сначала получают гарантированно уникальные имена, а потом уже получают настоящие.
Но как правило, СУБД откладывает такие проверки как минимум до конца стейтмента. Ну, а дальше уже вопрос техники — как обновить все объекты цикла за один стейтмент.
S>Варнинг он хоть должен выдать-то? Ещё раз: локальные ограничения нужны в первую очередь для обнаружения и исправления возможных ошибок ввода — чтобы пользователю не пришлось откручивать назад стек и вспоминать что именно вызвало ошибку при сохранении.
Чтобы не откручивать и не вспоминать — сообщения об ошибках должны давать достаточно информации. Сообщения типа "что-то сломалось" — сакс и бэдли независимо от применяемой технологии.
S>Дык вроде никто и не замахивался на /*завоевание галактики*/ написание сверхнадёжного клиента — речь шла именно о предотвращении ошибок пользователя. S>И с этой точки зрения запрет на одновременную работу нескольких товарищей под одним пользователем — довольно разумная вешь.
Во-первых, мне непонятно, каким именно образом несколько товарищей работают под одним пользователем по ошибке. Это типа "ой, я случайно набрала логин Юли и ее пароль?"
Во-вторых, зато есть масса полезных сценариев, где человек логинится под собой несколько раз.
S> Особенно если задачи, выполняемые пользователями распарралеливаются так, чтобы конфликты при редактировании возникали как можно реже. Ну и не стоит понимать запрет буквально — достаточно проверки с предупреждением.
Вообще-то сначала это фигурировало именно как математически достоверный факт, на который опиралась логика валидации.
S>А дальше начинается обычная оценка — какие проверки выгодней оосуществлять локально, а какие придётся делегировать субд. Для десктоп-клиентов число проверок, которые можно проводить локально обычно очень велика. Ещё раз: мы говорим не о 100%-й уверенности "у тебя здесь ошибка" а о предупреждении "при сохранении будут внесены неверные данные".
Можно формулу для "очень велика" в студию?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, gandjustas.
G>>Все равно разницы нету. Разница между вашими offline clients и partial-disconnected apps только в персистентности кеша. Все остальное окажется точно таким же.
S>Нет. Есть принципиальные отличия: offline client — самостоятельное приложение, что обращается к серверу только для загрузки свежих данных/изредка запихнуть что-то своё (на десктопе как пример — оутглюк/рсс ридер). А Partial disconnected — всего лишь фронтенд к реальной системе. Он не предназначен для работы без соединения, а всего лишь не держит соединение постоянно открытым. Сценарии использования у софтин соответственно разные.
Ни одна из клиент-серверных технологий .NET не держит постоянное соектное соединение. Таким образом все многозвенные — Partial disconnected?
Вы неверное выбираете критерий разделения. Правильный критерий основан на "толщине" клиента. Если клиент толстый (тпе содержит в себе бизнес-логику), то он вполне может работать в отрыве от сервера некоторое время. Если клиент тонкий, то ему на каждое действие надо обращаться к серверу. Локальные проверки уникальности в закешированных данных тонкого клиента почти бессмысленны, слишком низкая точность у них.
Если у вас сильно разделены данные, так что разные пользователи не конфликтуют друг с другом, то вполне возможно создать offline клиент, который будет регулярно синхронизировать свои данные с сервером, а не использовать датасеты.
S>>>Я как-то не понимаю, как чанжтракинг становится бесплатным. И каким боком он будет лучше датасетов. Разжуйте плиз. G>>Ничего не надо делать чтобы получить чанжтракинг. Лучше датасетов за счет полноценного SQL. S>Энееет. Вы писали "Работает это все гораздо лучше, чем change-tracking датасетов". Теперь расскажите как чанжтракинг выиграет от возможности выгребать данные при помощи sql? Или вы имеете в виду отслеживание изменений в анонимных типах — результатах запросов (которые by design readonly вообще-то) ?
Не понял о чем вы. change-tracking на уровне БД получается. changeset можно сформировать даже если приложение не работало длительное время.
S>Дальше. "Ничего не надо делать чтобы получить чанжтракинг.". Ничего не надо делать где? Если на сервере, чтобы получить свежие изменения — как раз надо. Если на клиенте — то датаадаптеры используют чанжтракинг датасетов и работают из коробки. Кстати в EF v2 будут Self-Tracking Entities — datarow вид сбоку (на самом деле ни разу не datarow конеш): http://blogs.msdn.com/efdesign/archive/2009/03/24/self-tracking-entities-in-the-entity-framework.aspx S>Кажется, я просто вас здесь не понял...
Ага, я имел ввиду что программисту ничего делать не надо.
G>>Не мешайте все в одну кучу. G>>Можно EF на серврере и ADO.NET DataServices на клиенте при наличиии постоянного соединения. G>>Для offline работы Sync Services. на клиенте и сервере можно использовать любую технологию доступа к данным.
S>Ок, не будем. С какими технологиями доступа к данным работают Sync Services кроме дефолтного варианта "sql ce — sync services — sql server"? S>Чтобы я не перевирал несказанное вами, предложите вашу альтернативу варианту 1
Искаропки — ни с какими. Но можно очень быстро сделать провайдер и адаптер для лююбой БД (указать строку соединения и несколько команд).
S>Как уже писалось, некритично — ставится один фиг через AD setup policies.
Неправда. xcopy достаточно для sqlce.
S>>>Особые требования к СУБД: S>>> 1) Наличие rowversion столбца. G>>Делается автоматически S>Изменение схемы базы данных не всегда допустимо. Точнее, как правило недопустимо.
А кто разработчик?
S>>> 2) прямой доступ к таблицам или к представлениям. G>>Можно работать через вебсервисы. S>Как я понял, sync services не умеют работать с вебсервисами.
Неправльно поняли, очень даже умеет.
S>Даже если и умел бы, DataServices потребуют доступа к таблицам/view, что не всегда возможно — на тебе хранимки и не выкобенивайся...
Ну если у вас такие проблемы, то кроме датасетов вам мало что поможет.
S>Насколько помню, других способов из коробки выставить БД как сервисы сейчас у МС нет. Пишем своё или ждём SDS?
sds совсем из другой оперы.
S>>>А как вы собираетесь подружить SyncServices и DataServices? В мсдн нет ни слова по поводу их скрещивания. Первые используют датасеты для передачи данных между sql ce и провайдером, вторые — ef + wcf. Писать свой провайдер имхо получится слишком дорого. Если есть наводки — поделитесь. G>>Пока никак. Сейчас MS делает возможности иснхронизации через DataServices. G>>А вообще зачем их сомещать в Disconnected режиме? S>Имелось в виду именно использование DataServices для синхронизации через вебсервисы. DataServices пока поддерживает только ef. Потому и спросил.
Через WCF и сейчас возможно.
G>> G>>От частого повторения утверждение не становится истинным. S>Ну вы ведь не будете утверждать, что "EF<->sql ce<->syncservices (+возможно вебсервисы)<->sqlserver" эффективнее чем "DataSet<->sqlserver"? Основной режим работы "Залил данные — поработал — сохранил — залил данные...".
Еще раз говорю что это возможно только когда один дексктопный клиент на одну базу.
S>Ок, давайте поговорим о равноправии. Я уже предлагал — вы проигнорировали. Попробуем еще раз. S>Раз мы отказываемся от стопроцентных гарантий, значит речь идет о вероятностном подходе. Никто не отрицает его полезность и важность. Но он тоже должен поддаваться учету и контролю.
Disclaimer уже был:
А дальше начинается обычная оценка — какие проверки выгодней оосуществлять локально, а какие придётся делегировать субд. Для десктоп-клиентов число проверок, которые можно проводить локально обычно очень велика. Ещё раз: мы говорим не о 100%-й уверенности "у тебя здесь ошибка" а о предупреждении "при сохранении будут внесены неверные данные".
...
Главная грабля в написании partial disconnected софта — соблюдать баланс, чтобы с одной стороны клиент не захлебнулся от жадности, а с другой — не нагружать по возможности сервер. При должной степени аккуратности получается дешёвое и масштабируемое решение.
Про "очень велика": типичные сценарии приводил:
1. Если известно, что данных в кэше всегда будет достаточно для проведения проверки. Пример про уникальность по составному ключу (имена документов в папке) приводился выше.
2. Если объём изменённых данных будет достаточно большим — массовые вставки или сеанс редактирования сложного графа объхектов.
Как подвид сценария 2 — всякие ограничения, накладываемые бизнес-логикой. Они как раз обычно очень хорошо ложатся на данные в кэше. Нужны примерно затем же что и code constraints — для нахождения косяков в БЛ.
Мне казалось, что таких отмазок достаточно для того, чтобы свернуть обсуждение на тему "насколько эффективна такая оценка" — it depends
S>Итак, нам нужно сравнить P1 = K/N, и P2 = 1-(1-1/M)^(T*F).
Уже писалось — на всякий: в общем случае эффективней обратиться к СУБД. в случае когда у нас данных на клиенте достаточно — эффективней локальная проверка. Это вроде очевидно
S>>2) Примитивные проверки работают прекрасно, но плохо масштабируются из-за выноса кэша СУБД. Сложные непрактичны из-за резкого роста трафика — приходится строить и передавать граф изменённых сущностей. S>Не понимаю, при чём тут кэш СУБД. Намекаю, что проверка на уникальность по индексированному ключу стоит порядка 0 обращений к диску. В плохих случаях — 1 обращение к диску.
Сталкивался на практике: 50-70 мелких запросов поднимали по странице в кэш (повезло с распределением ), вытесняя страницы другого индекса, что использовался для жойна в параллельных запросах. А так как оптимайзер выбирал nested loops вместо hash join, который терпимей к недостатку памяти, производительность конкретно проседала. Особенно часто подобные косяки проявлялись на серверах, где живёт куча баз и памяти не хватает по-страшному.
S>>Вроде никто не говорил о том, что локальные проверки отменяют или подменяют глобальные. Они их просто дополняют, а при аккуратном подходе хорошо снижают нагрузку на сервер. Ничего большего я и не утверждал вроде, нет? S>Можно в студию формулы про снижение нагрузки? Мы же не стилисты, у нас "хорошо" должно иметь какое-то количественное выражение.
Дык тут это — цифры нужны корректные. То что проверял лично года три назад:
Небольшая софтина/редактор типа словарика. Писалась специально для оценки стоимости регулярных обращений к серверу. Она рандомно выполняла некоторые действия над сущностями раз в 1-20 секунд и раз в 5 минут выполняла синхронизацию. При подходе с датасетами сервер держал порядка 150-200 одновременных подключений (дёргалось с 5 машин, пришлось ставить обновление непрерывно), каждое обращение занимало 1-5 секунд. Тормоза были с сетью — постоянно очередь у сетевого контроллера, процессор (celeron 1'7) — ~60%, память почти забита (памяти — 512 мб, база была сгенерена на 3 с чем-то гигов), объём отдаваемых данных на один запрос — 100-300кб.
Для EF|Linq2SQL проверка ессно не проводилась — не те времена Вместо этого данные подгружались кусочками по требованию — имитировалась подгрузка данных по мере навигации + временами дёргались запросы по текстовым столбцам — типа поиск
При полусотне коннектов база регулярно накрывалась медным тазом из-за взаимоблокировок. После убирания запросов на обновление, баттлнеком становилась очередь диска плюс память.
Могу восстановить софтинки (хотя магии там никакой нет) и прогнать по новой.
Если хочется цифр — берём теорию обслуживания (чесслово не знаю как оно зовётся по взрослому, дядечка что нам читал матобеспечение уверял что именно так) и подставляем. Время обслуживания 1-5 сек против 40-120 сек, интервал обращения — 5 минут.
S>>Нихт-нихт. Речь шла о том, что можно организовать работу пользователей с данными таким образом, что для каждого из них в базе нет никаких данных кроме тех, с которыми они работают. S>Ну так я об этом и говорю — раз для него в базе нет никаких чужих данных, значит можно просто завести ему отдельную базу. S>>Для этого нужно как можно больше конфликтов предупреждать локально. Здесь локальные проверки и рулят. S>Откуда взялись конфликты?
То, что большинство пользователей работают с практически непересекающимися диапазонами данных не значит, что пересечений этих нет. Зачем их разделять?
S>>Работать будет в двух сценариях: S>>1. Если известно, что данных в кэше всегда будет достаточно для проведения проверки. Пример про уникальность по составному ключу (имена документов в папке) приводился выше.
S>А, я наверное не уловил про документы в папке. Вот теперь я начинаю понимать — это да, если гарантировать, что все Иваны у нас в кэше, то проверка уникальности фамилии даст корректный результат. А есть еще какие-нибудь проверки, которые можно вот так сегментировать? Только, пожалуйста, без абстракций.
Да, FK (естественно ) и кастомные ограничения, что накладываются бизнес-логикой (типа не можешь создавать больше 5 папок)
S>>2. Если объём изменённых данных будет достаточно большим — массовые вставки или сеанс редактирования сложного графа объхектов. S>Я не понимаю, что такое "сложный граф объектов" и почему при нём локальная проверка уникальности будет хоть сколько-нибудь полезна.
Да любой большой UOW, что подразумевает участие пользователя приводит к куче изменений/удалений/созданию новых объектов. Корректность этих изменений выгодно проверять на месте — например, что взаказе не дублируются продукты (баг, должно увеличиться количество), что в результате пользователь не попросит больше бонусов, что ему положено и т.п.
Проверка таких "бизнес-ограничений" затрагивает кучу сущностей (особенно если данные нормализованы). И для более-менее надёжной проверки нужно, чтобы даные были когерентными (псевдо-repeatable read, если хотите). А согласованность локальных данных проще всего достигается с помошью локадьного кэша.
S>простите, я не понимаю в чем проблема. Все изменения свелись к добавлению подпапки с именем a в папку с именем a. S>Если важно сохранение суррогатных ключей, и СУБД не умеет откладывать проверки до окончания транзакции, то есть тупой и гарантированно рабочий алгоритм двухстадийного переименования.
Там не сохранение суррогатных ключей, а нарушение составных естественных ключей шло. Проблема была в сохранении кучи разнотипных сущностей (в однин стейтмент не уложишься, субд ms sql — отложить проверки нельзя), из-за грязных данных (хотя формально они были чистыми) регулярнейше возникали эдакие циклы, когда старая папка (на самом деле не папка) с таким именем должна была переместиться в новосозданную папку, которую нельзя было создать из-за старой.
Причём на вход приходил датасет, по сути — два списка: изменённые сущности в исходном состоянии и изменённые сущности в текущем состоянии. В сам процесс построения обоих списков вмешиваться было нежелательно, максимум что было разрешено — подписываться на сооответствующие события изменения строк.
По полурелигиозным причинам требовалось подобные косяки находить сразу, до внесения в базу.
S>Чтобы не откручивать и не вспоминать — сообщения об ошибках должны давать достаточно информации. Сообщения типа "что-то сломалось" — сакс и бэдли независимо от применяемой технологии.
Допустим в приведённом выше примере выдавалось текстовое описание цикла зависимостей (по гиперссылкам переходило к нужным сущностям) + предложение оставить как есть (субд разберётся) либо отменить изменения в любой из сущностей на выбор. При наличии информации об ограничениях довольно простая штука.
S>Во-первых, мне непонятно, каким именно образом несколько товарищей работают под одним пользователем по ошибке. Это типа "ой, я случайно набрала логин Юли и ее пароль?" S>Во-вторых, зато есть масса полезных сценариев, где человек логинится под собой несколько раз.
Самый типичный сценарий — товарищ логинится на другой машине, тут же выскакивает вопрос — "вы уже залогинены там-то. завершить сеанс(ы) (выбирается нужные)/проигнорировать" + галочка "запомнить". Естественно, текст куда внятней
S>> Особенно если задачи, выполняемые пользователями распарралеливаются так, чтобы конфликты при редактировании возникали как можно реже. Ну и не стоит понимать запрет буквально — достаточно проверки с предупреждением. S>Вообще-то сначала это фигурировало именно как математически достоверный факт, на который опиралась логика валидации.
У нас тут походу самый большой затык. Поскольку в мозгах у меня сейчас затый ничуть не меньший — отложим до завтра, ок?
Здравствуйте, Tom, Вы писали:
ili>>а что сразу в типизированый бизнес-объект мапить нихт? Tom>Мая твая нихт панимать
я так понял, что под "оберткой" имеется ввиду какая-то обертка над бизнес объектом.. вот зачем это я и не понимаю..
может я вообще не понял что есть "обертка"... вот интересно стало... что это и зачем оно?
ili>я так понял, что под "оберткой" имеется ввиду какая-то обертка над бизнес объектом.. вот зачем это я и не понимаю.. ili>может я вообще не понял что есть "обертка"... вот интересно стало... что это и зачем оно?
Есть стора или запрос которая возвращает поля A, B, C. Обёртка — это класс с такими полями и соответствующими типами данных.
Здравствуйте, Tom, Вы писали:
Tom>Есть стора или запрос которая возвращает поля A, B, C. Обёртка — это класс с такими полями и соответствующими типами данных.
а что потом с этой оберткой делается?
я просто втолк не возьму, это класс модели домена?
ili>а что потом с этой оберткой делается?
Например выводится на ASP.NET страничке
ili>я просто втолк не возьму, это класс модели домена?
Нет конечно. И я незнаю что такое класс модели домена. Знаю что такое класс модели предметной области
Здравствуйте, Tom, Вы писали:
ili>>я просто втолк не возьму, это класс модели домена? Tom>Нет конечно. И я незнаю что такое класс модели домена. Знаю что такое класс модели предметной области
домен и предметная область — синонимы в данном контексте, но "домен" писать короче
так вот я не понимаю, зачем нужны обертки, почему нельзя пользоваться классами модели предметной области?...
ili>так вот я не понимаю, зачем нужны обертки, почему нельзя пользоваться классами модели предметной области?...
И я не понимаю где мне их брать, когда для данной вью их просто нет. Например когда стора возвращает агрегатЫ
Или обьекты предметной области универсальный ответ на "Ответ на главный вопрос жизни, вселенной и всего такого" (c) Дуглас Адамс ?
