Здравствуйте, gandjustas, Вы писали:
C>>Есть организации, и пользователь может работать в нескольких организациях. Организации объединены в иерархии, внутри каждой организации ещё и набор иерархических ролей. G>Ну так а сами ACL как выглядят?
Что-то типа: "разрешить запись для пользователей, имеющих через текущий вход доступ в организацию XXX, и имеющую в ней набор ролей {роли}". Причём ACLи вложенные (т.е. доступ к родителю разрешает доступ к детям), и ещё есть запретительные ACLи.
C>>Где я говорил про веб? У меня "толстый клиент" на основе WebStart. G>Ну если так — тогда еще проще. Все изменения которые происходят прогоняются через механизм разрешений, и отправляются клиентам в них нуждающимся. G>Это вообще ортогонально доступу к данным получается. И через АОР прикручивается.
Ну оно так и работает.
Остаётся только вопрос — как этот механизм реализовать?
C>>Не хватит. 800*1000 = 800000 запросов где-то в 5 секунд. Что-то многовато. Даже если оптимизировать (не запрашивать каждый раз всё), то всё равно нагрузка будет очень нехилая. G>ну с чего ты взял что 800 запросов будет. Будет один батч от одного клиента, всего максимум 200 запросов в секунду, большая часть запросов даже до БД не дойдет так как метки последнего изменения будут закешированы на сервере.
Батч внутри тоже содержит запросы. Так что всё равно будут проблемы. В общем, не думаю, что такая нагрузка по силам большинству серверов.
G>>>"Там" это где? Ты передаешь по 30 мб данных на клиентов? А что они с ними делают? C>>Смотрят. G>И что это за данные? Даже если картинки — это очень много. G>Что показывается пользователю в итоге?
Какой-то вид этих данных.
C>>Речь идёт не о табличных данных. Например, нужна способность смотреть данные по расписанию для определённого департамента для планирования события, причём для планирования нужно учитывать, чтоб не было overtime'а. Это выглядит для пользователя очень безобидно, но внутри требует перелопатить кучу данных. G>Ну так и пусть данные лопаятся средствами сервера, бд, OLAP системы, а пользователю отдается конечный результат.
Тогда вдобавок:
1) Требуется увеличить мощность сервера в сотни раз.
2) Требуются очень хорошие каналы связи.
В общем, нереально.
C>>Можно было бы вынести на сервер кое-что, но тогда многие операции выполнялись бы не мгновенно, а с многосекундной задержкой (на передачу результатов). G>Какие задержки на передачу результатов? Передать картинку размером с экран (около 200 кб) через интернет — дело десяти секунд. А реально данных для отображения будет на порядок меньше.
Реально данных гораздо больше. Гоняться-то ведь будут не картинки. Вот есть такой вид, к примеру:
Тут для каждой ячейки пару десятков килобайт надо косвенных данных (если хранить полный граф объектов, то меньше получается — часть данных вычислима на клиенте). Иначе любой щелчок мыши потребует roundtrip до сервера. Всего в таблице около тысячи строк, в каждой строке по 42 столбца. Сам умножишь?
А у меня благодаря поддержанию когерентности данных на клиентах и сервере можно делать кучу интересных вещей. Скажем, анализ типа "а что если?".
Sapienti sat!
Re[37]: Фреймфорк для разработки Веб и десктоп-приложений на
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, gandjustas, Вы писали:
G>>
G>>var q = from u in users
G>> select new {u.Name, Groups = u.Groups.Select(g => new {g.Name})};
G>>
G>>И получит только необходимые данные ровно одним запросом.
Z>EF точно так умеет? Это некислая оптимизация, дровишки проверенные?
Точно, уже год так применяю.
Z>Кстати, маппинг коллекций вроде как был считался признаком H/ORM, или без LL не считается?
Маппинг сам по себе никаким образом к H/ORM не относится.
Z>Так без LL можно и хибер настроить.
Ну это только плюс хиберу.
Z>Пример про страшный ЛЛ хорош, но помнишь, как ты рассказывал, что используешь трекинговые свойства в EF Z>только для джойнов в запросах, а в остальном у тебя абсолютно анемичная модель?
Ну да, за очень редким исплючением
Z>Так вот коллекции в хибере можно использовать точно так же.
Прекрасно, только NHibernate не был на это заточен, поэтому уши торчать будут еще очень долго.
Аналогичная история у EF, даже если к нему прикрутят DML.
Z>
Z>foreach(var user in db.Users.Select(u => new { u.Id, u.Name }))
Z>{
Z> Console.WriteLine(user.Name);
Z> foreach(var ug in db.UserToGroup().Where(ug => ug.UserId == user.Id)).Select(ug => ug.GroupId))
Z> {
Z> var group = db.Groups.Where(g => g.Id == ug.GroupId).Single();
Z> Console.WriteLine(" " + group.Name);
Z> }
Z>}
Z>
Z>Как видишь, до маразма можно довести любую технологию, я взял сугубо анемичную модель без Z>навигационных свойств, выбирал каждым запросом "только необходимый минимум данных".
Разница только в том, что твой пример — действительно маразм. А SELECT N+1 с LL случается постоянно.
Z>Итог? Программист мыслящий объектами и циклами в хибере наломает меньше дров, Z>а мыслящий реляционными понятиями и в хибере выберет все что нужно одним запросом.
Ну это если хибер позволит. Он по возможностям Linq даже до EF сильно не дотягивает на сколько я знаю.
Кстати, если не видно разницы, то зачем выбирать тормоз?
Ведь хибер гораздо медленнее и EF и BLToolkit.
Re[46]: Фреймфорк для разработки Веб и десктоп-приложений на
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Есть организации, и пользователь может работать в нескольких организациях. Организации объединены в иерархии, внутри каждой организации ещё и набор иерархических ролей. G>>Ну так а сами ACL как выглядят? C>Что-то типа: "разрешить запись для пользователей, имеющих через текущий вход доступ в организацию XXX, и имеющую в ней набор ролей {роли}". Причём ACLи вложенные (т.е. доступ к родителю разрешает доступ к детям), и ещё есть запретительные ACLи.
То есть фактически каждый пользователь имеет несколько ролей и каждый защищаемый объект имеет список ролей которым разрешен (или запрещен) доступ.
Для пользователя все роли можно вытащить и закешировать, для объектов можно тоже роли кешировать, или считать их в UDF.
Таким образом задача сводится к поиску пересечения двух множеств, что отлично ложится на запросы.
C>>>Где я говорил про веб? У меня "толстый клиент" на основе WebStart. G>>Ну если так — тогда еще проще. Все изменения которые происходят прогоняются через механизм разрешений, и отправляются клиентам в них нуждающимся. G>>Это вообще ортогонально доступу к данным получается. И через АОР прикручивается. C>Ну оно так и работает.
C>Остаётся только вопрос — как этот механизм реализовать?
Ну ты же заранее знаешь в каких сценариях будут изменяться данные, с помощью AOP перезватываешь методы и получаешь ключи изменяемых записей, ведь в параметрах метода обязательно будут эти ключи.
Собственно механиза доступа к данным тут совершенно не при чем.
C>>>Не хватит. 800*1000 = 800000 запросов где-то в 5 секунд. Что-то многовато. Даже если оптимизировать (не запрашивать каждый раз всё), то всё равно нагрузка будет очень нехилая. G>>ну с чего ты взял что 800 запросов будет. Будет один батч от одного клиента, всего максимум 200 запросов в секунду, большая часть запросов даже до БД не дойдет так как метки последнего изменения будут закешированы на сервере. C>Батч внутри тоже содержит запросы. Так что всё равно будут проблемы. В общем, не думаю, что такая нагрузка по силам большинству серверов.
Я же говорю что до базы дойдет довольно малая часть.
G>>>>"Там" это где? Ты передаешь по 30 мб данных на клиентов? А что они с ними делают? C>>>Смотрят. G>>И что это за данные? Даже если картинки — это очень много. G>>Что показывается пользователю в итоге? C>Какой-то вид этих данных.
Вот какой вид? В любом случае жти данные как-то будут отфильрованы, преобразованы и сгрупированы.
C>>>Речь идёт не о табличных данных. Например, нужна способность смотреть данные по расписанию для определённого департамента для планирования события, причём для планирования нужно учитывать, чтоб не было overtime'а. Это выглядит для пользователя очень безобидно, но внутри требует перелопатить кучу данных. G>>Ну так и пусть данные лопаятся средствами сервера, бд, OLAP системы, а пользователю отдается конечный результат. C>Тогда вдобавок: C>1) Требуется увеличить мощность сервера в сотни раз.
Нет, БД и OLAP работает гораздо эффективнее, чем любой код, который ты напишешь.
C>2) Требуются очень хорошие каналы связи.
Точно не потребуются. Так как не придется передавать на клиентов по 30 мб (тебе ведь это хотябы раз сделать надо).
C>В общем, нереально.
Очень даже реально.
C>Реально данных гораздо больше. Гоняться-то ведь будут не картинки. Вот есть такой вид, к примеру: C>[img] C>http://files.rsdn.ru/37054/problem.png C>[/img]
C>Тут для каждой ячейки пару десятков килобайт надо косвенных данных (если хранить полный граф объектов, то меньше получается — часть данных вычислима на клиенте). Иначе любой щелчок мыши потребует roundtrip до сервера. Всего в таблице около тысячи строк, в каждой строке по 42 столбца.
Сам умножишь?
Данивопрос.
Твой вариант: 1000 строк * 42 столбца * 10 кб данных = около 40 метров.
Мой вариант: 1000 строк * 42 стобца * грубо 10 байт на ячейку = 0,5 мегабайт
щелчок мыши — сбегать на сервер — около 50 мс (если там все вычислено в олапе) и, навскидку, пару килобайт данных(ведь у нас уже готовые данные к отображению)
Человек кликать будет максимум раз в 3 секунды — то есть за час 1200 раз, оклоло 2 метров данных
Итого за 8-часовой рабочий день получится накликать 16 метров, но клиентское кеширование может сократить эту сумму в несколько раз.
Реально не будут люди кликать каждые 3 секунды весь рабочий день и даже полдня...
Ну вот и посчитал.
Тут недавно Синклер рассказывал, что Outlook Web Access суммарно кушает меньше трафика, чем десктопный аутлук, который качает все себе.
При этом аутлуку не надо ничего считать, у него нету "сырых" данных в отличие от твоей задачи.
C>А у меня благодаря поддержанию когерентности данных на клиентах и сервере можно делать кучу интересных вещей. Скажем, анализ типа "а что если?".
Это ты о чем?
Re[47]: Фреймфорк для разработки Веб и десктоп-приложений на
Здравствуйте, gandjustas, Вы писали:
C>>Что-то типа: "разрешить запись для пользователей, имеющих через текущий вход доступ в организацию XXX, и имеющую в ней набор ролей {роли}". Причём ACLи вложенные (т.е. доступ к родителю разрешает доступ к детям), и ещё есть запретительные ACLи. G>То есть фактически каждый пользователь имеет несколько ролей и каждый защищаемый объект имеет список ролей которым разрешен (или запрещен) доступ.
Ну да. Только объект ещё зависит и от родительского объекта (как в ФС).
G>Для пользователя все роли можно вытащить и закешировать, для объектов можно тоже роли кешировать, или считать их в UDF.
Вот-вот. И если это делать в UDF — получается ТАКАЯ жуть. Да и тормозно.
G>Таким образом задача сводится к поиску пересечения двух множеств, что отлично ложится на запросы.
C>>Остаётся только вопрос — как этот механизм реализовать? G>Ну ты же заранее знаешь в каких сценариях будут изменяться данные, с помощью AOP перезватываешь методы и получаешь ключи изменяемых записей, ведь в параметрах метода обязательно будут эти ключи.
Несерьёзно. С помощью AOP ты можешь получить только параметры методов, а не их результат.
К примеру:
public void someMethod(Key key, int num)
{
Family family=loadFamily(key);
if (isPrime(num) && (getCurrentTime()%2)==0)
family.getFather().setGreeting("Hello");
else
family.getMother().setGreeting("world!");
}
Как мне зная ключ и номер получить id-шники изменённых объектов?
В случае с моим подходом — мне НИЧЕГО делать не надо. Вообще совсем ничего.
G>>>Что показывается пользователю в итоге? C>>Какой-то вид этих данных. G>Вот какой вид? В любом случае жти данные как-то будут отфильрованы, преобразованы и сгрупированы.
Да.
C>>1) Требуется увеличить мощность сервера в сотни раз. G>Нет, БД и OLAP работает гораздо эффективнее, чем любой код, который ты напишешь.
LOL! У меня куча алгоритмов, которые на РБД вообще нормально не ложатся без кривого императивного PL-SQL/T-SQL.
C>>2) Требуются очень хорошие каналы связи. G>Точно не потребуются. Так как не придется передавать на клиентов по 30 мб (тебе ведь это хотябы раз сделать надо).
Один раз — фигня. Приложение неделями работает. Ещё и локальный кэш прикрутить можно.
C>>Тут для каждой ячейки пару десятков килобайт надо косвенных данных (если хранить полный граф объектов, то меньше получается — часть данных вычислима на клиенте). Иначе любой щелчок мыши потребует roundtrip до сервера. Всего в таблице около тысячи строк, в каждой строке по 42 столбца. G>Сам умножишь? G>Данивопрос. G>Твой вариант: 1000 строк * 42 столбца * 10 кб данных = около 40 метров.
Угу, примерно так.
G>Мой вариант: 1000 строк * 42 стобца * грубо 10 байт на ячейку = 0,5 мегабайт G>щелчок мыши — сбегать на сервер — около 50 мс (если там все вычислено в олапе) и, навскидку, пару килобайт данных(ведь у нас уже готовые данные к отображению)
В реальности — более полусекунды, скорее ближе к секунде. Сетевая латентность только съест до 200 миллисекунд. А ещё бывают и временные перебои связи.
Потом ещё серверу надо поработать, когда тысячи пользователей его мучают.
Кроме того, у меня я могу нажать на кнопку и перейти в другой вид тех же данных: мгновенно
Я могу для любого человека посмотреть всё его расписание — мгновенно.
Я могу посмотреть личную информацию — мгновенно.
Там ещё есть несколько видов информации — и я тоже могу между ними переключаться.
Всё без всяких задержек.
C>>А у меня благодаря поддержанию когерентности данных на клиентах и сервере можно делать кучу интересных вещей. Скажем, анализ типа "а что если?". G>Это ты о чем?
О том же.
Sapienti sat!
Re[4]: Фреймфорк для разработки Веб и десктоп-приложений на
От:
Аноним
Дата:
01.10.09 16:49
Оценка:
почитал топик и ей богу не пойму как мне на вопрос ответить — а зачем тогда на SL чето мучацца писать если есть стандартные клиентские апликухи и их доставка через IIS?
По сути программирование на SL превратилось из программирования ActiveXа для страницек в написание самостоятельных приложений причем получите дополнительно тонны геморроя и кучу багов — таки зачем нам это все?
наверно стар стал иль запал пропал (сам разрабатываю уже более 10 лет приложения работающие через инет).
начинал с клиент-серверных приложений — увольте — под расстрелом меня больше не заставиш меня писать клиентские залипухи, сопровождать их, обновлять и тд. и т.п.
А навороченный интерфейс на html вы не получаете потому как мало над этим работали — у меня например наработанный фреймворк в котором формы со всякими навороченными элементами строяцца по метаописанию маленький пример здесь
После переквалификации под ASP.NET сплю спокойно — наработанные технологии, все просто и понятно и глюки уже все давно повычищены, и Вам рекомендую то же )))
ну а у кого азарата много или ради любопытства — пожалуйста- SL и WPF Вам в руки!
Re[34]: Фреймфорк для разработки Веб и десктоп-приложений на
Здравствуйте, gandjustas, Вы писали:
G>Простой пример. Есть пользователи и группы, связаны один-ко-многим. Связанные группы подгружаются с помощью LL.
G>
G>foreach(var user in users)
G>{
G> Console.WriteLine(user.Name);
G> foreach(var group in user.Groups)
G> {
G> Console.WriteLine(" " + group.Name);
G> }
G>}
G>
G>...Хотя достаточно одного джоина... G>...В случае embedded DB LL оправдан, так как чаще всего эти операции приводят к обращениям к памяти самого процесса, поэтому нет затрат на пересечение границ процессов и количество вызовов роли почти не играет.
А тебе не кажется, что проще, лучше и наглядее сделать тот самый запрос с джоином?
Такой код на любой платформе будет работать оптимально и при этом код станет компактнее и понятнее (не нужно будет разглядывать тела циклов, чтобы понять, что происходит)?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: Фреймфорк для разработки Веб и десктоп-приложений на
Здравствуйте, Аноним, Вы писали:
А>Идею понял. А>Мне кажется, что описанная проблема это ошибки дизайна, а не LL. Тоесть, вышеописанную ситуацию можно обернуть в какой нить класс, который при первом обращении к коллекции груп делают тот же самый запрос с джоином.
А класс то тут зачем? Вот налепливание классов в подобных ситуациях (и циклов, впрочем тоже) и есть ошибка дизайна. Сам же сказал "нужен джоин". Ну, так за чем дело встало?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[32]: Фреймфорк для разработки Веб и десктоп-приложений на
Здравствуйте, gandjustas, Вы писали:
VD>>Не. Лучше не создавать условий для проблем, чем обучать разработчиков тому где разложены грабли. G>Это не грабли.
Ну, ну. Разубеждать тебя не буду. Сам со временем осознаешь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[48]: Фреймфорк для разработки Веб и десктоп-приложений на
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Что-то типа: "разрешить запись для пользователей, имеющих через текущий вход доступ в организацию XXX, и имеющую в ней набор ролей {роли}". Причём ACLи вложенные (т.е. доступ к родителю разрешает доступ к детям), и ещё есть запретительные ACLи. G>>То есть фактически каждый пользователь имеет несколько ролей и каждый защищаемый объект имеет список ролей которым разрешен (или запрещен) доступ. C>Ну да. Только объект ещё зависит и от родительского объекта (как в ФС).
Без разницы, в любой момент времени можно получить эффективный ACL, те список ролей для которых разрешено или запрещено.
G>>Для пользователя все роли можно вытащить и закешировать, для объектов можно тоже роли кешировать, или считать их в UDF. C>Вот-вот. И если это делать в UDF — получается ТАКАЯ жуть. Да и тормозно.
Тянуть данные на клиент и там фильтровать будет дороже.
По хорошему эффективный acl надо кешировать, тогда появится возможность фильтровать доступ к объектам вообще без считывания их с диска.
Это будет в тыщу раз быстрее, чем читать список полных объектов в память и там фильтровать.
C>>>Остаётся только вопрос — как этот механизм реализовать? G>>Ну ты же заранее знаешь в каких сценариях будут изменяться данные, с помощью AOP перезватываешь методы и получаешь ключи изменяемых записей, ведь в параметрах метода обязательно будут эти ключи. C>Несерьёзно. С помощью AOP ты можешь получить только параметры методов, а не их результат.
Это ты не можешь, а я могу.
C>К примеру: C>
C>public void someMethod(Key key, int num)
C>{
C> Family family=loadFamily(key);
C> if (isPrime(num) && (getCurrentTime()%2)==0)
C> family.getFather().setGreeting("Hello");
C> else
C> family.getMother().setGreeting("world!");
C>}
C>
C>Как мне зная ключ и номер получить id-шники изменённых объектов?
Вот еще один недостаток жирной модели.
У меня в стройной модели все изменения данных происходят в сервисных методах, на которые я могу повесить перехватчики.
И в каждом конкретном методе я могу определить что изменяется.
C>В случае с моим подходом — мне НИЧЕГО делать не надо. Вообще совсем ничего.
С твоим — конечно.
G>>>>Что показывается пользователю в итоге? C>>>Какой-то вид этих данных. G>>Вот какой вид? В любом случае жти данные как-то будут отфильрованы, преобразованы и сгрупированы. C>Да.
И зачем тогда их все тянуть на клиента?
C>>>1) Требуется увеличить мощность сервера в сотни раз. G>>Нет, БД и OLAP работает гораздо эффективнее, чем любой код, который ты напишешь. C>LOL! У меня куча алгоритмов, которые на РБД вообще нормально не ложатся без кривого императивного PL-SQL/T-SQL.
Ну с ACL уже разобрались — вполне ложится на SQL.
Можем еще что-нибудь разобрать, не сомневаюсь что тоже окажется нормально ложащимся на SQL.
Даже если тебе действительно нужен ипмеративный код, то используй его на здровье и кешируй результат.
SQL запрос гораздо эффективнне всего что ты можешь написать просто потому что тебе может не потребоваться даже поднимать данные с диска и тем более не передавать их на клиентскую часть.
Ведь передавая 30 мб на клиента ты фактически этот объем гоняешь по сети два раза. Один раз от базы на сервер, потом второй раз — клиенту.
C>>>2) Требуются очень хорошие каналы связи. G>>Точно не потребуются. Так как не придется передавать на клиентов по 30 мб (тебе ведь это хотябы раз сделать надо). C>Один раз — фигня. Приложение неделями работает. Ещё и локальный кэш прикрутить можно.
Ну так локальный кеш всегда прикрутить можно. В том числе для низкогранулярных запросов.
Причем для последних работать эффективнее будет.
А вот насчет десткоп-приложения неделями — сильно сомневаюсь.
C>>>Тут для каждой ячейки пару десятков килобайт надо косвенных данных (если хранить полный граф объектов, то меньше получается — часть данных вычислима на клиенте). Иначе любой щелчок мыши потребует roundtrip до сервера. Всего в таблице около тысячи строк, в каждой строке по 42 столбца. G>>Сам умножишь? G>>Данивопрос. G>>Твой вариант: 1000 строк * 42 столбца * 10 кб данных = около 40 метров. C>Угу, примерно так.
G>>Мой вариант: 1000 строк * 42 стобца * грубо 10 байт на ячейку = 0,5 мегабайт G>>щелчок мыши — сбегать на сервер — около 50 мс (если там все вычислено в олапе) и, навскидку, пару килобайт данных(ведь у нас уже готовые данные к отображению) C>В реальности — более полусекунды, скорее ближе к секунде. Сетевая латентность только съест до 200 миллисекунд. А ещё бывают и временные перебои связи.
А что так долго? У меня на сайтах картинки отдаются за 100 мс, вместе с латентностями.
C>Потом ещё серверу надо поработать, когда тысячи пользователей его мучают.
HTTP + Клиентское кеширование + Кеширование ответов на resverse proxy + кеширование данных на сервере и тыща пользователей вполне проживут.
Кроме того решение на HTTP будет неограниченно масштабироваться.
C>Кроме того, у меня я могу нажать на кнопку и перейти в другой вид тех же данных: C> C>мгновенно C>Я могу для любого человека посмотреть всё его расписание — мгновенно. C>Я могу посмотреть личную информацию — мгновенно. C>Там ещё есть несколько видов информации — и я тоже могу между ними переключаться. C>Всё без всяких задержек.
Только сначала надо выкачать 30 мб инфы, по моему GPRSу это будет часа 4. А мне бы увидеть хоть что-нибудь, хотябы в течение минуты.
А закешировав на клиенте нужные данные тоже все будет происходить мгновенно, только первый раз с лагом максимум в пару секунд (или десяток на GPRS).
Re[37]: Фреймфорк для разработки Веб и десктоп-приложений на
G>>var q = from u in users
G>> select new {u.Name, Groups = u.Groups.Select(g => new {g.Name})};
G>>
G>>И получит только необходимые данные ровно одним запросом.
Z>EF точно так умеет? Это некислая оптимизация, дровишки проверенные?
Блин, ёлы-палы. Так может любой LINQ-профайдер в том числе Linq2Sql, EF и BLToolkit.
Z>Кстати, маппинг коллекций вроде как был считался признаком H/ORM, или без LL не считается?
Как раз L/ORM — это те ORM которые умеют делать только его и еще запросы.
Z>только для джойнов в запросах, а в остальном у тебя абсолютно анемичная модель? Так вот коллекции в хибере можно использовать точно так же.
Ага, если бы не одно. Но гибернэйт заточен под возюканье с объектами из-за чего там сплошь и рядом кэширование. Кэширование дублирует задачи СУБД, причем решает их во много раз хуже, и в результате тормоза и гимор.
Z>Страшные сказки, что глупые программисты сразу понапишут кучу вложенных циклов по коллекциям можно уже не Z>повторять, такие программисты и на линке повтыкают ToList() и те же грабли ударят не хуже.
На линке они сначала напишут запрос, так как у них не будет возможности втянуть все через свойства.
Z>
Z>foreach(var user in db.Users.Select(u => new { u.Id, u.Name }))
Z>{
Z> Console.WriteLine(user.Name);
Z> foreach(var ug in db.UserToGroup().Where(ug => ug.UserId == user.Id)).Select(ug => ug.GroupId))
Z> {
Z> var group = db.Groups.Where(g => g.Id == ug.GroupId).Single();
Z> Console.WriteLine(" " + group.Name);
Z> }
Z>}
Z>
Ну, от идиота есть только один способо застраховаться — не брать его на работу.
Z>Как видишь, до маразма можно довести любую технологию, я взял сугубо анемичную модель без Z>навигационных свойств, выбирал каждым запросом "только необходимый минимум данных". Z>Итог? Программист мыслящий объектами и циклами в хибере наломает меньше дров, Z>а мыслящий реляционными понятиями и в хибере выберет все что нужно одним запросом.
Ну, а зачем же проламываться сквозь объекты чтобы понять как этот гичер там себе эти объекты в реляцию превращает? Не проще ли когда и система и программист говорят на одном языке?
Маразм ведь получается! Мы сначала скрываем от программиста тот факт, что данные то у нас реляционные, а потом этот программист вынужден догадываться о том как же его обманывают и подстраивать все так, чтобы все заработало.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[49]: Фреймфорк для разработки Веб и десктоп-приложений на
Здравствуйте, gandjustas, Вы писали:
C>>Ну да. Только объект ещё зависит и от родительского объекта (как в ФС). G>Без разницы, в любой момент времени можно получить эффективный ACL, те список ролей для которых разрешено или запрещено.
Можно. Но в UDF это делается уродливо. Проходили уже, первая версия ровно так и работала — делался row-level security в Оракульной БД.
Оно в итоге под своим весом всё упало.
C>>Вот-вот. И если это делать в UDF — получается ТАКАЯ жуть. Да и тормозно. G>Тянуть данные на клиент и там фильтровать будет дороже.
На клиенте данные не фильтруются (я идиот, что ли?)
G>По хорошему эффективный acl надо кешировать, тогда появится возможность фильтровать доступ к объектам вообще без считывания их с диска. G>Это будет в тыщу раз быстрее, чем читать список полных объектов в память и там фильтровать.
Ага, так и делается. Но для деталей реализации требуется знать именно объектную модель.
C>>Как мне зная ключ и номер получить id-шники изменённых объектов? G> G>Вот еще один недостаток жирной модели. G>У меня в стройной модели все изменения данных происходят в сервисных методах, на которые я могу повесить перехватчики. G>И в каждом конкретном методе я могу определить что изменяется.
О, так у нас уже всё через определённый слой идёт? И никаких массовых update'ов нет?
Так поздравляю, ты почти написал H/ORM! Ещё чуть-чуть, и оно будет готово.
C>>Да. G>И зачем тогда их все тянуть на клиента?
А то, что ты можешь часть фильтрации делать на клиенте. Скажем, поиск по словам в таблице.
G>>>Нет, БД и OLAP работает гораздо эффективнее, чем любой код, который ты напишешь. C>>LOL! У меня куча алгоритмов, которые на РБД вообще нормально не ложатся без кривого императивного PL-SQL/T-SQL. G>Ну с ACL уже разобрались — вполне ложится на SQL.
Не ложится.
G>Можем еще что-нибудь разобрать, не сомневаюсь что тоже окажется нормально ложащимся на SQL.
Спорим?
G>Даже если тебе действительно нужен ипмеративный код, то используй его на здровье и кешируй результат.
И следить за когерентностью кэша.
G>SQL запрос гораздо эффективнне всего что ты можешь написать просто потому что тебе может не потребоваться даже поднимать данные с диска и тем более не передавать их на клиентскую часть. G>Ведь передавая 30 мб на клиента ты фактически этот объем гоняешь по сети два раза. Один раз от базы на сервер, потом второй раз — клиенту.
Передаваемые данные кэшируются в виде готового к передаче массива байт или списка готовых для финальной фильтрации объектов.
C>>Один раз — фигня. Приложение неделями работает. Ещё и локальный кэш прикрутить можно. G>Ну так локальный кеш всегда прикрутить можно. В том числе для низкогранулярных запросов. G>Причем для последних работать эффективнее будет.
Проблема с их _обновлением_.
G>А вот насчет десткоп-приложения неделями — сильно сомневаюсь.
Запросто.
C>>В реальности — более полусекунды, скорее ближе к секунде. Сетевая латентность только съест до 200 миллисекунд. А ещё бывают и временные перебои связи. G>А что так долго? У меня на сайтах картинки отдаются за 100 мс, вместе с латентностями.
Это с учётом HTTP pipelining и хороших каналов. В США из LA до нашего сервера в TX именно такая латентность бывает на забитых каналах пользователей.
C>>Потом ещё серверу надо поработать, когда тысячи пользователей его мучают. G>HTTP + Клиентское кеширование + Кеширование ответов на resverse proxy + кеширование данных на сервере и тыща пользователей вполне проживут. G>Кроме того решение на HTTP будет неограниченно масштабироваться.
А кто будет фильтровать результаты для каждого пользователя? Видимо, reverse proxy?
C>>Там ещё есть несколько видов информации — и я тоже могу между ними переключаться. C>>Всё без всяких задержек. G>Только сначала надо выкачать 30 мб инфы, по моему GPRSу это будет часа 4. А мне бы увидеть хоть что-нибудь, хотябы в течение минуты. G>А закешировав на клиенте нужные данные тоже все будет происходить мгновенно, только первый раз с лагом максимум в пару секунд (или десяток на GPRS).
Реально передаётся около 5Мб, остальная информация довычисляется на клиенте.
Sapienti sat!
Re[5]: Фреймфорк для разработки Веб и десктоп-приложений на
Здравствуйте, <Аноним>, Вы писали:
А>почитал топик и ей богу не пойму как мне на вопрос ответить — а зачем тогда на SL чето мучацца писать если есть стандартные клиентские апликухи и их доставка через IIS? А>По сути программирование на SL превратилось из программирования ActiveXа для страницек в написание самостоятельных приложений причем получите дополнительно тонны геморроя и кучу багов — таки зачем нам это все?
Ну выше yorick назвал главную причину: современный WEB2 ето букет из технологий и языков программирования, помноженный на количество версий/спецификаций/стандартов + особенности реализаций броузеров. Во всем етом надо шарить, изучать приемы / подходы / рецепты / инструменты — вообщем нудно и так сразу не поедешь, возникает естественное желание чиста взять спортивный супер-кар от Microsoft в лице Silverlight-а и ай-да педаль газа под коврик Тока пока на проверку оказывается суперкар по песку не едет, кондиционер работает в одном режиме да и вообще как долго и куда на нем приедешь решает сама Microsoft А так в принципе покататься рекомендую — ето местами захватывающе и действительно на SL можно делать такие вещи, что waauuuu
Re[38]: Фреймфорк для разработки Веб и десктоп-приложений на
Здравствуйте, VladD2, Вы писали:
VD>Ну, а зачем же проламываться сквозь объекты чтобы понять как этот гичер там себе эти объекты в реляцию превращает? Не проще ли когда и система и программист говорят на одном языке?
VD>Маразм ведь получается! Мы сначала скрываем от программиста тот факт, что данные то у нас реляционные, а потом этот программист вынужден догадываться о том как же его обманывают и подстраивать все так, чтобы все заработало.
Я рассматриваю построение модели не как способ сокрытия реляционности, а как способ создать удобный ДСЛ для запросов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[35]: Фреймфорк для разработки Веб и десктоп-приложений на
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gandjustas, Вы писали:
G>>Простой пример. Есть пользователи и группы, связаны один-ко-многим. Связанные группы подгружаются с помощью LL.
G>>
G>>foreach(var user in users)
G>>{
G>> Console.WriteLine(user.Name);
G>> foreach(var group in user.Groups)
G>> {
G>> Console.WriteLine(" " + group.Name);
G>> }
G>>}
G>>
G>>...Хотя достаточно одного джоина... G>>...В случае embedded DB LL оправдан, так как чаще всего эти операции приводят к обращениям к памяти самого процесса, поэтому нет затрат на пересечение границ процессов и количество вызовов роли почти не играет.
VD>А тебе не кажется, что проще, лучше и наглядее сделать тот самый запрос с джоином? VD>Такой код на любой платформе будет работать оптимально и при этом код станет компактнее и понятнее (не нужно будет разглядывать тела циклов, чтобы понять, что происходит)?
Не понял, что именно сделать джоином?
Re[50]: Фреймфорк для разработки Веб и десктоп-приложений на
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Ну да. Только объект ещё зависит и от родительского объекта (как в ФС). G>>Без разницы, в любой момент времени можно получить эффективный ACL, те список ролей для которых разрешено или запрещено. C>Можно. Но в UDF это делается уродливо. Проходили уже, первая версия ровно так и работала — делался row-level security в Оракульной БД. C>Оно в итоге под своим весом всё упало.
Я же и говорю — кешировать надо.
C>>>Вот-вот. И если это делать в UDF — получается ТАКАЯ жуть. Да и тормозно. G>>Тянуть данные на клиент и там фильтровать будет дороже. C>На клиенте данные не фильтруются (я идиот, что ли?)
А где фильтруются? Ты же говорил что обработка не ложится на SQL...
Или я что-то не так понял.
C>>>Как мне зная ключ и номер получить id-шники изменённых объектов? G>> G>>Вот еще один недостаток жирной модели. G>>У меня в стройной модели все изменения данных происходят в сервисных методах, на которые я могу повесить перехватчики. G>>И в каждом конкретном методе я могу определить что изменяется. C>О, так у нас уже всё через определённый слой идёт? И никаких массовых update'ов нет?
Если есть массовые апдейты, то вмето конкретного ключа можно получить предикат на выборку нужных записей.
Но я сейчас EF использую, у него с массовыми операциям совсем плохо.
C>Так поздравляю, ты почти написал H/ORM! Ещё чуть-чуть, и оно будет готово. Ну если пара сотен строк кода для реализации такого функционала — H/ORM, то да, я написал H/ORM
как раз подобным образом делал отправку сообщений аудита.
C>>>Да. G>>И зачем тогда их все тянуть на клиента? C>А то, что ты можешь часть фильтрации делать на клиенте. Скажем, поиск по словам в таблице.
По каким словам, в какой таблице?
G>>>>Нет, БД и OLAP работает гораздо эффективнее, чем любой код, который ты напишешь. C>>>LOL! У меня куча алгоритмов, которые на РБД вообще нормально не ложатся без кривого императивного PL-SQL/T-SQL. G>>Ну с ACL уже разобрались — вполне ложится на SQL. C>Не ложится.
Ну покажи где?
Я так понимаю что стоит создать в базе списски эффективных ACL и эффективных ролей для пользователя (например на триггерах). Тогда можно фильтровать записи на севрере прямо в запросе, без вытягивания acl из базы.
G>>Можем еще что-нибудь разобрать, не сомневаюсь что тоже окажется нормально ложащимся на SQL. C>Спорим?
ну давай.
G>>Даже если тебе действительно нужен ипмеративный код, то используй его на здровье и кешируй результат. C>И следить за когерентностью кэша.
За ним не нужно следить, кеши обновляется при изменении данных.
Обычно соотношение выборок и изменений около 95% и 5%, поэтому вполне возможно запускать какой-то код с дополнительными вычислениями при изменнении данных.
C>>>Один раз — фигня. Приложение неделями работает. Ещё и локальный кэш прикрутить можно. G>>Ну так локальный кеш всегда прикрутить можно. В том числе для низкогранулярных запросов. G>>Причем для последних работать эффективнее будет. C>Проблема с их _обновлением_.
Никаких проблем. last modified отлично работает.
C>>>Потом ещё серверу надо поработать, когда тысячи пользователей его мучают. G>>HTTP + Клиентское кеширование + Кеширование ответов на resverse proxy + кеширование данных на сервере и тыща пользователей вполне проживут. G>>Кроме того решение на HTTP будет неограниченно масштабироваться. C>А кто будет фильтровать результаты для каждого пользователя? Видимо, reverse proxy?
В этом случае reverse proxy не поможет. Кеш на клиенте все равно работать будет.
Re[38]: Фреймфорк для разработки Веб и десктоп-приложений на
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Ziaw, Вы писали:
G>>>
G>>>var q = from u in users
G>>> select new {u.Name, Groups = u.Groups.Select(g => new {g.Name})};
G>>>
G>>>И получит только необходимые данные ровно одним запросом. Z>>EF точно так умеет? Это некислая оптимизация, дровишки проверенные? VD>Блин, ёлы-палы. Так может любой LINQ-профайдер в том числе Linq2Sql, EF и BLToolkit.
Linq2SQL так не умеет вроде.
Re[39]: Фреймфорк для разработки Веб и десктоп-приложений на
