Фреймфорк для разработки Веб и десктоп-приложений на .NET - .NET

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

А>Вот я с 5 класса писал программы на паскале, потом Си потом... чего там только не было. С ростом сложности програм меня всегда мучала мысль — как написать красивое и масштабируемое приложение. Думаю грабли у всех одни и те же: процедуры/функции, затем ООП, затем патерны. Вдруг я понял что сценарий транзакции или шлюз таблицы хорош только в примитивных приложениях (ИМХО!!!).

Не примитивные приложения, а приложения с примитивным состоянием, т.е. без него.

А>На сегодняшний день я не нашел более действенного метода нежели Domain Driven Design. Поэтому диктат тут не орээмами а методологией.

Безусловно DDD где-то рулит, а где-то рулит не очень, где-то не рулит совсем. Поэтому, одной методологией ограничиваться не разумно. Любая методология — это всего лишь на всего инструмент, такой же как паттерны, языки, библиотеки, ORM и т.п. Даже ООП можно рассматривать как всего лишь набор паттернов. А раз это инструмент, то место ему в коробке с другими инструментами, а не в углу в иконе. Подходит в каком-то случае лучше DDD — берём DDD, подходит Singleton — берём Singleton. Единственное требование к инструменту — это чтобы он, решая мои определённые проблемы, не создавал других в количестве, превышающем полезный выхлоп от его применения. Подход H/ORM, в котором всё уже как бы сделано и смешано в одном флаконе, для меня такие проблемы создаёт. Сделано то оно сделано, только не всегда хорошо и не всегда под мои нужды.

А>Скажи пожалуйста — какой фундамент у твоих разработок? Строишь ли десктоповые приложения?

Не совсем понял насчёт фундамента. По поводу десктопов — да, всего хватает: веб, процессинг, сервисы, десктоп в том числе. Но судя по упомянутому тобой DDD, речь скорее должна идти не конкретно о десктопах, а о приложениях, интенсивно работающих с собственным состоянием. Таким приложением может быть не только десктоп, а практически всё. Даже в вебе встречаются навороченные формы с развесистым состоянием и народ до сих пор мечется в поисках истины между AJAX, распределённым состоянием типа ViewState в ASP.NET и сильверлайтами. В результате удивляясь почему у них плохо работает и то и другое и третье.

А ответ прост — выбирать технологию нужно не для приложения в целом, а для каждой отдельной подзадачи из соображений обработки состояния в этой подзадаче. И всё сразу становится на свои места. Для страниц, не требующих интеррактива с пользователем характерны прямые запросы к базе, часто хитровыгнутые и с ad-hoc результатом. Запросил, нарисовал, забыл. Какое здесь может быть состояние? Зачем тут DDD? Зачем тяжелые ORM и прочие пляски вокруг объектных моделей? Зачем AJAX и сильверлайт? Для навороченных форм ввода без AJAX и сильверлайтов, наоборот, обойтись можно, но сложно, т.к. приходится работать с распределённым между клиентом и сервером состоянием. Здесь, безусловно, рулят объектные модели.

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

В общем, задачи нужно делить не на web и desktop, а по типу работы с состоянием. А это можно условно разделить следующим образом:

1. Отсутствие состояния.
2. Простое состояние, которое практически соответствует модели данных приложения.
3. Сложное состояние.

С первым типом всё понятно — обычная stateless модель. Cyberax такие задачи называет примитивными

LW/ORM для таких задач самое оно. H/ORM явно тяжеловата.

Со вторым тоже не сложно. Прямой маппинг модели данных в объектную модель и дальнейшая несложная работа с этой моделью — это то, на что H/ORM затачивается годами. У LW/ORM с маппингом тоже всё в порядке, определённые сложности имеются в части трекинга и сохранения изменений, но эти вещи с успехом можно решать независимо и/или другими способами.

С третьим типом тоже вроде всё без проблем. H/ORM тут только мешаются, а LW/ORM без разницы где рулить. Чтобы пояснить что я понимаю под этим типом состояния приведу в качестве примера одно из моих desktop приложений. В нём для хранения данных использовалась всего пара таблиц плюс справочники, а объектная модель представляла собой развесистую иерархическую структуру с трекингом и распространением изменения любого узла модели по всей модели. Главной проблемой была оптимизация распространения изменений. Т.к. всё это отображалось в гриде, то любая неоптимальность приводила к каскаду уведомлений и всё начинало жутко тормозить. А вот операции работы с базой сводились всего лишь к Load и Save, ну и подгрузка справочников.

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

Движение в сторону stateless модели приводит к утяжелению всего приложения, вместо хитровыгнутых и ad-hoc запросов, с которым лучше чем SQL сервер всё равно никто не справится, начинается полная или частичная загрузка объектной модели, что приводит к тормозам и неоправданному использованию ресурсов.

Но всё ещё хуже если движение идёт в сторону усложнения состояния. В этом случае H/ORM начинает тащить за собой и подгонять под состояние не только объектную модель приложения, но ещё и модель данных, т.к. по другому она не может (точнее может, но в строго ограниченных пределах). Отсюда у нас, кстати, возникают дурацкие требования к поддержке базой данных нереляционной ереси вроде наследования и иерархий. Вторая часть H/ORM — объектная модель тоже становится тормозом и проблемой, т.к. задачи в таких приложениях выходят за рамки просто оттрекал изменения и сохранил изменения. Гибкость объектной модели в таких приложениях — это всё, но гибкость эта ограничена H/ORM. В результате мы получаем приложение с переусложнённым дизайном БД и жёстко прибитой к ней негибкой объектной моделью.

А что же LW/ORM? А LW/ORM, как я уже сказал, без разницы где рулить. Она занимается только тем, что умеет делать хорошо и не вносит в дизайн приложения никаких искусственных ограничений. Единственная проблема — уровень подготовки разработчиков.

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

КО>Как фронтенд, я бы однозначно рекомендовал Silverlight 3 (www.silverlight.net) и WPF.
Вот такие интересности ждут Вас при выборе Silverlight-a в качестве базовой технологии для front-end-а enterprise level приложения (back-office-а и т.д.):

— работать с ним из VS2008 мягко говоря неудобно. Мало того что дизайнер примитивный (и если пользуетесь Expression Blend, то ето переодическое переключение окон тормозит и достает), так он еще и откровенно глючит, а не дай бог подключить сторонние Silverlight контролы — напрочь отказывается что либо вырисовывать. Ну и из-за специфики XAML иногда ето просто невозможно. Например, для безразмерного контрола значения Width и Height опускаются (в Expression Blend есть спец. аттрибуты DesignWidth и DesignHeight, которые есс-но игнорируются VS). Другими словами забейте на удобства и пишите XAML ручками.

— отладка. Вообщем-то очевидно — пока не скомпилишь — не запустишь. Забудьте про изменения "на лету", как в ASP.NET. Мелочь? Ето здорово кушает время — скомпилил, запустил, проверил, нашел ошибку, остановил, пофиксил, скомпилил, запустил...и т.д. по кругу. А как иначе проверить как выглядит твое творение? (помним про предыдущий пункт — дизайнер ничего не показывает, а XAML пишем руками — надо же посмотреть что из етого получилось

) К тому же в Silverlight-е есть ряд забавных конвенций — например Binding ошибки не считаются ошибками, и обнаружить их можно только тестируя приложение и тупо мониторя Output окошко

— контролы контролы контролы... Стандартных не хватает. Сторонние — глючат!!! Работал с Telerik, DevExpress — просто не верится, что такие уважаемые компании выкидывают на рынок такое <здесь нехорошее слово>. Впечатление удручающее, когда приложение падает на ровном месте с кодом, взятым из примера Demo. Или просто контрол не перерисовывается в окне. Сделали броузеру minimize/maximize, а на месте контрола пустое место

Здесь нужно вооружиться терпением и ждать пока пофиксят. Из бесплатных — Silverlight Toolkit — нареканий нет. Но вообщем-то выбор не большой. Пока. Наверно надо подождать...

— библиотеки. Иногда ето больно

Потому как после WPF кажется, что Silverlight ето ампутированный обрезанный поделок. Спотыкаешься буквально на каждой мелочи. До чертиков читать форумы, что етой-де фишки пока в Silverlight нету, но вот вам пожалуйста почти такой же работающий лисапедик. Чего только стоит эмуляция дабл клика мыши

Ну и вот другие мелочи:
— нет XML/XSLT (есть Linq To Xml — пользуйтесь)
— проблемно с линками (открытие интернет ресурса в текущем или новом окне — ето придется продумавать SL программисту) и URL mapping-ом (SL3 предлагает solution, правда примитивный но какой никакой)
— проблемно с экспортом данных вообще
Никогда не задумывались насколько удобна HTML страничка?
А вот настолько:
+ Copy/Paste любого контента в любое приложение — без проблем, с сохранением стилей или без
+ Сохранить на диск — в виде HTML, TXT, MHT (веб архив, со всеми картинками) — без проблем
+ Export таблиц — прямо в Excel (из IE, если установлен Office)
Пользователю надо комфортно работать с данными. Что предлагает Silverlight? CTRL-C в SL работает только в текст-боксах...

Делать screenshot-ы?

Можно ли как-то подружить SL с HTML? да, как-то. Ето стоит лишних усилий и постоянных напрягов фантазии. Вообщем не скучно. А посмотрите насколько уродлив HTML контрол для SL от Telerik

Ну и в конце концов не забываем, что Silverlight — client-side приложение.
Любой unhandled exception приводит к crash-у всего приложения.
Там где для html-я надо просто нажать F5, в SL ето тот же F5 только с перезагрузкой всей аппликухи.
А интеграция с серверными решениями (тот же reporting) ето как правило геморрой тот еще.

Вообщем я для себя сделал выводы насчет пригодности SL для написания бизнес приложений. ASP.NET (или любой другой web framework) + c элементами SL = да.
SL как базовый framework — никогда, по крайней мере пока сильные форума сего не рассеют мои невеселые впечатления своими рецептами правильного приготовления современного web приложения на основе технологии Silverlight

... << RSDN@Home 1.2.0 alpha 4 rev. 1238>>

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

C>>Нет, это примерно такое же по глупости выражение. Немерль ты выбираешь вовсе не из-за того, что он быстрее С.
VD>Я его выбираю потому, что он сравним с С по скорости и сильно превосходит его по выразительности и удобству.
VD>А вот за что выбираю Гибирнэйт? Он ведь по скорости сильно уступает булкиту, и при этом еще и отстает от него по выразительности.

По выразительности Булкиту до настоящего ORM — как до Луны. Как появится lazy loading и автодетект изменений, тогда посмотрим.

VD>>>Но вот на фиг гибернэйт нужен для людей у которых присутствует интеллект я понять не могу.
C>>Ты просто не умеешь им пользоваться. Или делаешь такие приложения, где пофиг чем пользоваться.
VD>Ну, или ты не умеешь пользоваться альтернативами вроде линка и булкита.
Умею. Но у меня просто не стандартное веб приложение — у меня изменения графа объектов с сервера реплицируются на клиенты. Причём каждый клиент имеет свой собственный вид графа, с учётом ACL и некоторых настроек.

Нормальный ООП для данных, с поддержкой ссылок, у меня получился просто незаменим.

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

А>В чём принципиальная разница в использовании BLToolkit, NHibernete и FE?

BLToolkit — это lightweight ORM. NH и FE — heavy ORM.

Принципиальная разница между LW/ORM и H/ORM в том, что задача первых облегчить работу с реляционными данными, а вторых — заменить работу с реляционными данными на работу с объектной моделью. Из этого вытекают как достоинства, так и недостатки обоих подходов.

Главный недостаток LW/ORM в том, что он требует от праграммиста навыков работы с реляционными данными. Т.е. проблемы LW/ORM — это прежде всего проблемы квалификации программиста. Если же программист обладает всеми необходимыми навыками, то близость к БД плавно переходит из разряда недостатков в главное достоинство и LW/ORM становится практически идеальным решением. Это, кстати, хорошо заметно по нашему форуму. Как правило те, кто является экспертами в БД, рьяно защищают LW/ORM и люто ненавидят H/ORM.

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

Но выбор остаётся, естественно, за программистом. Если вы не очень уверенно чувствуете себя в работе с реляционными данными, то, возможно, H/ORM будет лучшим выбором. А со временем, подкачав навыки работы с БД, можно будет перейти на LW/ORM.

Так же следует отметить, что бытует мнение, будто H/ORM лучше подходят для больших и сложных задач, а LW/ORM для маленьких и простых. Это заблуждение.

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

КО>>Как фронтенд, я бы однозначно рекомендовал Silverlight 3 (www.silverlight.net) и WPF.
SHE>Вот такие интересности ждут Вас при выборе Silverlight-a в качестве базовой технологии для front-end-а enterprise level приложения (back-office-а и т.д.):

А я скажу пару слов в защиту.

SHE>- работать с ним из VS2008 мягко говоря неудобно... Другими словами забейте на удобства и пишите XAML ручками.

Верно. Но можно подумать в asp.net что-то иначе... На практике достаточно навороченую форму с табами, визардом и прочим в дизайнере тоже хрен откроешь.
Короче, ситуация абсолютно одинаековая: на более-менее простых формах всё Ок, на сложных — и там и там грабли.

SHE>- отладка. Вообщем-то очевидно — пока не скомпилишь — не запустишь. Забудьте про изменения "на лету", как в ASP.NET. Мелочь? Ето здорово кушает время — скомпилил, запустил, проверил, нашел ошибку, остановил, пофиксил, скомпилил, запустил...и т.д. по кругу.

Да ну, это не серьёзно. Разметка занимает дай бог процентов десять времени. И я реально забыл уже когда мне хотелось бы делать это в дизайнере.

SHE> К тому же в Silverlight-е есть ряд забавных конвенций — например Binding ошибки не считаются ошибками, и обнаружить их можно только тестируя приложение и тупо мониторя Output окошко

Есть более прогрессивные методы

http://bea.stollnitz.com/blog/?p=52

SHE>Чего только стоит эмуляция дабл клика мыши

Господи, да там один раз на всю жизнь за час пишется экстеншн... Ну еще по часу на правую кнопку и колёсико.

SHE>Пользователю надо комфортно работать с данными. Что предлагает Silverlight? CTRL-C в SL работает только в текст-боксах...
Идея через буфер себе странички сохранять достаточно странная. Нафига тогда вообще огород городить, если пользователю "комфортно работать с данными" не через ваш инструмент, а сохраняя страницу(куда?)?

SHE>проблемно с линками (открытие интернет ресурса в текущем или новом окне — ето придется продумавать SL программисту)
Вы чего, издеваетесь? HtmlPage.Window.Navigate(url, target) — хоть в новом, хоть в текущем... Может это в консерватории что-то не так?

Короче, всё совсем не так страшно, как вы это описываете. Тем более, что основная масса притензий вообще непонятно к чему: SL плохой, надо double-click допиливать, а html хороший, там... А как там этого достичь? Хаками js, попутно обходя грабельки особенностей разных броузеров?

Для меня лично есть одно достоинство SL, котрое перевешивает все недостатки. Я ПИШУ НА ОДНОМ ЯЗЫКЕ.
Как пишутся морды на ASP.net? Тут html, здесь — js, тут — dhtml, тут css, еще какая-то хрень... Блин, да на каком языке мы пишем?

" ASP.NET (или любой другой web framework)"? Это же html, шаг в право — шаг в лево: расстрел. Сделать дропдаун с чем-то кроме текста? Вот вам бубен. Надо карту/графики? Ой, это лучше вообще на чём-нибуть другом. Драг-энд-дроп? Тут где-то фреймфорк на js был... Многооконный интерфейс? Ну вы поняли

Сейчас потихоньку переводим проект с asp.net на sl — клиенты довольны. Оно и реально(хотя бы потому, что навороченые контролы со справочниками можно затянуть один раз вместо того, что-бы тащить их на каждый чих) и субьективно(проще в начале пододжать хоть минуту чем потом ждать двадцать раз по три секунды) начинает быстрее работать, да и пишется всё гораздо быстрее.
Каких контролов вам не хватает? Нас полностью удовлетворяет Silverlight Toolkit(это вроде как стандартный набор), ну DevExpress(он бесплатный пока) еще иногда.

В общем у нас идут в основном холивары между флешерами и sl, приверженцев asp.net+js как-то не осталось

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

C>PetShop совершенно неинтересен. Это банальное классическое веб-приложение.

Кто бы сомневался

C>Ты лучше попробуй сделать так, чтобы изменения, которые ты делаешь с помощью Булкита, записывались в отдельную базу для аудита, а потом рассылались клиентам (с учётом ACL, невыразимых на уровне стандартных средств БД).

Задача аудита совершенно ортогональна тому, чем должен заниматься ORM tool. И реализуется она в приложения с прямой архитектурой с помощью вызова одного метода на операцию в нужном месте, вроде:

public void Audit(string operation, string comment);

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

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

VD>Здравствуйте, oleg.agafonov, Вы писали:

OA>>Хотелось бы более детальной информации об рисках, связанных с использованием NHibernate в таком проекте как rsdn.

VD>У нас просто не хватит денег на железо. На РСДН используется только прямая работа с SQL и BL-Toolkit.
VD>NHibernate-у к ним и на пушечный выстрел не подойти.
Господа, теперь я понял почему вы так хвалите свое боло... ой BL-Toolkit. Без обид, но как минимум не скромно хаять темы пришедшие из ява. Генерики тоже из ява пришли

Или может Мартин Фаулер по вашему необразован?
гыг, что еще сказать

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

VD>>Серьезно? И чем же они помогают?

А>Тебе ничем. Коси траву в противогазе ибо так труднее. )))

Очень похоже на слив. В принципе, можно засчитать.

А>Юзайте, дети мои, то что вашей душе угодно.

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

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

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

А>>>А можно просветить почему lazy load "препоганейший"??
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>>Хотя достаточно одного джоина.

О>Просто справедливости ради замечу, что проблема здесь вовсе не в самом LL, а в том как он используется.
Грубо говоря проблема чаще всего в том, что используется LL.
очень мало ты сможешь найти примеров где LL оправдан хоть немного.

О>При желании можно заставить тот же Hiberante загрузить пользователя с его группами как раз за один селект c джойном, хотя есть и другие достаточно эффективные способы загрузки коллекций.
О>Вот например (Join fetching): http://docs.jboss.org/hibernate/core/3.3/reference/en/html/performance.html#performance-fetching
Если есть проблема SELECT N+1 — как описана в примере — то лечится она только загрузкой сущности со связанными.

А современные фреймворки позволяют вообще написаnь так:

var q = from u in users
        select new {u.Name, Groups = u.Groups.Select(g => new {g.Name})};
foreach(var user in q)
{
    Console.WriteLine(user.Name);
    foreach(var group in user.Groups)
    {
        Console.WriteLine("    " + group.Name);
    }
}

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

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

SHE>но ничего по делу
Могу еще раз пройтись по пунктам, если есть желание.

SHE>Мало того что дизайнер примитивный (и если пользуетесь Expression Blend, то ето переодическое переключение окон тормозит и достает), так он еще и откровенно глючит
Это да. Expression Blend — полное Г, тормозит, глючит, плюс идиотский размытый WPF интерфейс в могильной теме, которая режет глаз. Плюс к этому интерфейс интуитивно непонятный, что бы найти что-то надо перерыть полмануала. В конце-концов я заметил, что я стал больше полагаться на автокомплит (который тоже сделан через задницу) и подумал — а нафига мне этот бленд?
С тех пор пишу ручками и радуюсь. Впрочем точно такая же ситуация и с html — пишем ручками, если нужен хороший результат. HTML — XAML 0:0

SHE>Забудьте про изменения "на лету", как в ASP.NET. Мелочь?
Мелочь, конечно, но неприятно. Согласен.

SHE>- контролы контролы контролы... Стандартных не хватает. Сторонние — глючат!!! Работал с Telerik, DevExpress — просто не верится, что такие уважаемые компании выкидывают на рынок такое <здесь нехорошее слово>.
Я работаю с Инфрагистик, потому, что стандартный и девэкспрессовский грид, мягко говоря, не функциональны. Проблемы есть, но только с RIA — не умеет работать с домайн контролом, не может забиндиться к риа коллекция в режиме редактирования и т.п. Винить инфрагистик сложно, РИА еше не в релизе, а превью вышло только летом.
Больше глюков пока не нашел.

SHE>- библиотеки. Иногда ето больно

Бывает, но обходится.

SHE>- нет XML/XSLT (есть Linq To Xml — пользуйтесь)
XmlReader/XmlWriter вроде тоже есть

SHE>- проблемно с линками (открытие интернет ресурса в текущем или новом окне — ето придется продумавать SL программисту)
Мелочь

SHE> и URL mapping-ом (SL3 предлагает solution, правда примитивный но какой никакой)
А с ним-то какие проблемы?

SHE>- проблемно с экспортом данных вообще
Никаких проблем не обнаружил.

SHE> + Copy/Paste любого контента в любое приложение — без проблем, с сохранением стилей или без
SHE> + Сохранить на диск — в виде HTML, TXT, MHT (веб архив, со всеми картинками) — без проблем
SHE> + Export таблиц — прямо в Excel (из IE, если установлен Office)
Смешно. Попробуй проделать те же самые операции с винвордовским меню. Не получается? Ах да! Не нужно же это. А почему? А потому, что копи-пасте и экспорт реализованы самим винвордом. И сделаны эти операции намного лучше, чем тот же экспорт html и потом попытка что-то с ним сделать.
Если немного поменять свое ASP.NET-ое мышление и воспринимать Silverlight application именно, как application, а не web page, то проблем станет ноль. Всего то и нужно сделать нормальный интерфейс, который все это умеет. Который позволяет экспортить и копи-пастить только нужные данные, без разметки. Знаешь как бесят все эти вебаппликухи, которые полагаются на то, что юзер все будет делать через стандартные механизмы, как задалбывает выделять строчку в таблице, когда выделение постоянно перескакивает на какой-нить логотип или заголовок, как потом в винворд влезают куски разметки? Нечего нам тут тащить в сильверлайт изначально ущербные практики!
И не надо мне говорить про эксель. В инфрагистике есть замечательные компоненты для работы с экселевскими файлами.

SHE>Пользователю надо комфортно работать с данными.
См. выше.

SHE>Можно ли как-то подружить SL с HTML? да, как-то.
Понятия не имею зачем это нужно в корпоративных приложениях. Видимо для того что бы плодить гибридных уродцев. Тем не менее все для этого есть.

SHE>Любой unhandled exception приводит к crash-у всего приложения.
Ну да. Видимо придется позабыть о жабаскриптной практике забивать на все и грамотно работать с exceptions.

SHE>Там где для html-я надо просто нажать F5, в SL ето тот же F5 только с перезагрузкой всей аппликухи.
А если сделать кнопочку Релоад, то перезагрузится только то, что ты сам захочешь.

SHE>А интеграция с серверными решениями (тот же reporting) ето как правило геморрой тот еще.
С репортингом не сталкивался, но с сервер-сайдом интеграция отличная.

SHE>Вообщем я для себя сделал выводы насчет пригодности SL для написания бизнес приложений.
Я тоже сделал. Наконец-то можно забыть, как о страшном сне, эту жуткую помесь ASP.NET, AJAX, HTML & JScript и писать нормальные корпоративные приложения на SL. Еще очень сильно надеюсь, что часть указанных здесь пунктов заставят девелоперов писать нормальный UI, поменьше полагаясь на стандартно-ущербный от браузера.

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

А>И ежу понятно, что ежели у вас 400 запросов в секунду, то необходимо искать разумный компромисс между скоростью работы и удобством пользования. Этим компромисом является BLToolkit. Мне тяжело назвать "удобным" использование SQL при разработке приложений на C#. Я предполагаю, что дело не в мышлении, а в типе разрабатываемого ПО. К примеру у нас удачно удалось применить наследование объектов и хранение таковых в БД посредством Гибернейта. Если суть разрабатываемого ПО состоит не в хрании данных, а в управлении внешними устройствами, моделировании процессов и т.д. (тут хранение данных не есть основой самого ПО и подход к проектированию иной нежели таблица и список) тогда заморачиваться SQL`ем чтобы ускорить время реакции интерфейса с 0,0001с до 0,00009с есть нецелесообразно, а местами еще и вредно. Посему заявления, что проект априори под угрозой только потому что под Гибернейтом, смешные.

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

Ты сделал неверный вывод когда копался в исходниках, если посчитал, что BLToolkit (а значит и мы) предлагает использовать SQL в виде строк и с синтаксисом конкретной СУБД.

Просто BLToolkit так развивался. В начале он автоматизировал работу с SQL в обычных ADO.NET-приложениях.
Но с появлением LINQ и с началом работы над LINQ-провайдером для BLToolkit, BLToolkit перестал требовать писать запросы вручную.

BLToolkit стал предлагать другой (в отличии от Гибернэйта) стиль работы с данными. В этом стиле во главу угла ставится не объект, а список. Объекты в нем рассматриваются как PONO (Plain Old dotNet Object) или попросту плоский объект (без наследовани, без иерархий, без виртуальности и других заморочек). Цель этого объекта — позволить манипулировать записями из БД.
Пока что LINQ-провайдером для BLToolkit не закончен и в нем нет всех функциональности. Но я очень надеюсь, что когда IT закончит, BLToolkit позволит нам монипулировать данными хранящимисмя в СУБД так как будто они находятся прямо на шашей машие и являются списками типизированных объетков, но при этом теми методами которые уместны для работы с большими множествами объектво (т.е. методами СУБД) — запросами. Причем не только запросами на выборку (select-ами в терминах SQL), но и запросами на обновление.

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

Да, некоторыми вещами придется поплатиться. Так наследование, виртуальность и прочая дребедень несколько ограничены (хотя кое-что можно будет эмулировать). Но то что данными можно будет манипулировать с помощью запросов позволит очень сильно упростить код.

Объекты, со всеми их прелестями, можно будет по прежнему использовать в коде программ (на клиентах и в серверах приложений), но эти обекты не будут персистентными. Они будут жить только в рамках приложения (как это происходило до появления персистентной модели). Если надо в эти объекты можно будет загружать состояние из объектов данных (назовем PONO так). Более того некоторые возможности H/ORM можно будет эмалировать на базе BLToolkit. Так, например, можно будет обеспечить модификацию свойств отдельного объекта с последующей записью изменений. Но это будет делаться как надстройка над механизмом основанным на запросах. В итоге будет код который читает значения свойств объектов и формирует запрос на изменение.

Если же вы проектируете систему как объектную модель и вас не интересуют вопросы повышения производительности и упрощения управления наборами данных, то конечно Гибернэйт будет хорошим выбором, так как он позволяет замаскировать работу с данными под привычную работу с объектами и не требует от человека думать о данных как о наборах которые обрабатываются запросами. Но при этом не ясно зачем вообще нужен гибернэйт и СУБД. Ведь тогда граф объектов проще сериализовать в ХМЛ или бинарную форму и записать в файл. Разве что ли для того, чтобы организовать не очень многопользовательское решение от которого не будет требоваться высокой масштабируемости, параллелизма и

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

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

C>>>И они по своему дизайну не Turing-complete.
WH>>А всякие там TSQL очень даже Turing-complete. При этом еще и императивные в доску.
C>Ну это уже извращение, не спорю. С CTE и сам SQL тоже полон, но CTE можно игнорировать, как ещё одно кривое расширение.

CTE отличная вещь — не надо его игнорировать. И на каком основании эта часть стандарта SQL стала вдруг кривым расширением?

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

IT>Так же следует отметить, что бытует мнение, будто H/ORM лучше подходят для больших и сложных задач, а LW/ORM для маленьких и простых. Это заблуждение.
Так же следует отметить, что бытует мнение, будто L/ORM лучше подходят для больших и сложных задач, а HW/ORM для маленьких и простых. Это заблуждение.

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

VD>Серьезно? И чем же они помогают?

Тебе ничем. Коси траву в противогазе ибо так труднее. )))
Юзайте, дети мои, то что вашей душе угодно.
Для топикстартера информации достаточно, разве что порекомендую Мартина Фаулера "Архитектура корпоративных программных приложений" пролистать. Похоже что топикстартер программист с опытом — определиться с выбором сам сможет. А ДАО на sql и самому можно написать.

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

А>Тебе ничем. Коси траву в противогазе ибо так труднее. )))
А>Юзайте, дети мои, то что вашей душе угодно.

Фу, какой бездарный слив.

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

G>linq2sql — больше H/ORM.

Я бы не сказал. Возврат из запроса массива сконструированных по месту кортежей для linq2sql не запасной парашут, а совершенно нормальный, основной режим работы, что есть характернейший признак LW/ORM. Для всех H/ORM характерным является возвращение активных коллекций, что в linq2sql наблюдается только в довольно специфичных случаях.

... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>

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

IT>Единственная проблема — уровень подготовки разработчиков.

в конторе где я работаю последние 5 лет мы сталкивались (на самом деле расшибались) именно об эту проблему не менее трех раз. Пробовали разные подходы в том числе используя разные фреймворки — проблемы одни и те же. Тяжело\долго обучить ресурс со стороны конкретному фремевейрку и стилю, если так можно выразится, его использования.
Как это ни странно, но из десятков проектов в которых я принимал участие одним из самых успешных был проект в котором использовалась POCO модель данных и комбинировались ADO.NET (более старый код времен сотворения .NET 1.1) и BLToolkit для работы с базой данных. Проект до сих пор расширяется новой функциональностью без особых проблем. Недавно передавали проект другой группе разработчиков для дальнейшего сопровождения — возникавшие по ходу вопросы в большинстве своем не касались DAL\ORM.

В новом проекте (несколько месяцев, совершенно другая предметная область) пришел новый ресурс с хорошим знанием NHibernate. Решили попробовать NHibernate еще раз (первый раз обламались на нем года 3 назад). И началось 'притягивание' модели данных под нужды фреймворка. Модель получилась гораздо более правильная с точки зрения DDD чем в упомянутом ранее проекте, но ее использование другими разработчиками более проблематично, так как налагает определенные требования к знанию\поддержанию состояния модели. Плюс разработчик должен понимать что конкретное design решение в модели данных было принято не потому, что так было хорошо, а потому что ТАК НАДО для работы фреймворка. ИМХО именно это часто вызывает самые серьезных затруднения.

В конечном итоге мораль сей басни такова — IT прав в том, что чем меньше требований инструмент предъявляет разработчику, тем больше вероятность что он будет использован, и, как ни странно, использован правильно...

ИМХО успешность использования фреймворка командой разработчиков может быть определена формулой, схожей с определением счастливой семейной пары, где каждый старается больше дать, чем получить взамен, и при этом не выдвигает идиотских требований\условий

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

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

G>>>С чего ты взял? Исходники видел?
C>>Нет. Презентации о его архитектуре.
Dog>Где можно глянуть ?

Частично отсюда: http://code.google.com/p/gmail-greasemonkey/wiki/GmailGreasemonkey10API

Ещё здесь было, AFAIR: http://www.youtube.com/watch?v=cQyha30nm6k

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

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

КО>>Для баз МС рекомендует Entity Framework, но многие используют и хвалят NHibernate.

VD>Это все временное явление. IT на финише работы которая добавит поддержку LINQ в BL-Toolkit. После того как он закончит выбор будет очевиден

.
Никак не могу найти убедительных доводов спрыгнуть с NHibernate в пользу BL-Toolkit. Я скорее на Entity Framework уйду, как только увижу что оно всеръез задумано майкрософтом.

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

А>Да и... в НХибернейте для простейшего ДАО нам абсолютно не надо знать SQL. Самый простейший пример с BL-Toolkit — наичнается с селектов. Т.е. я меняю бизнесобъект и сразу же обязан в дао подправить запрос. Если это однозначно так — то мне это не по карману.

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

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

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

G>>linq2sql — больше H/ORM.

AVK>Я бы не сказал. Возврат из запроса массива сконструированных по месту кортежей для linq2sql не запасной парашут, а совершенно нормальный, основной режим работы, что есть характернейший признак LW/ORM. Для всех H/ORM характерным является возвращение активных коллекций, что в linq2sql наблюдается только в довольно специфичных случаях.
Ну тогда EF вообще lw/orm, только несколько просчетов не позволяют использовать его в этом качестве на полную катушку. (кстати эти просчеты у EFv4 исправлены).

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

C>>По выразительности Булкиту до настоящего ORM — как до Луны. Как появится lazy loading и автодетект изменений, тогда посмотрим.
IT>Надеюсь, при мне это никогда не появится. Тем не менее, если тебе хочется поговорить о выразительности не на словах, а на деле, то мы можем с тобой посостязаться. Давай возьмём какой-нибудь PetShop и сравним код на булките и NH.
PetShop совершенно неинтересен. Это банальное классическое веб-приложение.

Ты лучше попробуй сделать так, чтобы изменения, которые ты делаешь с помощью Булкита, записывались в отдельную базу для аудита, а потом рассылались клиентам (с учётом ACL, невыразимых на уровне стандартных средств БД).

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

IT>>Как хочешь. Можно параметры убрать и получать имя вызывающего метода из колстека. Это всё дело техники и не очень интересно.
C>А что делать с аргументами? Запись в логе "изменил права доступа" мало кого интересует.

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

C>Не-не-не, ещё как имеет. ORM позволяет мне нужную задачу реализовать легко, так как в ORM уже есть система поиска изменений, уже есть абстракции объектов и связей.
C>Тебе это придётся руками делать.

Не переживай, не придётся. В булките есть всё, что для этого нужно (смотреть BLToolkit.EditableObjects). Но, повторяю ещё раз, эта задача ортогональна работе с БД. Булкит умеет и это и многое другое, но все эти вещи чётко разделены и могут использоваться как вместе так и раздельно. В твоём же инструменте всё намешано в одну большую кучу г.

IT>>Зачем такое вообще делать? Судя по твоей любви к мелким извращениям твоя изначальная задача может быть спокойно решена каким-нибудь прямым простым способом.
C>Не может быть. Ни у одного из конкурентов она вообще нормально не получилась. Один из них вообще заставляет работать пользователей через терминальный клиент к их серверу, так как не осилили сделать удалённый клиент (требуется куча запросов и убивает латентность).

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

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

IT>>Но, повторяю ещё раз, эта задача ортогональна работе с БД. Булкит умеет и это и многое другое, но все эти вещи чётко разделены и могут использоваться как вместе так и раздельно. В твоём же инструменте всё намешано в одну большую кучу г.
C>Не ортогонально.
Не выдумывай. Трекинг изменений в DataSet был еще в самой первой версии и он совершенно ортогонален работе с БД. То что в большинстве ORM_ов прибит гвоздями к контексту не является правильным решением.
Кстати в EVv4 можно отцепить трекинг от контекста.

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

VD>А не надо делать денормализацию. Агрегаты просто нужно делать как отдельные процедуры, а данные хранить в нормализованном виде.
Для простых аггрегатов есть indexed\materialized view. Более сложные агрегаты можно делать на триггерах.
Совсем крутые аггрегаты, например по иерархическим мерам — уже OLAP.

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

G>EF начал разрабатыватсья раньше linq2sql
Но неправильнее и кривее.

... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>

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

IT>>Как правильно заметил AVK в EF реализованы оба подхода, видимо из-за чувства вины за убийство Linq 2 SQL.

G>EF начал разрабатыватсья раньше linq2sql

Это уже не важно.

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

SHE>Мы говорим про разработку интерфейса. То что в большинстве проектов ето занимает не самый большой процент времени — не обсуждается.

Повторюсь: менять дизайн — это копейки. Если только вы не юзабелист/дизайнер интерфейсов... Но тогда сидите в Blend и работайте там, он специально для этого и предназначен.

SHE>Вообщем за время проекта имеем свой зверинец и здоровый зоопарк от коллег — все умники

То ли дело зоопарк яваскриптов, который не компилится, непонятно как тестируется имеет внутри три-четыре ветки под разные броузеры.

SHE>Или не всю, а скажем только 32-значный код ентого продукта. И что мне теперь — посимвольно переписывать с экрана? Или предусматривать каждый чих юзера и навешивать свои менюшки "еще по часу на правую кнопку" c одним пунктом "Copy to clipboard"? Ты просто засеки скока раз за день средний юзер тыкает CTRL-C/CTRL-V...

Мало. Очень мало. "Средний юзер" т.е. оператор сидит и долбит в формы данные. Кто с телефона, кто с каких-то бумаг. Никаких копи-пейстов. Всякие там манагеры и прочие сейлзы глядят в свои ненаглядные таблицы с графиками. Копипейстить там тоже особо негде.
Вообще, у вас ИМХО с юзабилити какие-то напряги. Клиент не должен ничего копи-пейстить. Вы спрашиваете " Вот надо мне ету инфу просто послать клиенту по мылу." — так я спрошу: как эти данные разослать всем клинентам? Пятьдесят тысяч копи-пейстов, не иначе. А только premium account-у? Сделать выборку и перекопипейстить их мыла

Если клиенту надо переслать по почте данные, то он должен тыцнуть мышкой: вот этим людям, на основании вооот этого шаблона послать вот эти данные. Всё. А заставлять пользователя копаться в аутлуке, искать какое мыло клиента(ой, а это он... или может оно сменилось? Вася, а ты не понишь, какое мыло этого... рыжего такого) — это, извините, бред.

YKU>>А как там этого достичь? Хаками js, попутно обходя грабельки особенностей разных броузеров?
SHE>Все зависит от постановки задачи. Большинство решаемо без хаков. Большой выбор JS библиотек и разных cross-броузерных AJAX-tookit-ов позволяет забыть об особенностях этих самых броузеров. Ну и по-любому, HTML поддерживается гораздо большим количеством броузеров, чем Silverlight

Вы всё скинули в кучу. Изначально мы о чём говорили? "enterprise level приложения (back-office-а и т.д.)". Поэтому вопросы кто там кого подерживает нас не так и сильно волнуют.
Виндовые ie+ff+opera(вроде начала), safari поддерживают — этого обычно достаточно, что-бы покрыть любой корпоративный стандарт. Если заказчик вдруг сидит на линуксах с их броузерами(я, правда, такого не видел) — тогда да, увы, наверное флеш наш выбор.
Немного в сторону:В большинстве случаем я вообще не понимаю на кой чёрт им этот веб сдался: операторы сидят в офисе, если надо — им компы как угодно сконфигурят. "Заходить отовсюду" всё равно будут с личного ноута, ситуация "забежал в интернет кафе побыстрому заэпрувить инвойсы" выглядит несколько фантастичной. Но это лирика.

Тоже самое про "кинуть линк". "Кинуть линк" — это действительно надо для морды магазина("Зиночка, погляди какая штучка"), для back-office это нафиг никому не сдалось(если очень cильно надо — Navigation application поможет отцу). То же самое и про "открытие в новом окне"(а запретить открывать новые окна в некоторых обстоятельствах штука весьма полезная). Скопировать страничку себе да диск/добавить в закладки — это тоже полезно на уровне конечного клиента, забредшего на сайт, но никак не.

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

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

C>>>1) Что кэшировать-то? Вот я нажал на ячейку — и мне надо показать подробные детали для неё. Шансы что я нажму на неё второй раз — не особо велики.
G>>Вот подробные детали и кешируй. Даже если второй раз запрошено никогда не будет это не даст заметного оверхеда. Причем кеш ответов не вносит оверхед в отличе от кеширования данных.
C>Торможение в первый раз — уже неприемлимо.
Да ты че? а как же 5 метров первая загрузка?

C>>>2) Как инвалидировать будем-с?
G>>last modified
C>Это требует _каждый_ _раз_ делать запрос на сервер при нажатии на ячейку. Пофиг что оно вернёт "304 Not Modified" — всё равно нужен отдельный запрос.
Ну да, с каналом в 1,5 мбит это пройдет незаметно.

C>>>Хранимые процедуры, триггеры, CTE — уже не имеют никакого отношения к реляционной алгебре. Соответственно, глупо утверждать что программа с большим числом хранимок и триггеров более "реляционна", чем программа с H/ORM.
G>>Как раз можно, томому что теже триггеры и CTE работают именно с реляционными данными, тогда как H/ORM хочет сделать вид что работа идет с объектами.
C>Нет, H/ORM работает с объектным представлением реляционных данных.
Мало маслянное.

C>Сам по себе H/ORM так же "реляционен" как и голый SQL.
Ты видимо не понимаешь что означает термин "реляцонный".

C>>>Ты не учитываешь, что некоторые изменения должны делаються очень быстро. Если координатор, который должен распределить пару тысяч смен, должен по 10 секунд ждать на каждую операцию — он придёт к тебе домой и тебя застрелит.
G>>Ну да, выдумывание небылиц — хороший способ обоснования свой позиции, с чего ты взял 10 секунд?
C>Даже пара секунд — уже много. Уже даже доли секунды — слишком много.
Ну да, у тебя тоже реалтайм софт по управлению ядерным реактором?
Задержка в пределах секунды для сохранения — вполне нормально.

G>>Даже если взять того же оператора и представить что пересчет аггрегатов в запросе выполняется в 100 раз быстрее 0.1 секунду, то на отображение 10000 записей ему придется ждать около 20 минут. И это прижедтся испытать каждому пользователю, который попытается просмотреть расписание.
C>Ты забываешь, что в том виде, который смотрит координатор никакие сложные аггрегаты не считаются.
В другом считаются, без разницы.

C>>>Я говорю не про FK. Я уже привёл пример, когда изменение одного кусочка данных повляет на другой, не связанный напрямую с ним.
G>>И что? Ты создавая программу не знаешь какие действия на какие данные повлияют?
C>Не знаю. Поэтому и сделал систему, где мне и знать это необязательно.

C>>>Нет. Лишний расход траффика — у тебя. У меня сейчас дневной расход на приложение — около 10Мб. 5Мб на начальную загрузку (надо бы её оптимизировать...), а дальше считанные байты на трансляцию изменений.
G>>

G>>А в моем подходе не будет начальной загрузки и теже 5 метров будут растянуты по времени. И потом тоже будут "считанные байты" на изменения.
C>Не будут. У тебя загрузка одного вида займёт в лучшем случае килобайт 500. А их переключают кучу десятков раз в день.
Давай не будем мерятся качаемыми данными, в твоем случае в среднем получится больше.

C>>>Т.е. оно реально может использоваться на модеме.
G>>

G>>Я плакал
C>Плачь. Требование реально.
Как ты 5 метров на модеме выкачаешь?.

C>>>Для твоей модели оно недостижимо.
G>>Ну я как раз через GPRS часто в интернете сижу. Если бы мне кто-нибудь предложил скачать 5 метров просто чтобы начать пользоваться программой, то я бы сразу послал такой сервис.
C>А твой сервис с торможением по минуте на _каждое_ действие пошлют ещё дальше.
Уже минуты... хорошо ты выдумываешь...
Время работы сервера в случае GPRS пренебрежительно мало по сравенинию со всеменем передачи данных.

G>>Короче хватит практиковаться в выдумывании небылиц. Адекватного описания преимуществ твоего подхода не видно, а все что есть вполне делается и без h\orm.
C>Ну да. Твой подход требует:
C>1) Большого расхода времени.
Докажи

C>2) В 10-100 раз большего количества серверов.
Докажи

C>3) Гораздо более сложного программирования — ручного отслеживания зависимостей.
Это зависит от структуры программы. В моем случае все зависимости явные.

C>4) Мешанины UDF, SP и прочих "радостей".
Которые улучшают производительность и уменьшают нагрузку на сеть.

C>5) Зависимость от конкретной БД.
Какой ужас...

C>6) Не будет работать на модеме.

Будет лучше чекм твой вариант

Короче не выдумывай небылицы.

Последние пару лет отошел от Майкрософта..
Сейчас приходится возвращаться.
В связи с этим актуален вопрос, не появился ли какой-нибудь
продвинутый фреймворк, упрощающий процесс разработки Веб и десктоп-приложений
на базе современных технологий Microsoft: XAML, LINQ.
Чтобы позволял костяк бизнес-модели (структуру, ограничения) определять в одном месте более менее компатно
и по нему можно было бы генерировать все что нужно: базу, классы linq, дефолтный xaml.
Что-то типа django ))

Интересует сие все же скорее для десктопных (Не Веб) программ.

Как фронтенд, я бы однозначно рекомендовал Silverlight 3 (www.silverlight.net) и WPF. Тогда можно будет использовать один и тот же код и для клиента, и для веба.

Для баз МС рекомендует Entity Framework, но многие используют и хвалят NHibernate.

Ещё вот буквально сегодня ссылка пробежала:
http://www.nakedobjects.org/home/index.shtml
Это к твоему желанию иметь один декларативный слой, а остальные генерить

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

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

КО>Для баз МС рекомендует Entity Framework, но многие используют и хвалят NHibernate.

Это все временное явление. IT на финише работы которая добавит поддержку LINQ в BL-Toolkit. После того как он закончит выбор будет очевиден

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

А>Никак не могу найти убедительных доводов спрыгнуть с NHibernate в пользу BL-Toolkit. Я скорее на Entity Framework уйду, как только увижу что оно всеръез задумано майкрософтом.
http://ormbattle.net/
Посмотри кто там в лидерах... И на сколько отстали все остальные.

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

WH>Здравствуйте, Аноним, Вы писали:

А>>Никак не могу найти убедительных доводов спрыгнуть с NHibernate в пользу BL-Toolkit. Я скорее на Entity Framework уйду, как только увижу что оно всеръез задумано майкрософтом.
WH>http://ormbattle.net/
WH>Посмотри кто там в лидерах... И на сколько отстали все остальные.
Да, это видел. Но есть несколько другие критерии, и один из самых важных (важнее скорости) — это апробация.
Судя по вот этому:
http://rsdn.ru/Forum/Info/FAQ.rfd.rfdprojects.aspx
не густо.
Ставить под угрозу новый проект не особо хочется.

Да и... в НХибернейте для простейшего ДАО нам абсолютно не надо знать SQL. Самый простейший пример с BL-Toolkit — наичнается с селектов. Т.е. я меняю бизнесобъект и сразу же обязан в дао подправить запрос. Если это однозначно так — то мне это не по карману.

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

А>Ставить под угрозу новый проект не особо хочется.

Если ты испоьзуешь НГибернэйт, то проект уже под угрозой.

Мне даже страшно представить, что было бы если бы РСДН жил бы на гибернэйте.

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

VD>Если ты испоьзуешь НГибернэйт, то проект уже под угрозой.

VD>Мне даже страшно представить, что было бы если бы РСДН жил бы на гибернэйте.

Хотелось бы более детальной информации об рисках, связанных с использованием NHibernate в таком проекте как rsdn.

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

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

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

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

OA>Хотелось бы более детальной информации об рисках, связанных с использованием NHibernate в таком проекте как rsdn.

У нас просто не хватит денег на железо. На РСДН используется только прямая работа с SQL и BL-Toolkit.
NHibernate-у к ним и на пушечный выстрел не подойти.

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

OA>Связь отношение-класс для простейших операций CRUD себя вполне оправдывает.

Ну, да если ресурсы беспредельны, а операций кот наплакал.

OA>Если же говорить о сложных выборках, например, для аналитической отчетности, то здесь использовать ORM даже вредно. Так что все зависит от задачи.

Ну, и зачем тогда вообще такой ОРМ?

Полностью согласен.
Еще бы вместо убогого SQL'я и его кошмарных расширений сделали бы ленивый функциональный язык (LINQ имеет именно такую семантику) было бы вообще супер.

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

А>Да и... в НХибернейте для простейшего ДАО нам абсолютно не надо знать SQL. Самый простейший пример с BL-Toolkit — наичнается с селектов. Т.е. я меняю бизнесобъект и сразу же обязан в дао подправить запрос. Если это однозначно так — то мне это не по карману.
Смотри сюда:
http://code.google.com/p/ormbattle/source/browse/trunk/Tests/Performance/BLToolkitTest.cs
Там всего 2 SQL запроса. Один очищает таблицу до и после теста.
А второй в тесте по имени NativeQueryTest

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

WH>Еще бы вместо убогого SQL'я и его кошмарных расширений сделали бы ленивый функциональный язык (LINQ имеет именно такую семантику) было бы вообще супер.
Нет, тут сложнее. SQL — изначально основывался на операциях с множествами, у которых главная фича в том, что они могут быть хорошо оптимизированы. И они по своему дизайну не Turing-complete. О том как бы лучше расширить SQL написан не один десяток диссертаций

Тупые методы "взять и всю базу в память загрузить, а потом map-reduce'у скормить" неинтересны.

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

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

C>И они по своему дизайну не Turing-complete.
А всякие там TSQL очень даже Turing-complete. При этом еще и императивные в доску.

C>О том как бы лучше расширить SQL написан не один десяток диссертаций

На какие только темы диссертации не пишут.

C>Тупые методы "взять и всю базу в память загрузить, а потом map-reduce'у скормить" неинтересны.
А императивненько ползать курсором по таблице значит интересно?
А не иметь нормальных средств декомпозиции запросов тоже интересно?

После появления CTE они стали Тюринг-полными. Так что ты не прав.

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

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

C>>И они по своему дизайну не Turing-complete.
WH>А всякие там TSQL очень даже Turing-complete. При этом еще и императивные в доску.
Ну это уже извращение, не спорю. С CTE и сам SQL тоже полон, но CTE можно игнорировать, как ещё одно кривое расширение.

C>>Тупые методы "взять и всю базу в память загрузить, а потом map-reduce'у скормить" неинтересны.
WH>А императивненько ползать курсором по таблице значит интересно?
Нет. Я про такие "расширения" и не говорю.

WH>А не иметь нормальных средств декомпозиции запросов тоже интересно?
Нет. Но если пытаться что-то придумать на мотив SQL, то сильно лучше тоже что-то не получается. Понятно, что кое-что можно улучшить — в явном виде представлять отношения, к примеру. Но сама суть SQL по дизайну сделана ограниченной.

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

C>>Нет, тут сложнее. SQL — изначально основывался на операциях с множествами, у которых главная фича в том, что они могут быть хорошо оптимизированы. И они по своему дизайну не Turing-complete. О том как бы лучше расширить SQL написан не один десяток диссертаций

VD>После появления CTE они стали Тюринг-полными. Так что ты не прав.
Я их игнорирую

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

VD>Здравствуйте, Аноним, Вы писали:

А>>Да и... в НХибернейте для простейшего ДАО нам абсолютно не надо знать SQL. Самый простейший пример с BL-Toolkit — наичнается с селектов. Т.е. я меняю бизнесобъект и сразу же обязан в дао подправить запрос. Если это однозначно так — то мне это не по карману.

VD>Вы что гордитесь, что не знаете и не используете SQL?

Меня радует возможность не менять ДАО при изменении свойств бизнес-объектов.

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

А>Господа, теперь я понял почему вы так хвалите свое боло... ой BL-Toolkit. Без обид, но как минимум не скромно хаять темы пришедшие из ява. Генерики тоже из ява пришли

А>Или может Мартин Фаулер по вашему необразован?
http://en.wikipedia.org/wiki/Generic_programming

А>гыг, что еще сказать
А ничего и не надо больше

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

S>Здравствуйте, Аноним, Вы писали:

А>>Господа, теперь я понял почему вы так хвалите свое боло... ой BL-Toolkit. Без обид, но как минимум не скромно хаять темы пришедшие из ява. Генерики тоже из ява пришли

А>>Или может Мартин Фаулер по вашему необразован?
S>http://en.wikipedia.org/wiki/Generic_programming

А>>гыг, что еще сказать
S>А ничего и не надо больше

, виноват, на эмоциях выдал непроверенную инфу.
Обидно слышать что мои проекты щас живут и где то там у них есть угроза, потому что на гибернейте.
Но по сути — зачем тогда BL-Toolkit если я и так могу все дао на SQL переписать?
Есть два вида водителей: одни просто ездят и для решения повседневных задач им коробка-автомат приемлемо, другим только механика — чтобы на светофорах не обижали.

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

А>>>Да и... в НХибернейте для простейшего ДАО нам абсолютно не надо знать SQL. Самый простейший пример с BL-Toolkit — наичнается с селектов. Т.е. я меняю бизнесобъект и сразу же обязан в дао подправить запрос. Если это однозначно так — то мне это не по карману.

VD>>Вы что гордитесь, что не знаете и не используете SQL?

А>Меня радует возможность не менять ДАО при изменении свойств бизнес-объектов.

Я разве об этом спрашивал?

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

А>…Без обид, но как минимум не скромно хаять темы пришедшие из ява. Генерики тоже из ява пришли

Вслед за сборщиком мусора что ли пришли?

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

VD>Здравствуйте, Аноним, Вы писали:

А>>>>Да и... в НХибернейте для простейшего ДАО нам абсолютно не надо знать SQL. Самый простейший пример с BL-Toolkit — наичнается с селектов. Т.е. я меняю бизнесобъект и сразу же обязан в дао подправить запрос. Если это однозначно так — то мне это не по карману.

VD>>>Вы что гордитесь, что не знаете и не используете SQL?

А>>Меня радует возможность не менять ДАО при изменении свойств бизнес-объектов.

VD>Я разве об этом спрашивал?
Отвечаю на Ваш вопрос:
я использую SQL там где NHibernate не уместен.
несколько лет назад я сопровождал ОДБ под ораклом — там ОРМ не уместна, только SQL — и его я там накушался до отвращения — горжусь этим.

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

А>Обидно слышать что мои проекты щас живут и где то там у них есть угроза, потому что на гибернейте.

Пока у них нет по 400 параллельных запросов, как это постоянно происходит на РСДН, им ничего не угражает.

А вообще, да, согласен. Слышать то, что ты используешь не эффективное и неразумно спроектированное решение всегда неприятно. Раньше я тоже наверно обиделся бы, если услышал бы такое. А сейчас я бы предпочел для начала разобраться в сути вопроса. Оказывается, что не все представления которые мы имеем верны.

А>Но по сути — зачем тогда BL-Toolkit если я и так могу все дао на SQL переписать?

Он тебе не нужен если ты конечно не хочешь писать более масштабируемые проекты меньшими силами. Ну, и соответственно, нужен если хочешь.

А>Есть два вида водителей: одни просто ездят и для решения повседневных задач им коробка-автомат приемлемо, другим только механика — чтобы на светофорах не обижали.

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

В прочем все аналогии пригодны только для образного объяснения.

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

А>Господа, теперь я понял почему вы так хвалите свое боло... ой BL-Toolkit. Без обид, но как минимум не скромно хаять темы пришедшие из ява.

Я к BL-Toolkit не имею никакого отношения.

А>Генерики тоже из ява пришли

О как? А ничего что дженерики в CLI (в специальном открытом проекте созданном автором F#) появились на пару лет раньше чем аналогичное предложение для явы?
Дженерики пришли из мира функционального программирования где они поддерживались начиная с 70-х годов. Кроме того, конечно, большое влияние на них оказали шаблоны С++.
Дженерики же явы являются весьма поверхностным решением. Короче, курите источники.
http://en.wikipedia.org/wiki/Generic_programming#Generics_in_Java

А>Или может Мартин Фаулер по вашему необразован?
А>гыг, что еще сказать

А что Фаулер писал, что BL-Toolkit — это плохо?
Гы-гы. Что еще сказать на такую логику?

Как мне взять вот это
http://rsdn.ru/projects/rfd/rfd_dev.rar
вижу страницу с "Server Error in Application "RSDN.RU""

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

А>Как мне взять вот это
А>http://rsdn.ru/projects/rfd/rfd_dev.rar
А>вижу страницу с "Server Error in Application "RSDN.RU""

http://www.bltoolkit.net/download.htm

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

А>Отвечаю на Ваш вопрос:
А>я использую SQL там где NHibernate не уместен.
А>несколько лет назад я сопровождал ОДБ под ораклом — там ОРМ не уместна, только SQL — и его я там накушался до отвращения — горжусь этим.

Получается, что ты используешь и NHibernate и SQL. А можно было бы использовать один LINQ. При этом и скорость была бы лучше, и код более высокоуровневым был бы.

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

VD>Получается, что ты используешь и NHibernate и SQL. А можно было бы использовать один LINQ. При этом и скорость была бы лучше, и код более высокоуровневым был бы.
Не так. У гибернейта есть язык запросов, зачастую мне его хватает заглаза. Разве что груповое изменение типа UPDATE ... WHERE

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

А>Не так. У гибернейта есть язык запросов, зачастую мне его хватает заглаза.

Только он динамически типизированный и не очень хорошо ложиться на РСБУД. Вот и приходится тебе писать что-то на SQL-диалекте конкретной СУБД.

А>Разве что груповое изменение типа UPDATE ... WHERE

Вот именно! А это очень не маловажный момент. Для производительности он чуть ли не главный. А как только ты полез делать UPDATE-ты вручную, так сразу нарываешься на конфликт идеологией гибернэйта (его кэша).

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

VD>Здравствуйте, Аноним, Вы писали:

А>>Не так. У гибернейта есть язык запросов, зачастую мне его хватает заглаза.

VD>Только он динамически типизированный и не очень хорошо ложиться на РСБУД. Вот и приходится тебе писать что-то на SQL-диалекте конкретной СУБД.

А>>Разве что груповое изменение типа UPDATE ... WHERE

VD>Вот именно! А это очень не маловажный момент. Для производительности он чуть ли не главный. А как только ты полез делать UPDATE-ты вручную, так сразу нарываешься на конфликт идеологией гибернэйта (его кэша).

Мне не доводилось писать бизнеслогику где бы требовались груповые изменения. В основном объект туда, объект сюда

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

VD>А вообще, да, согласен. Слышать то, что ты используешь не эффективное и неразумно спроектированное решение всегда неприятно. Раньше я тоже наверно обиделся бы, если услышал бы такое. А сейчас я бы предпочел для начала разобраться в сути вопроса. Оказывается, что не все представления которые мы имеем верны.

А можно по-подробнее на ету тему.

В чём принципиальная разница в использовании BLToolkit, NHibernete и FE?
Какое решение выбрать?
К сожалении при всём уважении к BLToolkit (результаты тестов видел, впечатляет) использовать его нет возможности поскольку к сожалению не мы ето определяем.

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

А>А можно по-подробнее на ету тему.

На этом сайте эта тема обсуждалась уже много раз. Поиск должен помочь.

А>В чём принципиальная разница в использовании BLToolkit, NHibernete и FE?

В двух словах — в идеологии. NHibernete и от части FE предлагают абстрагироваться от реляционной природы данных замаскировав БД под граф объектов. К сожалению ООП плохо подходит для обработки массивов данных. В нем для этого попросту нет средств. Работа с БД чрез интефейс объектов приводит к огромному оверхэду. Основная причина заключается в том, что ООП хорошо выглядит только если объекты лежат в памяти. Тогда начинаются разные навороты цель которых скрыть эти проблемы. Средства используются разные, но обычно все сводится к кэшированию. Ну, а кэширование, как не трудно догадаться противоречит массовм обновлениям данных с использованием UPDATE + сложное WHERE (а то и подзапросами, и джоинами).

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

Для обработки данных в BLToolkit предлагается всегда использовать запросы. Это могут быть или прямые обращения к СУБД на ее диалекте SQL, или (с недавнего времени) использование универсального языка LINQ. Сейчас автор BLToolkit-а (IT) заканчивает реализацию поддержки LINQ для BLToolkit. Он обещал, что к в него войдут и массовые обновления/вставки. Обещана поддержка широкого спектра СУБД.
Используя возможности BLToolkit-LINQ можно будет эффективно обрабатывать данные больших объемов самым естественным для этого образом и при этом быть независимым от конкретной СУБД (по желанию, конечно). При этом так же гарантируется, что работа с удаленными данными будет производиться практически так же эффективно как прямая работа с SQL.

А>Какое решение выбрать?
А>К сожалении при всём уважении к BLToolkit (результаты тестов видел, впечатляет) использовать его нет возможности поскольку к сожалению не мы ето определяем.

Если у вас есть возможность использовать NHibernete, то не понятно что может не дать использовать BLToolkit.

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

VD>BLToolkit предлагает смотреть на БД как на БД и всего лишь автоматизирует операции выборки данных и превращение строк в простые объекты. БД в этом случае представляется в виде списков объеденных реляционными отношениями. Объекты же всего лишь заменяют абстракцию записи (в широком смысле этого слова, т.е. некой структуры данных имеющей именованные поля).
Хотел было разобраться с тулкитом, но ... дела мирские.
Хочу рассказать еще о Гибернейте (мне кажется что это не сделаешь в БЛТулките)
Когда я проектирую бизнес-логику, я делаю как это учил Фаулер — сначала определяюсь с бизнес-объектами. Затем, я эти объекты реализую на языке программирования и... вуаля расставляю атрибуты и создаю структуру БД на сервере БД. Меняю бизнес-логику — пересоздаю програмно структуру БД, очень удобно. Пока скорость работы удовлетворяет, не имею ни малейшего желания усложнять себе жизнь. Хотя, БЛТулкит конечно же поковыряю.

VD>Если у вас есть возможность использовать NHibernete, то не понятно что может не дать использовать BLToolkit.

Дабы избедать таких ситуаций
http://rsdn.ru/forum/prj.rsharp/2347688.flat.aspx#2347688

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

А>Мне не доводилось писать бизнеслогику где бы требовались груповые изменения. В основном объект туда, объект сюда

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

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

VD>Здравствуйте, Аноним, Вы писали:

А>>Мне не доводилось писать бизнеслогику где бы требовались груповые изменения. В основном объект туда, объект сюда

VD>Скорее всего это потому, что ты думаешь в императивном стиле.
VD>Мне вот никогда не доводилось видеть бизнес данные состоящие из отдельных объектов. Всегда, почему-то, попадались списки или таблицы.

Таблица — это массив объектов

У каждого объекта могут быть связи с другими — это либо ссылка на другой объект либо массив объетов с лейзилоадами.

Груповое изменение данных мне приходилось часто делать в ОДБ — там проведение документов, овердрафтов и тому подобной дряни хватало. Но ведь не все приложения — это отчеты для баб из бухгалтерии ) извините если кого обидел. Бывают проекты, где записей в бд итого несколько сотен, но каждая запись на вес золота. Например ты хранишь показания прибора за некий интревал времени. Показания — это wav размером нескольно десятков мегабайт + некоторые метаданные. Вот тут то лейзилоады то что доктор прописал.

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

VD>>Скорее всего это потому, что ты думаешь в императивном стиле.
VD>>Мне вот никогда не доводилось видеть бизнес данные состоящие из отдельных объектов. Всегда, почему-то, попадались списки или таблицы.

А>Таблица — это массив объектов ;-)

Вау! В смысле — уж ты!

Не вспомнишь определение понятия массив?
И, кстати, почему объектов?

А> У каждого объекта могут быть связи с другими — это либо ссылка на другой объект либо массив объетов с лейзилоадами.

Ты про реляционную теорию что-то слышал?

А>Груповое изменение данных мне приходилось часто делать в ОДБ — там проведение документов, овердрафтов и тому подобной дряни хватало. Но ведь не все приложения — это отчеты для баб из бухгалтерии ) извините если кого обидел. Бывают проекты, где записей в бд итого несколько сотен, но каждая запись на вес золота.

Зачем же сотню записей пихать в БД, да еще и в виде объектов ее представлять?
Может проще было бы, действительно, массив объектов сделать?

А> Например ты хранишь показания прибора за некий интревал времени. Показания — это wav размером нескольно десятков мегабайт + некоторые метаданные. Вот тут то лейзилоады то что доктор прописал.

Серьезно? И чем же они помогают?

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

IT>>Так же следует отметить, что бытует мнение, будто H/ORM лучше подходят для больших и сложных задач, а LW/ORM для маленьких и простых. Это заблуждение.
C>Так же следует отметить, что бытует мнение, будто L/ORM лучше подходят для больших и сложных задач, а HW/ORM для маленьких и простых. Это заблуждение.

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

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

IT>>Так же следует отметить, что бытует мнение, будто H/ORM лучше подходят для больших и сложных задач, а LW/ORM для маленьких и простых. Это заблуждение.
C>Так же следует отметить, что бытует мнение, будто L/ORM лучше подходят для больших и сложных задач, а HW/ORM для маленьких и простых. Это заблуждение.

Если под размером задач понимается объем обрабатываемых данных, то несомненно лучше.

Вообще не верно называть продукты вроде гибернэйта H/ORM-ами. Более точно их назвать Object Persister-ами, так как именно эта идеология подводится под них.

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

IT>>>Так же следует отметить, что бытует мнение, будто H/ORM лучше подходят для больших и сложных задач, а LW/ORM для маленьких и простых. Это заблуждение.
C>>Так же следует отметить, что бытует мнение, будто L/ORM лучше подходят для больших и сложных задач, а HW/ORM для маленьких и простых. Это заблуждение.
IT>Ну да, от перемены букв местами суть не меняется. По делу есть что сказать?
Просто для полноты. Ну или можно очередной флейм устроить ORM vs. L/ORM. Мне лично лень.

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

C>Просто для полноты. Ну или можно очередной флейм устроить ORM vs. L/ORM. Мне лично лень.

А что его устраивать то? Факты на лицо. Иди сначала поправь тесты гибернэта так чтобы они хотя бы сравнялись с булкитовскими, тогда можно будет еще раз пофлэймить.

Потом с тобой не интересно флэймить. Ты рано или поздно начинаешь всем объяснять, что просто используешь некий сабсэт гибернэйта как эдакий L/ORM. Так что с одной стороны ты споришь с нами, но с другой находишся практически на тех же позиция. Ну, а твои сказки про скорость гибернэйта как-то не стыкуются с результатами тестов.

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

VD>Вообще не верно называть продукты вроде гибернэйта H/ORM-ами. Более точно их назвать Object Persister-ами, так как именно эта идеология подводится под них.

К сожалению, продукты вроде гибернэйта узурпировали термин ORM полностью, хотя давно ушли в другую сторону и этому термину уже не соответствуют. Мне тоже такая ситуация не нравится, но, думаю, вряд ли уже можно что-то сделать. Можно начать хотя бы разделять ORM тулы по классам: H/ORM и LW/ORM, а там дальше видно будет.

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

C>>Просто для полноты. Ну или можно очередной флейм устроить ORM vs. L/ORM. Мне лично лень.
VD>А что его устраивать то? Факты на лицо. Иди сначала поправь тесты гибернэта так чтобы они хотя бы сравнялись с булкитовскими, тогда можно будет еще раз пофлэймить.
"Иди перепиши Nemerle, чтоб всегда работал быстрее кода на С"

В смысле: "А нафига"? Люди пишут приложения на Питоне и PHP, которые в 100-200 раз медленнее С.

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

IT> Можно начать хотя бы разделять ORM тулы по классам: H/ORM и LW/ORM

А куда тогда linq2sql приткнуть? LW/ORM с элементами H/ORM?

... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>

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

IT>> Можно начать хотя бы разделять ORM тулы по классам: H/ORM и LW/ORM

AVK>А куда тогда linq2sql приткнуть? LW/ORM с элементами H/ORM?

Я бы приткнул к LW/ORM, не смотря на глупости от H/ORM.

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

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

IT>> Можно начать хотя бы разделять ORM тулы по классам: H/ORM и LW/ORM

AVK>А куда тогда linq2sql приткнуть? LW/ORM с элементами H/ORM?

linq2sql — больше H/ORM.

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

IT>К сожалению, продукты вроде гибернэйта узурпировали термин ORM полностью, хотя давно ушли в другую сторону и этому термину уже не соответствуют. Мне тоже такая ситуация не нравится, но, думаю, вряд ли уже можно что-то сделать. Можно начать хотя бы разделять ORM тулы по классам: H/ORM и LW/ORM, а там дальше видно будет.

Никуда они не уходили. Они родились такими. Идею персистентности мусировали в Корбе еще до того как Ява стала популярна. О Гибернейте тогда даже речи не шло.

Что до названий, то мне кажется имеет смысл придумать совсем новое название в котором не было бы даже упоминания об объектах и отображении. Ну, как в LINQ-е. Например, можно назвать это дело Object Relation Integrator — ORI.

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

C>"Иди перепиши Nemerle, чтоб всегда работал быстрее кода на С"

А что булкит на С написан и по этому в скорости выигрывает?

C>В смысле: "А нафига"? Люди пишут приложения на Питоне и PHP, которые в 100-200 раз медленнее С.

А, ну, то есть гибернэйт это средство предназначенное для того, чтобы снизить скорость еще на порядок? Крутяк! :))

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

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

VD>Например, можно назвать это дело Object Relation Integrator — ORI.

Назвать можно, только кто этим названием пользоваться будет?

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

AVK>Я бы не сказал. Возврат из запроса массива сконструированных по месту кортежей для linq2sql не запасной парашут, а совершенно нормальный, основной режим работы, что есть характернейший признак LW/ORM. Для всех H/ORM характерным является возвращение активных коллекций, что в linq2sql наблюдается только в довольно специфичных случаях.

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

Скажем доступ к данным можно было бы получать с помощью некого метода LoadData() или GetReader().

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

VD>>Например, можно назвать это дело Object Relation Integrator — ORI.

IT>Назвать можно, только кто этим названием пользоваться будет?

Ты. Глядишь станешь главным родоначальником нового ту-вэя! :))

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

C>>"Иди перепиши Nemerle, чтоб всегда работал быстрее кода на С"
VD>А что булкит на С написан и по этому в скорости выигрывает?
Нет, это примерно такое же по глупости выражение. Немерль ты выбираешь вовсе не из-за того, что он быстрее С.

C>>В смысле: "А нафига"? Люди пишут приложения на Питоне и PHP, которые в 100-200 раз медленнее С.
VD>А, ну, то есть гибернэйт это средство предназначенное для того, чтобы снизить скорость еще на порядок? Крутяк!

Угу.

VD>Если серьезно, то я как бы и не спорю, что для людей не осиливших работу со списками и сидящих на ПХП — гибернэйта за глаза хватит. Только для них гибернэйт — это слишком сложно. Им лучше что-то типа "рельсов".
VD>Но вот на фиг гибернэйт нужен для людей у которых присутствует интеллект я понять не могу.
Ты просто не умеешь им пользоваться. Или делаешь такие приложения, где пофиг чем пользоваться.

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

C>Нет, это примерно такое же по глупости выражение. Немерль ты выбираешь вовсе не из-за того, что он быстрее С.

Я его выбираю потому, что он сравним с С по скорости и сильно превосходит его по выразительности и удобству.
А вот за что выбираю Гибирнэйт? Он ведь по скорости сильно уступает булкиту, и при этом еще и отстает от него по выразительности. :xz:

VD>>Если серьезно, то я как бы и не спорю, что для людей не осиливших работу со списками и сидящих на ПХП — гибернэйта за глаза хватит. Только для них гибернэйт — это слишком сложно. Им лучше что-то типа "рельсов".
VD>>Но вот на фиг гибернэйт нужен для людей у которых присутствует интеллект я понять не могу.
C>Ты просто не умеешь им пользоваться. Или делаешь такие приложения, где пофиг чем пользоваться.

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

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

C>По выразительности Булкиту до настоящего ORM — как до Луны. Как появится lazy loading и автодетект изменений, тогда посмотрим.

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

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

G>Ну тогда EF вообще lw/orm, только несколько просчетов не позволяют использовать его в этом качестве на полную катушку.

Значит не lw/orm

G> (кстати эти просчеты у EFv4 исправлены).

значит EFv4 можно использовать как LW/ORM (компенсация за застреленный linq2sql?).

... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>

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

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

А>>В чём принципиальная разница в использовании BLToolkit, NHibernete и FE?

IT>BLToolkit — это lightweight ORM. NH и FE — heavy ORM.

IT>Принципиальная разница между LW/ORM и H/ORM в том, что задача первых облегчить работу с реляционными данными, а вторых — заменить работу с реляционными данными на работу с объектной моделью. Из этого вытекают как достоинства, так и недостатки обоих подходов.

Но ведь и те и другие возвращают одинаковую коллекцию объектов. Какая-то быстрее, какая-то медленнее.
Етот нюанс не понятен.

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

C>>Ты лучше попробуй сделать так, чтобы изменения, которые ты делаешь с помощью Булкита, записывались в отдельную базу для аудита, а потом рассылались клиентам (с учётом ACL, невыразимых на уровне стандартных средств БД).
IT>Задача аудита совершенно ортогональна тому, чем должен заниматься ORM tool. И реализуется она в приложения с прямой архитектурой с помощью вызова одного метода на операцию в нужном месте, вроде:
IT>

public void Audit(string operation, string comment);

А как мы синтезируем строчку и операцию?

Ручками? -> У морг.

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

Т.е. я делаю так:

        //В дебрях сервера
    @Override public void setCustomProperty(Key usId, String prop, String value, String type)
    {
        User us=(User)dataHelper.loadForModify(ctx(), usId); //С учётом ACL!

        CustomProperty newProp=new CustomProperty();
        newProp.setParentUser(us);
        us.getCustomProperties().add(newProp);

        newProp.setName(prop);
        newProp.setValue(value);
        newProp.setType(type);
                //И ничего больше делать не надо!
       }

       //На клиентах
       public void consumeEvents(DiffBundle diff)
       {
             User us=getCurrentUser();
             if (diff.containsObject(us))
             {
                   Set<CustomProperty> props=us.getCustomProperties();
                   rebindProperties(props); //И пользователь видит изменённые данные. МГНОВЕННО.
             }
       }

Более того, клиенты не имеют доступа к БД _вообще_. Они полностью работают через слой реплицируемых объектов.

Как такое будешь делать?

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

C>Более того, клиенты не имеют доступа к БД _вообще_. Они полностью работают через слой реплицируемых объектов.
C>Как такое будешь делать?
Забыл сказать. Разные CustomProperty могут ещё иметь разные правила доступа, и для недопущенные пользователи просто не увидят то, что не могут видеть.

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

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

А>Но ведь и те и другие возвращают одинаковую коллекцию объектов. Какая-то быстрее, какая-то медленнее.
А>Етот нюанс не понятен.

Вопрос не в том, что они возвращают, а как они это делают. В случае с LW/ORM программист обращается за данными к БД с помощью LW/ORM. В H/ORM программист обращается непосредственно к H/ORM, а уж как там она работает с БД дело десятое.

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

G>кстати эти просчеты у EFv4 исправлены

Можно развить эту тему?

Что планируется изменить?

Есть ли ссылки?

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

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

А>>Но ведь и те и другие возвращают одинаковую коллекцию объектов. Какая-то быстрее, какая-то медленнее.
А>>Етот нюанс не понятен.

IT>Вопрос не в том, что они возвращают, а как они это делают. В случае с LW/ORM программист обращается за данными к БД с помощью LW/ORM. В H/ORM программист обращается непосредственно к H/ORM, а уж как там она работает с БД дело десятое.

Понятно, тогда просоединяюсь H/ORM в топку.

На етом фоне кем-же тогда является EF.
С одной стороны он работает напрямую с БД, а сдругой у него есть 3 слоя, которые в итоге должны скрыть работу с базой данных.

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

IT>>

public void Audit(string operation, string comment);

C>А как мы синтезируем строчку и операцию?

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

C>Оно у меня не для аудита нужно (это просто приятное дополнение), а для рассылки изменений клиентам. В реальном времени.

Подожди-ка, дружок. Мы с тобой начали с того, что ты предъявил претензии к выразительности булкита как ORM инструмента. Доказывать свою позицию на примере веб-проекта ты отказался, ввиду примитивности задачи для такого крутого профи как ты. Бредовость аудита средствами NH ты теперь тоже ненавязчиво отвергаешь и предлагаешь новую задачу, которая тоже к ORM инструменту никакого отношения не имеет. WTF is going on?

C>Более того, клиенты не имеют доступа к БД _вообще_. Они полностью работают через слой реплицируемых объектов.
C>Как такое будешь делать?

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

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

IT>>>

public void Audit(string operation, string comment);

C>>А как мы синтезируем строчку и операцию?
IT>Как хочешь. Можно параметры убрать и получать имя вызывающего метода из колстека. Это всё дело техники и не очень интересно.
А что делать с аргументами? Запись в логе "изменил права доступа" мало кого интересует.

C>>Оно у меня не для аудита нужно (это просто приятное дополнение), а для рассылки изменений клиентам. В реальном времени.
IT>Подожди-ка, дружок. Мы с тобой начали с того, что ты предъявил претензии к выразительности булкита как ORM инструмента. Доказывать свою позицию на примере веб-проекта ты отказался, ввиду примитивности задачи для такого крутого профи как ты. Бредовость аудита средствами NH ты теперь тоже ненавязчиво отвергаешь и предлагаешь новую задачу, которая тоже к ORM инструменту никакого отношения не имеет.
Не-не-не, ещё как имеет. ORM позволяет мне нужную задачу реализовать легко, так как в ORM уже есть система поиска изменений, уже есть абстракции объектов и связей.

Тебе это придётся руками делать.

C>>Как такое будешь делать?
IT>Зачем такое вообще делать? Судя по твоей любви к мелким извращениям твоя изначальная задача может быть спокойно решена каким-нибудь прямым простым способом.
Не может быть. Ни у одного из конкурентов она вообще нормально не получилась. Один из них вообще заставляет работать пользователей через терминальный клиент к их серверу, так как не осилили сделать удалённый клиент (требуется куча запросов и убивает латентность).

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

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

G>>Ну тогда EF вообще lw/orm, только несколько просчетов не позволяют использовать его в этом качестве на полную катушку.
AVK>Значит не lw/orm

ну он более lw, чем linq2sql

G>> (кстати эти просчеты у EFv4 исправлены).
AVK>значит EFv4 можно использовать как LW/ORM (компенсация за застреленный linq2sql?).
можно

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

C>Умею. Но у меня просто не стандартное веб приложение — у меня изменения графа объектов с сервера реплицируются на клиенты. Причём каждый клиент имеет свой собственный вид графа, с учётом ACL и некоторых настроек.

Это пожалуй единственное рациональное зерно, потому отвечу на это.

Я уже как-то говорил с IT о том, что было бы не плохо реализовать LINQ-DML и триггеры для него.

Но даже не имея подобной фичи у нас есть СУБД в которых есть все что нужно для репликации данных. От встроенных средств репликации, до триггеров (в том числе и на высокоуровневых языках). Так что это не аргумент. Чем ближе к данным репликация, тем надежнее она будет работать, так как меньше лазеек через которые можно все испортить.

Здравствуйте, yoriсk.kiev.ua, Вы писали:

YKU>Верно. Но можно подумать в asp.net что-то иначе... На практике достаточно навороченую форму с табами, визардом и прочим в дизайнере тоже хрен откроешь.
YKU>Короче, ситуация абсолютно одинаековая: на более-менее простых формах всё Ок, на сложных — и там и там грабли.
SHE>>- отладка. Вообщем-то очевидно — пока не скомпилишь — не запустишь. Забудьте про изменения "на лету", как в ASP.NET. Мелочь? Ето здорово кушает время — скомпилил, запустил, проверил, нашел ошибку, остановил, пофиксил, скомпилил, запустил...и т.д. по кругу.
YKU>Да ну, это не серьёзно.

Сравни workflow:
ASP.NET: запустил сайт, на лету меняешь странички (дизайн, код...) и вот тебе сразу результат — наслаждаемся background компиляцией.
SL: запустил приложение, остановил, меням код, запустил, остановил, меняем код... Повторюсь — ета мелочь, но при достаточно больших размерах исходников неимоверно жрет время (тут я добавлю чисто субьективный момент, что студия у меня регулярно зависала и падала через n итераций

). В ASP.NET — если не меняется библиотечный код (в App_Code) компилится только тек. измененная страничка. Сессии, кэш остаются на месте. Вам не надо заново (если ето приложение с авторизацией) вводить логин/пароль чтобы добраться до нужной странички и протестировать измененную функциональность.

YKU>Разметка занимает дай бог процентов десять времени. И я реально забыл уже когда мне хотелось бы делать это в дизайнере.
Мы говорим про разработку интерфейса. То что в большинстве проектов ето занимает не самый большой процент времени — не обсуждается.
Кстати раз уж заговорили про core part имейте ввиду, что SL и "не-SL" сборки не совместимы. Есть хаки как ето поправить, но в основном рекомендуют добавлять в проект общие классы как файл линки. Ето кстати первый случай на .NET, где также понадобились С# препроцессинг директивы — в SL некоторые сигнатуры конструкторов отличаются, или отсутствуют методы или классы.

SHE>> К тому же в Silverlight-е есть ряд забавных конвенций — например Binding ошибки не считаются ошибками, и обнаружить их можно только тестируя приложение и тупо мониторя Output окошко
YKU>Есть более прогрессивные методы

YKU>http://bea.stollnitz.com/blog/?p=52
Все эти прогрессивные методы просто позволяют "реже нагибаться".

SHE>>Чего только стоит эмуляция дабл клика мыши

YKU>Господи, да там один раз на всю жизнь за час пишется экстеншн... Ну еще по часу на правую кнопку и колёсико.
Ну еще на paging и сортировку. Ну там за час написать свой или где надыбать ICommand. Ну нету там MultiTrigger, DataTrigger — сворганить воркароунд по-бырому.
Вообщем за время проекта имеем свой зверинец и здоровый зоопарк от коллег — все умники

SHE>>Пользователю надо комфортно работать с данными. Что предлагает Silverlight? CTRL-C в SL работает только в текст-боксах...
YKU>Идея через буфер себе странички сохранять достаточно странная. Нафига тогда вообще огород городить, если пользователю "комфортно работать с данными" не через ваш инструмент, а сохраняя страницу(куда?)?
Ну вот ты странный, ей-бо. Допустим у тебя есть форма, выводящая информацию о каком-то продукте. Вот надо мне ету инфу просто послать клиенту по мылу.
Или не всю, а скажем только 32-значный код ентого продукта. И что мне теперь — посимвольно переписывать с экрана? Или предусматривать каждый чих юзера и навешивать свои менюшки "еще по часу на правую кнопку" c одним пунктом "Copy to clipboard"? Ты просто засеки скока раз за день средний юзер тыкает CTRL-C/CTRL-V...

SHE>>проблемно с линками (открытие интернет ресурса в текущем или новом окне — ето придется продумавать SL программисту)
YKU>Вы чего, издеваетесь? HtmlPage.Window.Navigate(url, target) — хоть в новом, хоть в текущем... Может это в консерватории что-то не так?

Ну так и я о том же — ты прописываешь в коде про "хоть в новом, хоть в текущем", а не юзер выбирает.
Хотя ето не самая большая проблема.
Вот я сейчас твое сообщение в форуме могу добавить в favourites или кинуть shortcut на десктоп — прямой линк.
А что делать, если б web-морда форума была на SL?

YKU>Короче, всё совсем не так страшно, как вы это описываете. Тем более, что основная масса притензий вообще непонятно к чему: SL плохой, надо double-click допиливать, а html хороший, там...
То что я описал — неудобства, c которыми сталкивается и разработчик и пользователь.
Вот скажи — каким решением вы воспользуетесь для печати из SL приложения?

YKU>А как там этого достичь? Хаками js, попутно обходя грабельки особенностей разных броузеров?
Все зависит от постановки задачи. Большинство решаемо без хаков. Большой выбор JS библиотек и разных cross-броузерных AJAX-tookit-ов позволяет забыть об особенностях этих самых броузеров. Ну и по-любому, HTML поддерживается гораздо большим количеством броузеров, чем Silverlight

YKU>Для меня лично есть одно достоинство SL, котрое перевешивает все недостатки. Я ПИШУ НА ОДНОМ ЯЗЫКЕ.
SL в текущем его состоянии для меня, к сожалению, эти недостатки не перевешивает.

YKU>Как пишутся морды на ASP.net? Тут html, здесь — js, тут — dhtml, тут css, еще какая-то хрень... Блин, да на каком языке мы пишем?
YKU>" ASP.NET (или любой другой web framework)"? Это же html, шаг в право — шаг в лево: расстрел. Сделать дропдаун с чем-то кроме текста? Вот вам бубен. Надо карту/графики? Ой, это лучше вообще на чём-нибуть другом. Драг-энд-дроп? Тут где-то фреймфорк на js был... Многооконный интерфейс? Ну вы поняли

Да. Много технологий, библиотек, даже языков программирования, поэтому практически любой сложности задачи решаемы. В крайнем случае внедрю тот же апплет на Silverlight-е. У вас так не получится

YKU>Каких контролов вам не хватает? Нас полностью удовлетворяет Silverlight Toolkit(это вроде как стандартный набор), ну DevExpress(он бесплатный пока) еще иногда.
Стандартные примитивны, сторонние глюковаты. Вообщем если у вас с этим проблем нет, ето не значит что их нет вообще.

YKU>В общем у нас идут в основном холивары между флешерами и sl, приверженцев asp.net+js как-то не осталось

да да, поживем увидим

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

IDL>На етом фоне кем-же тогда является EF.
IDL>С одной стороны он работает напрямую с БД, а сдругой у него есть 3 слоя, которые в итоге должны скрыть работу с базой данных.

Как правильно заметил AVK в EF реализованы оба подхода, видимо из-за чувства вины за убийство Linq 2 SQL.

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

C>>Умею. Но у меня просто не стандартное веб приложение — у меня изменения графа объектов с сервера реплицируются на клиенты. Причём каждый клиент имеет свой собственный вид графа, с учётом ACL и некоторых настроек.
VD>Это пожалуй единственное рациональное зерно, потому отвечу на это.
VD>Я уже как-то говорил с IT о том, что было бы не плохо реализовать LINQ-DML и триггеры для него.
Малой кровью не обойтись. Я думал о том, как бы это сделать без Hibernate (она меня достала уже

). Но всё в итоге сводится к "написать свой велосипедный Hibernate".

VD>Но даже не имея подобной фичи у нас есть СУБД в которых есть все что нужно для репликации данных. От встроенных средств репликации, до триггеров (в том числе и на высокоуровневых языках). Так что это не аргумент. Чем ближе к данным репликация, тем надежнее она будет работать, так как меньше лазеек через которые можно все испортить.
Репликация в известных СУБД — это ерунда.

Во-первых, на рынке нет решений, позволяющих делать то что мне надо — транслировать изменения сотням подключенных клиентов (вот сейчас вижу, что на сервере висит 700 пользователей). Причём у самих клиентов локальной БД не стоит, они просто запускают моё приложение (через WebStart — по сути просто заходят на нужную страничку в браузере).

Во-вторых, уровень СУБД слишком низкий для многих операций. Скажем, для сложного контроля доступа. А ещё ведь реплицировать клиентам надо только то, что они могут видеть. А row-level security — уж жутко примитивный, даже в Oracle и MSSQL.

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

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

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

G>>кстати эти просчеты у EFv4 исправлены

VD>Можно развить эту тему?

VD>Что планируется изменить?

VD>Есть ли ссылки?

Есть VS2010 и EF Feature CTP1.
Смторю http://blogs.msdn.com/efdesign/default.aspx и http://blogs.msdn.com/adonet/default.aspx

Вкратце полезные новшества:
1)Маппинг функций и поддержка их в Linq
2)Поддержка Contains в Linq
3)Поддержка Poco (на самом деле можно полностью настроить кодогененрацию с помощью t4)
4)Маппинг внешних ключей (обещали в beta2)
5)Надеюсь что прикрутят метод AttachAsModified
6)Сделали ExecuteStoreCommand и ExecuteStoreQuery, которые позволяют писать SQL там где без него не обойтись.

Последняя фича в сочетании с методом ObjectQuery<T>.ToTraceString позволяет делать массовые операции.

Кроме этого есть еще self-tracking entities, которые вполне способны вытеснить датасеты в n-tier сценариях.

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

IT>Само собой. Что душе угодно — это когда получается работать с любым инструментом. А если работать с реляционными данными получается хреново, то, конечно, остаётся только нахваливать лэйзилоадинг.
Насколько я понял (а я немного покопал Ваш проект) то между BLToolkit и NHibernate разница намного большая, чем просто скорость работы. Я смотрю, что пипл юзающий BLToolkit, "люто ненавидит H/ORM" [(c) IT] потому что пытались применить его как "молоток к шурупу" [(с) IT].
И ежу понятно, что ежели у вас 400 запросов в секунду, то необходимо искать разумный компромисс между скоростью работы и удобством пользования. Этим компромисом является BLToolkit. Мне тяжело назвать "удобным" использование SQL при разработке приложений на C#. Я предполагаю, что дело не в мышлении, а в типе разрабатываемого ПО. К примеру у нас удачно удалось применить наследование объектов и хранение таковых в БД посредством Гибернейта. Если суть разрабатываемого ПО состоит не в хрании данных, а в управлении внешними устройствами, моделировании процессов и т.д. (тут хранение данных не есть основой самого ПО и подход к проектированию иной нежели таблица и список) тогда заморачиваться SQL`ем чтобы ускорить время реакции интерфейса с 0,0001с до 0,00009с есть нецелесообразно, а местами еще и вредно. Посему заявления, что проект априори под угрозой только потому что под Гибернейтом, смешные.
Я очень надеюсь, что в своем посте не допустил грамматических, орфографических ошибок, а также верно применил все термины дабы не дать пиплу комментировать не по сути. Если есть по сути — рад знакомству.

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

C>>А что делать с аргументами? Запись в логе "изменил права доступа" мало кого интересует.
IT>Так ты задачу поставь нормально, со всеми деталями и тогда мы её решим.
Нужно записать полный результат операции — что и как было изменено.

C>>Не-не-не, ещё как имеет. ORM позволяет мне нужную задачу реализовать легко, так как в ORM уже есть система поиска изменений, уже есть абстракции объектов и связей.
C>>Тебе это придётся руками делать.
IT>Не переживай, не придётся. В булките есть всё, что для этого нужно (смотреть BLToolkit.EditableObjects).
Придётся. Во-первых, в EditableObject нет вычисления изменений (добавить несложно, согласен). Во-вторых, там нет нет трэкинга коллекций. В-третьих, ВСЕ объекты нужно делать Editable. В-четвёртых, когда ты это всё закончишь делать — получишь Hibernate, вид сбоку.

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

C>>Не может быть. Ни у одного из конкурентов она вообще нормально не получилась. Один из них вообще заставляет работать пользователей через терминальный клиент к их серверу, так как не осилили сделать удалённый клиент (требуется куча запросов и убивает латентность).
IT>То, что у тебя что-то получилось, а у конкурентов нет, говорит лишь о том, что ты смог проявить смекалку и нае... простите, обойти свою большую кучу г, а они не смогли. Вот и всё. Если решение существует в рамках твоей большой кучи г, то его всегда можно выделить и применить отдельно. Просто твоя большая куча г тебя уже полностью засосала и зашорила мозги и ты отказываешься это понимать и мыслить вне рамках своей кучи г.
Ну ровно то же говориться про BLToolkit. Эта куча г. не позволяет нормально работать с объектным представлением, требуя везде знать детали мэппинга на БД.

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

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

IDL>>На етом фоне кем-же тогда является EF.
IDL>>С одной стороны он работает напрямую с БД, а сдругой у него есть 3 слоя, которые в итоге должны скрыть работу с базой данных.

IT>Как правильно заметил AVK в EF реализованы оба подхода, видимо из-за чувства вины за убийство Linq 2 SQL.

EF начал разрабатыватсья раньше linq2sql

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

VD>>Я уже как-то говорил с IT о том, что было бы не плохо реализовать LINQ-DML и триггеры для него.
C>Малой кровью не обойтись. Я думал о том, как бы это сделать без Hibernate (она меня достала уже :) ). Но всё в итоге сводится к "написать свой велосипедный Hibernate".

Какой еще кровью?
Представь...
Весь DML (Update, Insert, Delete) идет через LINQ+-драйвер где его можно легко перехватить и или просто проанализировать и отпустить в том же виде, или переписать запросы как посчитаешь нужным. Запросы при этом предствалены в виде AST аля LINQ Expression.

C>Репликация в известных СУБД — это ерунда.

Гы-гы.

C>Во-первых, на рынке нет решений, позволяющих делать то что мне надо — транслировать изменения сотням подключенных клиентов (вот сейчас вижу, что на сервере висит 700 пользователей). Причём у самих клиентов локальной БД не стоит, они просто запускают моё приложение (через WebStart — по сути просто заходят на нужную страничку в браузере).

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

C>Во-вторых, уровень СУБД слишком низкий для многих операций. Скажем, для сложного контроля доступа. А ещё ведь реплицировать клиентам надо только то, что они могут видеть. А row-level security — уж жутко примитивный, даже в Oracle и MSSQL.

Ну, так код нужно писать. Его все равно писать придется.

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

А не надо делать денормализацию. Агрегаты просто нужно делать как отдельные процедуры, а данные хранить в нормализованном виде.

В прочем, на словах всегда все просто. Я просто к тому веду, что все это реализуется и на моделе с L/ORM.

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

G>Вкратце полезные новшества:
G>2)Поддержка Contains в Linq

Это в смысле аналог in(...)?
И почему в Linq? В Linq2Sql это было. Наверно ты имел в виду "в EF"?

G>5)Надеюсь что прикрутят метод AttachAsModified

Это еще что?

G>6)Сделали ExecuteStoreCommand и ExecuteStoreQuery, которые позволяют писать SQL там где без него не обойтись.

Ну, это немного не то. Точнее сильно не то. Это как раз дырка в абстракции. Одни проблемы она позволит обойти (некузявость линка в общении с конкретными СУБД), но появятся другие — код будет привязан к конкретной СУБД и не будет единого место где можно было бы перехватить изменения и обработать их (нечто вроде независимых от СУБД триггеров).

G>Последняя фича в сочетании с методом ObjectQuery<T>.ToTraceString позволяет делать массовые операции.

А если они что-то кэшировать начнут? Ручне операции будут конфликтовать с кэшем.
Плюс — это приводит к необходимости работать с конерктным диалектом SQL, да еще без проверок во время компиляции. Короче говоря — это возврат к ADO.NET и строковым запросам.

G>Кроме этого есть еще self-tracking entities, которые вполне способны вытеснить датасеты в n-tier сценариях.

Это еще что?

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

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

G>>Вкратце полезные новшества:
G>>2)Поддержка Contains в Linq

VD>Это в смысле аналог in(...)?
VD>И почему в Linq? В Linq2Sql это было. Наверно ты имел в виду "в EF"?
ну да. Я имею ввиду Linq 2 enttites.
На уровне entity SQL и сейчас такое поддерживается.

G>>5)Надеюсь что прикрутят метод AttachAsModified
VD>Это еще что?
Когда выполняется attach сущности к контексту она присоединяется в статусе unmodified, и естественно в базу данные не записываются.
Теоретически надо иметь экеземпляр сущности с оригинальными значениями, аттачить его, потом делать ApplyPropertyChanges.
Но даже если предыдущие значения полей не важны, все равно придется поднимать из базы запись для её обновления.

Чтобы сейчас это победить надо лезть в object state manager и ручками проставлять статус Modified для сущности и её полей.
AttachAsModified должен это сам делать.

G>>6)Сделали ExecuteStoreCommand и ExecuteStoreQuery, которые позволяют писать SQL там где без него не обойтись.

VD>Ну, это немного не то. Точнее сильно не то.
Но лучше чем ничего.

VD>Это как раз дырка в абстракции. Одни проблемы она позволит обойти (некузявость линка в общении с конкретными СУБД), но появятся другие — код будет привязан к конкретной СУБД
Не дырка, метаданные (маппинг) доступны в рантайме, поэтому пожно сформировать корректный запрос.

VD>и не будет единого место где можно было бы перехватить изменения и обработать их (нечто вроде независимых от СУБД триггеров).
А вот это действительно проблема, но тоже можно обойти, например выкидывая свое событие из наследника ObjectContext и передавать туда нужные данные.

G>>Последняя фича в сочетании с методом ObjectQuery<T>.ToTraceString позволяет делать массовые операции.

VD>А если они что-то кэшировать начнут? Ручне операции будут конфликтовать с кэшем.
А тут уже используй как хчоешь: материализованные объкты с трекингом и LL (он тоже появится в следующей версии) или проекции и запросы, которые транслируются в нужный SQL. Будешь смешивать — ССЗБ.

VD>Плюс — это приводит к необходимости работать с конерктным диалектом SQL, да еще без проверок во время компиляции. Короче говоря — это возврат к ADO.NET и строковым запросам.
Ну совсем нет.
Можно написать код, который например будет принимать IQueryable<T> и удалять все записи из нужной таблицы, которые попадают в этот запрос.
То есть формировать что-то вроде "DELETE FROM [TableName] WHERE [Key] in (SELECT [Key] in ([текст запроса]))" доставая нужные имена ключей и таблиц из метаданных.
В BL это будет только типизированный IQueryable<T>, и нарваться на особенности конкретной СУБД будет сложно.

G>>Кроме этого есть еще self-tracking entities, которые вполне способны вытеснить датасеты в n-tier сценариях.
VD>Это еще что?
Это возможность прицепить трекинг изменений к сущностям, а не к контексту. Соотвественно граф объектов может быть сериализован вместе с информацией об изменениях, а также на клиенте может быть получен список изменений для отправки на сервер.

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

VD>Какой еще кровью?
VD>Представь...
VD>Весь DML (Update, Insert, Delete) идет через LINQ+-драйвер где его можно легко перехватить и или просто проанализировать и отпустить в том же виде, или переписать запросы как посчитаешь нужным. Запросы при этом предствалены в виде AST аля LINQ Expression.
Думаешь, я про это не думал?

Я даже пробовал такое сделать с iBatis, в котором перехват запросов — штатная фича.

Слишком уж низкий уровень.

C>>Репликация в известных СУБД — это ерунда.
VD>Гы-гы.
А что сделать?

C>>Во-первых, на рынке нет решений, позволяющих делать то что мне надо — транслировать изменения сотням подключенных клиентов (вот сейчас вижу, что на сервере висит 700 пользователей). Причём у самих клиентов локальной БД не стоит, они просто запускают моё приложение (через WebStart — по сути просто заходят на нужную страничку в браузере).
VD>А на хрена тогда нужна репликация? Это ты, мил человек, совей репликацией решаешь проблемы которые ты же привнес в свою жизнь когда решил использовать Гибернэйт.
Клиенты видят _сложный_ граф объектов. Т.е. на одном экране они могут реально видеть около пары десятков мегабайт данных. Если тупо перегружать всё при любом изменении — усё умрёт (прям как у конкурентов). Значит, нужно как-то делать инкрементальные изменения. А это как раз и требует отсылать только изменения.

Можно попробовать часть вычислений перенести на сервер, и выдавать уж совсем конечный результат, но всё равно данных катастрофически много.

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

C>>Во-вторых, уровень СУБД слишком низкий для многих операций. Скажем, для сложного контроля доступа. А ещё ведь реплицировать клиентам надо только то, что они могут видеть. А row-level security — уж жутко примитивный, даже в Oracle и MSSQL.
VD>Ну, так код нужно писать. Его все равно писать придется.
Проблема в том, что коду приходят, по сути, только данные вида "table.object_id.field = 'newvalue'". И из них надо восстановить разумные действия.

ACL только усложняет задачу. К примеру, изменение свойства одного объекта может вызвать то, что ряду клиентов перестанут (или начнут) приходить обновления для других объектов. Так что последовательная обработка DML вообще становится невозможной.

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

VD>В прочем, на словах всегда все просто. Я просто к тому веду, что все это реализуется и на моделе с L/ORM.
Реализуется. С помощью реализации H/ORM, с видом сбоку. Я ж даже начинал это делать даже

По сути, ведь всё отличие L от H/ORM в двух вещах:
1) Трекинг изменений.
2) Поддержка загрузки зависимых коллекций.

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

C>>Не ортогонально.
G>Не выдумывай. Трекинг изменений в DataSet был еще в самой первой версии и он совершенно ортогонален работе с БД. То что в большинстве ORM_ов прибит гвоздями к контексту не является правильным решением.
А ещё в 99 году я писал драйвер, перехватывающий SQL update'ы и парсящий их.

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

G>Когда выполняется attach сущности к контексту она присоединяется в статусе unmodified, и естественно в базу данные не записываются.
G>Теоретически надо иметь экеземпляр сущности с оригинальными значениями, аттачить его, потом делать ApplyPropertyChanges.
G>Но даже если предыдущие значения полей не важны, все равно придется поднимать из базы запись для её обновления.

G>Чтобы сейчас это победить надо лезть в object state manager и ручками проставлять статус Modified для сущности и её полей.
G>AttachAsModified должен это сам делать.

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

G>>>6)Сделали ExecuteStoreCommand и ExecuteStoreQuery, которые позволяют писать SQL там где без него не обойтись.

VD>>Ну, это немного не то. Точнее сильно не то.
G>Но лучше чем ничего.

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

VD>>Это как раз дырка в абстракции. Одни проблемы она позволит обойти (некузявость линка в общении с конкретными СУБД), но появятся другие — код будет привязан к конкретной СУБД
G>Не дырка, метаданные (маппинг) доступны в рантайме, поэтому пожно сформировать корректный запрос.

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

VD>>и не будет единого место где можно было бы перехватить изменения и обработать их (нечто вроде независимых от СУБД триггеров).
G>А вот это действительно проблема, но тоже можно обойти, например выкидывая свое событие из наследника ObjectContext и передавать туда нужные данные.

Это латание дыр.
По факту EF перерастает в монстра который просто не предназначен для того что мы хотим.

VD>>А если они что-то кэшировать начнут? Ручне операции будут конфликтовать с кэшем.
G>А тут уже используй как хчоешь: материализованные объкты с трекингом и LL (он тоже появится в следующей версии) или проекции и запросы, которые транслируются в нужный SQL. Будешь смешивать — ССЗБ.

Дык я не вижу прямого пути использования. Я вижу что EF бодрым шагом идет в сторону H/ORM (c) IT. Причем вижу, что пишут его "на заказа", т.е. не для себя. Вот получается фигня.

VD>>Плюс — это приводит к необходимости работать с конерктным диалектом SQL, да еще без проверок во время компиляции. Короче говоря — это возврат к ADO.NET и строковым запросам.
G>Ну совсем нет.
G>Можно написать код, который например будет принимать IQueryable<T> и удалять все записи из нужной таблицы, которые попадают в этот запрос.
G>То есть формировать что-то вроде "DELETE FROM [TableName] WHERE [Key] in (SELECT [Key] in ([текст запроса]))" доставая нужные имена ключей и таблиц из метаданных.

А что мешает сделать это же сейчас?

G>В BL это будет только типизированный IQueryable<T>, и нарваться на особенности конкретной СУБД будет сложно.

Согласен. Но все равно это будет конфликтовать с идеей персистентности объектов которую развивает сам EF.

G>>>Кроме этого есть еще self-tracking entities, которые вполне способны вытеснить датасеты в n-tier сценариях.
VD>>Это еще что?
G>Это возможность прицепить трекинг изменений к сущностям, а не к контексту. Соотвественно граф объектов может быть сериализован вместе с информацией об изменениях, а также на клиенте может быть получен список изменений для отправки на сервер.

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

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

IDL>>На етом фоне кем-же тогда является EF.
IDL>>С одной стороны он работает напрямую с БД, а сдругой у него есть 3 слоя, которые в итоге должны скрыть работу с базой данных.

IT>Как правильно заметил AVK в EF реализованы оба подхода, видимо из-за чувства вины за убийство Linq 2 SQL.

Мне кажется, что EF — это скрещивание ежа с ужем. Наличие инфраструктуры персистентности объектов делает слишком сильно привязанным к H/ORM.

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

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

G>>Когда выполняется attach сущности к контексту она присоединяется в статусе unmodified, и естественно в базу данные не записываются.
G>>Теоретически надо иметь экеземпляр сущности с оригинальными значениями, аттачить его, потом делать ApplyPropertyChanges.
G>>Но даже если предыдущие значения полей не важны, все равно придется поднимать из базы запись для её обновления.

G>>Чтобы сейчас это победить надо лезть в object state manager и ручками проставлять статус Modified для сущности и её полей.
G>>AttachAsModified должен это сам делать.

VD>Если я все правильно понял, то это очень похоже на героическое решение проблем созданных перед этим.
VD>Мне кажется, что было ошибкой само создание всех этой инфраструктуры.
Ну это собственно расплата за возможность получить изменения объектов, про которую рассказывает Cyberax.

VD>>>Это как раз дырка в абстракции. Одни проблемы она позволит обойти (некузявость линка в общении с конкретными СУБД), но появятся другие — код будет привязан к конкретной СУБД
G>>Не дырка, метаданные (маппинг) доступны в рантайме, поэтому пожно сформировать корректный запрос.
VD>Будет два конфликтующих механизма изменения данных в БД и никто не сможет гарантировать, что они не будет конфликтовать. А если неприятность может случиться, то она обязательно случится.
Я уже давно работаю с вебом, а там конфликтующие изменения и так случаются.
Меня это совершенно не парит.
А в контекстве обработки одно запроса нарваться на подобные конфликты — надо еще постораться.

VD>>>и не будет единого место где можно было бы перехватить изменения и обработать их (нечто вроде независимых от СУБД триггеров).
G>>А вот это действительно проблема, но тоже можно обойти, например выкидывая свое событие из наследника ObjectContext и передавать туда нужные данные.

VD>Это латание дыр.
VD>По факту EF перерастает в монстра который просто не предназначен для того что мы хотим.
Наоборот, EF предоставляет возможности для всех. И для тех кто хочет LL, и для тех кто хочет запросы писать.
При этом эти возможности друг другу не мешают.

VD>>>А если они что-то кэшировать начнут? Ручне операции будут конфликтовать с кэшем.
G>>А тут уже используй как хчоешь: материализованные объкты с трекингом и LL (он тоже появится в следующей версии) или проекции и запросы, которые транслируются в нужный SQL. Будешь смешивать — ССЗБ.

VD>Дык я не вижу прямого пути использования. Я вижу что EF бодрым шагом идет в сторону H/ORM (c) IT. Причем вижу, что пишут его "на заказа", т.е. не для себя.
EF конечно преобретает возможности H/ORM, но это не означает что надо эти возможности использовать.

VD>Вот получается фигня.
Фигня в основном получается от того что многие разработчики EF слишком много читали фаулера и прочих эвансов.

VD>>>Плюс — это приводит к необходимости работать с конерктным диалектом SQL, да еще без проверок во время компиляции. Короче говоря — это возврат к ADO.NET и строковым запросам.
G>>Ну совсем нет.
G>>Можно написать код, который например будет принимать IQueryable<T> и удалять все записи из нужной таблицы, которые попадают в этот запрос.
G>>То есть формировать что-то вроде "DELETE FROM [TableName] WHERE [Key] in (SELECT [Key] in ([текст запроса]))" доставая нужные имена ключей и таблиц из метаданных.

VD>А что мешает сделать это же сейчас?
То что не умеет сейчас ObjectContext выполнить произвольный SQL.
Хотя и это можно обойти, но не очень хочется.

G>>В BL это будет только типизированный IQueryable<T>, и нарваться на особенности конкретной СУБД будет сложно.
VD>Согласен. Но все равно это будет конфликтовать с идеей персистентности объектов которую развивает сам EF.
То что EF позволяет так работать еще не значит что надо обязательно так работать.

G>>>>Кроме этого есть еще self-tracking entities, которые вполне способны вытеснить датасеты в n-tier сценариях.
VD>>>Это еще что?
G>>Это возможность прицепить трекинг изменений к сущностям, а не к контексту. Соотвественно граф объектов может быть сериализован вместе с информацией об изменениях, а также на клиенте может быть получен список изменений для отправки на сервер.
VD>Это очень хорошо! Это очень не помешало бы. Только в итоге изменения должны записываться через некий типизированный DML.
Ну это уже есть. Список StateEntry.

VD>Тогда это будет аналогом отключенной работы, что предоставляли датасеты.
Ну собственно эта фича и придумана как убийца датасетов.

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

А>Насколько я понял (а я немного покопал Ваш проект) то между BLToolkit и NHibernate разница намного большая, чем просто скорость работы. Я смотрю, что пипл юзающий BLToolkit, "люто ненавидит H/ORM" [(c) IT] потому что пытались применить его как "молоток к шурупу" [(с) IT].

Дело даже не в BLToolkit. BLT можно совершенно спокойно заменить на Linq2SQL и получится тоже самое.

А>И ежу понятно, что ежели у вас 400 запросов в секунду, то необходимо искать разумный компромисс между скоростью работы и удобством пользования. Этим компромисом является BLToolkit. Мне тяжело назвать "удобным" использование SQL при разработке приложений на C#.

Какая разница что тяжело называть "удобным", SQL или HQL или как там его? Текстуальные строки они и в африке текстуальные строки.

Если же речь идёт о Linq, то тут есть один момент. Честно говоря, после выхода Linq2SQL я подумывал о переходе ORM части проекта BLT в пассивный режим развития, т.к. L2S обладая очень приличной производительностью и при наличии провайдеров к другим базам данных мог бы оказаться практически идеальным LW/ORM решением в том числе и для меня. Но в MS решили по-другому и развивать L2S не стали. В результате я занялся поддержкой Linq в BLT несколько поздновато, как минимум на пару лет позже, чем конкуренты. Но работы идут, на сегодня поддержка Linq в BLT уже выше, чем в NH и всё идёт к тому, что она будет не хуже или даже лучше, чем в L2S. При этом всё будет работать быстрее и более чем с десятком баз данных. Так что упрёки в plain SQL я пока принимаю, но очень скоро эти разговоры можно будет закончить навсегда. Можно даже уже начинать пробовать

А>Я предполагаю, что дело не в мышлении, а в типе разрабатываемого ПО.

Тип ПО без разницы. Дело именно в скилсете разработчиков. Если в нём отсутсвуют навыки работы с реляционными данными, то выбор H/ORM вполне очевиден.

А>К примеру у нас удачно удалось применить наследование объектов и хранение таковых в БД посредством Гибернейта. Если суть разрабатываемого ПО состоит не в хрании данных, а в управлении внешними устройствами, моделировании процессов и т.д. (тут хранение данных не есть основой самого ПО и подход к проектированию иной нежели таблица и список) тогда заморачиваться SQL`ем чтобы ускорить время реакции интерфейса с 0,0001с до 0,00009с есть нецелесообразно, а местами еще и вредно. Посему заявления, что проект априори под угрозой только потому что под Гибернейтом, смешные.

Эти заявления не связаны с производительностью. Влад имел ввиду как раз архитектуру приложений, которая диктуется применением тяжёлых ORM. H/ORM диктует архитектуру приложения, это факт. И эта архитектура рано или поздно может стать проблемным местом. Обрати внимание на посты Cyberax. Все его "а ты так можешь" — это демонстрация смекалки по обходу именно такой архитектуры приложения. Его мозг зашорен Хайбернейтом и он даже представить не может, что тоже самое можно решать не просто, а очень просто, если избавиться от диктата архитектуры со стороны используемого инструмента. И в отличии от него, я свои приложения строю так, как считаю нужным я, а не мой инструмент. А мой инструмент в моих руках всего лишь помощник, но не диктатор.

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

C>>>А что делать с аргументами? Запись в логе "изменил права доступа" мало кого интересует.
IT>>Так ты задачу поставь нормально, со всеми деталями и тогда мы её решим.
C>Нужно записать полный результат операции — что и как было изменено.

Ну 'что' я ещё могу понять, а зачем 'как'? Зачем мне знать пользователь нажал на клавиатуре Delete или выполнил аналогичную операцию мышкой?

IT>>Не переживай, не придётся. В булките есть всё, что для этого нужно (смотреть BLToolkit.EditableObjects).
C>Придётся. Во-первых, в EditableObject нет вычисления изменений (добавить несложно, согласен).

IsDirtyMember устроит?

C>Во-вторых, там нет нет трэкинга коллекций.

EditableList.IsTrackingChanges, EditableList.NewItems, EditableList.DelItems.

C>В-третьих, ВСЕ объекты нужно делать Editable.

А в NH ничего ни от чего не надо наследовать? Или там это реализовано (не могу в это поверить) сравнением с копией?

C>В-четвёртых, когда ты это всё закончишь делать — получишь Hibernate, вид сбоку.

Да делал я это всё, ещё 6 лет назад в IBM. Всё это мы проходили, было даже то, что сегодня модно именуется Unit Of Work. Было. Но очень быстро стало понятно, что подобные архитектуры — это болото, способное засосать в себя любое приложение и любого разработчика. Посмотри на себя, все твои "а ты так можешь" — это борьба против Хайбернейт во имя Хайбернейт. 6 лет назад я даже не мог подумать, что это ТАК может засасывать!

Давай пропробуем ещё раз. Попробуй вынурнуть из своего болота и подумать о том, что трекинг изменений в объекте и отображение данных из объектной модели в БД — это разные вещи, которые могут использоваться как вместе, так и раздельно. Например, трекать я могу на клиенте, а данные сохранять на сервере. Или такое для NH запрещено как ересь?

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

По чаще это повторяй. Руки лодочкой перед собой, в глазах образ святого Хайбернейта...

C>Ну ровно то же говориться про BLToolkit. Эта куча г. не позволяет нормально работать с объектным представлением, требуя везде знать детали мэппинга на БД.

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

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

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

G>Не выдумывай. Трекинг изменений в DataSet был еще в самой первой версии и он совершенно ортогонален работе с БД. То что в большинстве ORM_ов прибит гвоздями к контексту не является правильным решением.
G>Кстати в EVv4 можно отцепить трекинг от контекста.

Вот, Cyberax, послушай умного человека

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

C>>Нужно записать полный результат операции — что и как было изменено.
IT>Ну 'что' я ещё могу понять, а зачем 'как'? Зачем мне знать пользователь нажал на клавиатуре Delete или выполнил аналогичную операцию мышкой?
Для анализа в случае проблем.

C>>Придётся. Во-первых, в EditableObject нет вычисления изменений (добавить несложно, согласен).
IT>IsDirtyMember устроит?
Даже близко не устроит.

C>>Во-вторых, там нет нет трэкинга коллекций.
IT>EditableList.IsTrackingChanges, EditableList.NewItems, EditableList.DelItems.
Вот теперь то же самое для всех коллекций, с правильными каскадами. Как только оно всё заработает — ты уже почти полностью напишешь классическую ORM.

C>>В-третьих, ВСЕ объекты нужно делать Editable.
IT>А в NH ничего ни от чего не надо наследовать?
Ничего не надо.

IT>Или там это реализовано (не могу в это поверить) сравнением с копией?
Ага, именно сравнением с копией.

C>>В-четвёртых, когда ты это всё закончишь делать — получишь Hibernate, вид сбоку.
IT>Да делал я это всё, ещё 6 лет назад в IBM. Всё это мы проходили, было даже то, что сегодня модно именуется Unit Of Work. Было. Но очень быстро стало понятно, что подобные архитектуры — это болото, способное засосать в себя любое приложение и любого разработчика. Посмотри на себя, все твои "а ты так можешь" — это борьба против Хайбернейт во имя Хайбернейт. 6 лет назад я даже не мог подумать, что это ТАК может засасывать!
Нет, это просто вы неправильно там в IBM всё делали. Засасывающего тут только простота использования — создаёшь объект, добавляешь куда надо, и забываешь про него. Оно всё там дальше само сделает.

IT>Давай пропробуем ещё раз. Попробуй вынурнуть из своего болота и подумать о том, что трекинг изменений в объекте и отображение данных из объектной модели в БД — это разные вещи, которые могут использоваться как вместе, так и раздельно. Например, трекать я могу на клиенте, а данные сохранять на сервере. Или такое для NH запрещено как ересь?
Блин, в третий раз уже говорю, что клиент вообще не держит связи с БД. Более того, он и не может его держать — иначе ему на каждый чих придётся мегабайты данных гонять.

C>>Ну ровно то же говориться про BLToolkit. Эта куча г. не позволяет нормально работать с объектным представлением, требуя везде знать детали мэппинга на БД.
IT>Я тебе уже один раз предложил сравнить выразительность этих двух куч г на вполне конкретной задаче. Но видимо твоё профессиональное эго на это пойтить никак не может.
Я не вижу в чём "выразительность" BLToolkit'а. В том, что он всегда заставляет работать с SQL (кроме примитивных взятий объекта по ID)?

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

IT>>Давай пропробуем ещё раз. Попробуй вынурнуть из своего болота и подумать о том, что трекинг изменений в объекте и отображение данных из объектной модели в БД — это разные вещи, которые могут использоваться как вместе, так и раздельно. Например, трекать я могу на клиенте, а данные сохранять на сервере. Или такое для NH запрещено как ересь?
C>Блин, в третий раз уже говорю, что клиент вообще не держит связи с БД. Более того, он и не может его держать — иначе ему на каждый чих придётся мегабайты данных гонять.

Причем тут связь с БД? Трекать изменения данных можно (и нужно) без БД.
ADO.NET Data Services вполне умеет трекать изменения на клиенте при этом поддерживается маппинг и Linq.

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

G>EF конечно преобретает возможности H/ORM, но это не означает что надо эти возможности использовать.

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

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

G>Ну это уже есть. Список StateEntry.

Что это такое?

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

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

G>>EF конечно преобретает возможности H/ORM, но это не означает что надо эти возможности использовать.

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

VD>Так что если EF планировался как универсальная технология которая позволяет работать как только запросами, так и в стиле персистентности объектов, то надо было вводить режимы которые позволяли бы четко отделить эти возможности друг от друга. Как вариант можно было бы реализовать персистентость объектов на основе строготипзированных объектов. Тогда конфликтов можно было бы избежать.
А сейчас как?

G>>Ну это уже есть. Список StateEntry.
VD>Что это такое?
http://msdn.microsoft.com/ru-ru/library/system.data.objects.objectstateentry.aspx

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

IT>>Ну 'что' я ещё могу понять, а зачем 'как'? Зачем мне знать пользователь нажал на клавиатуре Delete или выполнил аналогичную операцию мышкой?
C>Для анализа в случае проблем.

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

C>>>Придётся. Во-первых, в EditableObject нет вычисления изменений (добавить несложно, согласен).
IT>>IsDirtyMember устроит?
C>Даже близко не устроит.

Тогда что ты подразумеваешь под вычислением изменений?

C>>>Во-вторых, там нет нет трэкинга коллекций.
IT>>EditableList.IsTrackingChanges, EditableList.NewItems, EditableList.DelItems.
C>Вот теперь то же самое для всех коллекций, с правильными каскадами. Как только оно всё заработает — ты уже почти полностью напишешь классическую ORM.

Ты о чём? Ты просил треккинг, получи. Если ты хочешь получать уведомления, подписывайся и получай.

IT>>Или там это реализовано (не могу в это поверить) сравнением с копией?
C>Ага, именно сравнением с копией.

Пипец! И эти люди запрещают мне наследоваться от IEditable

C>Нет, это просто вы неправильно там в IBM всё делали. Засасывающего тут только простота использования — создаёшь объект, добавляешь куда надо, и забываешь про него. Оно всё там дальше само сделает.

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

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

А при чём тут тогда NH?

C>Я не вижу в чём "выразительность" BLToolkit'а. В том, что он всегда заставляет работать с SQL (кроме примитивных взятий объекта по ID)?

Как я понял, про Linq в NH пока лучше помолчать. Если так, то чем HQL лучше?

var query = session.CreateCriteria<Simplest>().Add(Expression.Eq("Id",(long)id));

Это конечно сильно? Офигенно читабельно и главное почти так же типобезопасно как и plain SQL. Уж лучше SQL:

SELECT * FROM Simplest WHERE Id = @id

Как минимум не надо глаза ломать что там у нас Eq или что-то ещё.

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

G>лучше обучать разработчиков, а не оберегать их от возможных проблем.

Не. Лучше не создавать условий для проблем, чем обучать разработчиков тому где разложены грабли.
Почему-то в случае с языком (ты же не пишешь бизнес-приложения на С++?) тебе это понятно. А в случае с фрэймворком — нет.

VD>>Так что если EF планировался как универсальная технология которая позволяет работать как только запросами, так и в стиле персистентности объектов, то надо было вводить режимы которые позволяли бы четко отделить эти возможности друг от друга. Как вариант можно было бы реализовать персистентость объектов на основе строготипзированных объектов. Тогда конфликтов можно было бы избежать.
G>А сейчас как?

Что как? EF? Сейчас EF вообще мало на что пригодна.

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

IT>Эти заявления не связаны с производительностью. Влад имел ввиду как раз архитектуру приложений, которая диктуется применением тяжёлых ORM. H/ORM диктует архитектуру приложения, это факт. И эта архитектура рано или поздно может стать проблемным местом. Обрати внимание на посты Cyberax. Все его "а ты так можешь" — это демонстрация смекалки по обходу именно такой архитектуры приложения. Его мозг зашорен Хайбернейтом и он даже представить не может, что тоже самое можно решать не просто, а очень просто, если избавиться от диктата архитектуры со стороны используемого инструмента. И в отличии от него, я свои приложения строю так, как считаю нужным я, а не мой инструмент. А мой инструмент в моих руках всего лишь помощник, но не диктатор.

За пост +1. Заставляет задуматься, но... подскажи тогда ...
Вот я с 5 класса писал программы на паскале, потом Си потом... чего там только не было. С ростом сложности програм меня всегда мучала мысль — как написать красивое и масштабируемое приложение. Думаю грабли у всех одни и те же: процедуры/функции, затем ООП, затем патерны. Вдруг я понял что сценарий транзакции или шлюз таблицы хорош только в примитивных приложениях (ИМХО!!!). На сегодняшний день я не нашел более действенного метода нежели Domain Driven Design. Поэтому диктат тут не орээмами а методологией.
Скажи пожалуйста — какой фундамент у твоих разработок? Строишь ли десктоповые приложения?

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

VD>Но при этом не ясно зачем вообще нужен гибернэйт и СУБД. Ведь тогда граф объектов проще сериализовать в ХМЛ или бинарную форму и записать в файл. Разве что ли для того, чтобы организовать не очень многопользовательское решение от которого не будет требоваться высокой масштабируемости, параллелизма и

VD>Если же планируется создавать многопользовательское решение, то предложенная модель будет намного лучше.

10-30 зверей, которые не жмакают по клавиатуре 1000 нажатий в секунду — работают вдумчиво. Толстые и тонкие клиенты — во всех случаях Хибернейта хватало.

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

А>Скажи пожалуйста — какой фундамент у твоих разработок?

В отличии от ООП, который придуман интуитивно тут имеется реальная мат.модель.

http://ru.wikipedia.org/wiki/Реляционная_алгебра
http://ru.wikipedia.org/wiki/Алгебра_Кодда
http://ru.wikipedia.org/wiki/ER-модель_данных

Ну, и конечно http://ru.wikipedia.org/wiki/Лямбда-исчисление как база для LINQ и функциональной обработки списков.

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

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

G>>лучше обучать разработчиков, а не оберегать их от возможных проблем.

VD>Не. Лучше не создавать условий для проблем, чем обучать разработчиков тому где разложены грабли.
Это не грабли.

VD>Почему-то в случае с языком (ты же не пишешь бизнес-приложения на С++?) тебе это понятно. А в случае с фрэймворком — нет.
В некоторых случаях нужет и трекинг, и персистентные объекты (например в n-tier). Даже препоганейший lazy load довольно неплохо работает на enmedded DB в десктопных сценариях.
Так что совсем убирать эти возможности я бы не стал, плучше большинство из них сделать выключенными по-умолчанию.
Например в EFv4 LL по-умолчанию выключен. Если бы там была возможнсть использовать DML, то можно было бы и трекинг выключить по-умолчанию.

VD>>>Так что если EF планировался как универсальная технология которая позволяет работать как только запросами, так и в стиле персистентности объектов, то надо было вводить режимы которые позволяли бы четко отделить эти возможности друг от друга. Как вариант можно было бы реализовать персистентость объектов на основе строготипзированных объектов. Тогда конфликтов можно было бы избежать.
G>>А сейчас как?
VD>Что как? EF? Сейчас EF вообще мало на что пригодна.
Тем не менее у сеня вполне нормально работает, даже с большой нагрузкой.

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

IT>Как я понял, про Linq в NH пока лучше помолчать. Если так, то чем HQL лучше?

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

IT>

var query = session.CreateCriteria<Simplest>().Add(Expression.Eq("Id",(long)id));

IT>Это конечно сильно? Офигенно читабельно и главное почти так же типобезопасно как и plain SQL. Уж лучше SQL:

Ну это не HQL

Это CriteriaAPI, его кто-то уже экспрешенами кстати облагородил. В стиле

session.CreateCriteria<Simplest>().Add(s => s.ID == id)

.

HQL это почти полный аналог SQL, с упрощеным синтаксисом джойнов. Т.е. запрос пишется также
как на сиквеле, но лаконичнее.

session.CreateQuery("from Simplest where id=:id").SetParameter("id", id)

Это лучше чем SQL, но сильно хуже линка.

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

Как можно убрать маппинг коллекций и оставить такую же понятную запись?

from u in Users
where u.Departments.Any(d => d.Type == type)
select u.Operations.Sum(o => o.Amount);

На HQL кстати будет такая же по понятности, но без контроля компилятора.

Да, у хибера серьезные проблемы с производительностью, но как инструмент по борбе со сложностью модели он пока не имеет равных.

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

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

IT>

var query = session.CreateCriteria<Simplest>().Add(Expression.Eq("Id",(long)id));

IT>Это конечно сильно? Офигенно читабельно и главное почти так же типобезопасно как и plain SQL. Уж лучше SQL:

Кстати, глянул новый CriteriaAPI, там это выглядит так:

session.QueryOver<Simplest>().Where(s => s.Id == id)

Сходство с линком правда лишь внешнее.

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

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

C>>Для анализа в случае проблем.
IT>Тебе так важно нажал пользователь кнопку или повозил по экрану мышкой? А скриншотик ты на всякий случай не сохраняешь? И запись с вебкамеры за последние 10 минут работы пользователя тоже очень могут помочь.
Скриншоты сохраняются в случае необработанного исключения и автоматически добавляются к баге в Jira.

Действия в аудите обычно сложнее, чем "нажал кнопку". К примеру: "добавил роль XXX в организации YYY к пользователю ZZZ, вступающую в действие начиная с aa.bb.20cc dd:ee".

C>>>>Придётся. Во-первых, в EditableObject нет вычисления изменений (добавить несложно, согласен).
IT>>>IsDirtyMember устроит?
C>>Даже близко не устроит.
IT>Тогда что ты подразумеваешь под вычислением изменений?
В смысле, что это такая микроскопическая часть, что о ней говорить смешно.

C>>Вот теперь то же самое для всех коллекций, с правильными каскадами. Как только оно всё заработает — ты уже почти полностью напишешь классическую ORM.
IT>Ты о чём? Ты просил треккинг, получи. Если ты хочешь получать уведомления, подписывайся и получай.
Объясняю ещё раз. Мне нужен трекинг ВСЕХ изменений. Без необходимости делать кучу шаманств. Так вот, если его сделать — ты получишь классическую ORM.

C>>Нет, это просто вы неправильно там в IBM всё делали. Засасывающего тут только простота использования — создаёшь объект, добавляешь куда надо, и забываешь про него. Оно всё там дальше само сделает.
IT>Ну да. Оно там всё само делает только в примитивных, заранее определённых сценариях и в демках. А чтобы сделать простой аудит нужно попрыгать вприсядку вокруг костра с бубном.
Угу, а у тебя написать на ассемб^W Булките пару сотенок килобайт.

C>>Блин, в третий раз уже говорю, что клиент вообще не держит связи с БД. Более того, он и не может его держать — иначе ему на каждый чих придётся мегабайты данных гонять.
IT>А при чём тут тогда NH?
А что ты думаешь на сервере работает?

C>>Я не вижу в чём "выразительность" BLToolkit'а. В том, что он всегда заставляет работать с SQL (кроме примитивных взятий объекта по ID)?
IT>Как я понял, про Linq в NH пока лучше помолчать. Если так, то чем HQL лучше?
В Hibernate есть killer feature (правда, при неправильном использовании и для производительности) — навигационный доступ. Который позволяет свести к минимуму число явных запросов вообще.

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

C>>Блин, в третий раз уже говорю, что клиент вообще не держит связи с БД. Более того, он и не может его держать — иначе ему на каждый чих придётся мегабайты данных гонять.
G>Причем тут связь с БД? Трекать изменения данных можно (и нужно) без БД.
G>ADO.NET Data Services вполне умеет трекать изменения на клиенте при этом поддерживается маппинг и Linq.
Изменения не на клиенте происходят.

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

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

C>>>Блин, в третий раз уже говорю, что клиент вообще не держит связи с БД. Более того, он и не может его держать — иначе ему на каждый чих придётся мегабайты данных гонять.
G>>Причем тут связь с БД? Трекать изменения данных можно (и нужно) без БД.
G>>ADO.NET Data Services вполне умеет трекать изменения на клиенте при этом поддерживается маппинг и Linq.
C>Изменения не на клиенте происходят.
Ну тогда еще проще: батч запросов + last modified. И в принципе становится пофиг какой ORM.

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

C>>>>Блин, в третий раз уже говорю, что клиент вообще не держит связи с БД. Более того, он и не может его держать — иначе ему на каждый чих придётся мегабайты данных гонять.
G>>>Причем тут связь с БД? Трекать изменения данных можно (и нужно) без БД.
G>>>ADO.NET Data Services вполне умеет трекать изменения на клиенте при этом поддерживается маппинг и Linq.
C>>Изменения не на клиенте происходят.
G>Ну тогда еще проще: батч запросов + last modified. И в принципе становится пофиг какой ORM.
Блин, в четвёртый раз уже говорю, что клиент вообще не держит связи с БД. Более того, он и не может его держать — иначе ему на каждый чих придётся мегабайты данных гонять.

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

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

C>>>>>Блин, в третий раз уже говорю, что клиент вообще не держит связи с БД. Более того, он и не может его держать — иначе ему на каждый чих придётся мегабайты данных гонять.
G>>>>Причем тут связь с БД? Трекать изменения данных можно (и нужно) без БД.
G>>>>ADO.NET Data Services вполне умеет трекать изменения на клиенте при этом поддерживается маппинг и Linq.
C>>>Изменения не на клиенте происходят.
G>>Ну тогда еще проще: батч запросов + last modified. И в принципе становится пофиг какой ORM.
C>Блин, в четвёртый раз уже говорю, что клиент вообще не держит связи с БД. Более того, он и не может его держать — иначе ему на каждый чих придётся мегабайты данных гонять.
При чем тут связь с БД?

Клиент регулярно дергает сервер с запросом: дай мне список изменений с даты last_modified с таким-то предикатом.
Вернее с батч таких запросов по всем коллекциям.

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

C>>Блин, в четвёртый раз уже говорю, что клиент вообще не держит связи с БД. Более того, он и не может его держать — иначе ему на каждый чих придётся мегабайты данных гонять.
G>При чем тут связь с БД?
G>Клиент регулярно дергает сервер с запросом: дай мне список изменений с даты last_modified с таким-то предикатом.
G>Вернее с батч таких запросов по всем коллекциям.
Несерьёзно. См. что я там написал.

Это придётся клиентам по всем таблицам всё время запросы делать. С пост-обработкой результатов с учётом ACL.

В общем, не жилец этот вариант.

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

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

C>>>Блин, в четвёртый раз уже говорю, что клиент вообще не держит связи с БД. Более того, он и не может его держать — иначе ему на каждый чих придётся мегабайты данных гонять.
G>>При чем тут связь с БД?
G>>Клиент регулярно дергает сервер с запросом: дай мне список изменений с даты last_modified с таким-то предикатом.
G>>Вернее с батч таких запросов по всем коллекциям.
C>Несерьёзно. См. что я там написал.
Помоему вполне нормально.

C>Это придётся клиентам по всем таблицам всё время запросы делать.
Ну если батчить запросы, то все ОК. Теб более что большинство из них не будет ничего возвращать.

C>С пост-обработкой результатов с учётом ACL.
С пост-обработкой — действительно несерьезно, а вот с навешиванием дополнительного предиката, в зависимости от ACL — вполне нормально.

C>В общем, не жилец этот вариант.
Очень даже жилец. И как раз с BLToolkit такой вариант проще всего сделать.

Хотя мне не нравится сама идея держать на клиенте мегабайт данных и их обновлять их постоянно.

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

C>>Это придётся клиентам по всем таблицам всё время запросы делать.
G>Ну если батчить запросы, то все ОК. Теб более что большинство из них не будет ничего возвращать.
См. ниже.

C>>С пост-обработкой результатов с учётом ACL.
G>С пост-обработкой — действительно несерьезно, а вот с навешиванием дополнительного предиката, в зависимости от ACL — вполне нормально.
Уже третий раз говорю, что оно невозможно. Или потребует таких извращений на уровне БД, что Hibernate будет цветочками.

C>>В общем, не жилец этот вариант.
G>Очень даже жилец. И как раз с BLToolkit такой вариант проще всего сделать.
Сейчас у меня 800 сущностей. Ты хочешь, чтобы по восьмистам таблицам тысяча клиентов одновременно постоянно выполняла запросы?

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

Сколько серверов в твоём случае потребуется? Скажи, ты продаёшь суперкомпьютеры?

G>Хотя мне не нравится сама идея держать на клиенте мегабайт данных и их обновлять их постоянно.
Их там около 30 мегабайт.

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

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

C>>>Это придётся клиентам по всем таблицам всё время запросы делать.
G>>Ну если батчить запросы, то все ОК. Теб более что большинство из них не будет ничего возвращать.
C>См. ниже.

C>>>С пост-обработкой результатов с учётом ACL.
G>>С пост-обработкой — действительно несерьезно, а вот с навешиванием дополнительного предиката, в зависимости от ACL — вполне нормально.
C>Уже третий раз говорю, что оно невозможно. Или потребует таких извращений на уровне БД, что Hibernate будет цветочками.
Ну покажи чтоли что у тебя там за система такая с ACL.

C>>>В общем, не жилец этот вариант.
G>>Очень даже жилец. И как раз с BLToolkit такой вариант проще всего сделать.
C>Сейчас у меня 800 сущностей. Ты хочешь, чтобы по восьмистам таблицам тысяча клиентов одновременно постоянно выполняла запросы?
А сейчас как клиенты узнают об изменениях?
Ты же говорил что у тебя веб. Значит делают запросы.

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

C>Сколько серверов в твоём случае потребуется?
Думаю что один + сервер БД.

C>Скажи, ты продаёшь суперкомпьютеры?
Нет.

G>>Хотя мне не нравится сама идея держать на клиенте мегабайт данных и их обновлять их постоянно.
C>Их там около 30 мегабайт.
"Там" это где? Ты передаешь по 30 мб данных на клиентов? А что они с ними делают?
Человеку никак нереально просмотреть такой объем в разумные сроки.

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

G> Даже препоганейший lazy load довольно неплохо работает на enmedded DB в десктопных сценариях.
А можно просветить почему lazy load "препоганейший"??

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

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

G>> Даже препоганейший lazy load довольно неплохо работает на enmedded DB в десктопных сценариях.
А>А можно просветить почему lazy load "препоганейший"??

Простой пример. Есть пользователи и группы, связаны один-ко-многим. Связанные группы подгружаются с помощью LL.

foreach(var user in users)
{
    Console.WriteLine(user.Name);
    foreach(var group in user.Groups)
    {
        Console.WriteLine("    " + group.Name);
    }
}

Посчитай сколько запросов к базе будет.
Хотя достаточно одного джоина.

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

В случае embedded DB LL оправдан, так как чаще всего эти операции приводят к обращениям к памяти самого процесса, поэтому нет затрат на пересечение границ процессов и количество вызовов роли почти не играет.

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

C>>Уже третий раз говорю, что оно невозможно. Или потребует таких извращений на уровне БД, что Hibernate будет цветочками.
G>Ну покажи чтоли что у тебя там за система такая с ACL.
Есть организации, и пользователь может работать в нескольких организациях. Организации объединены в иерархии, внутри каждой организации ещё и набор иерархических ролей.

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

G>>>Очень даже жилец. И как раз с BLToolkit такой вариант проще всего сделать.
C>>Сейчас у меня 800 сущностей. Ты хочешь, чтобы по восьмистам таблицам тысяча клиентов одновременно постоянно выполняла запросы?
G>А сейчас как клиенты узнают об изменениях?
Им они присылаются сервером.

G>Ты же говорил что у тебя веб. Значит делают запросы.
Где я говорил про веб? У меня "толстый клиент" на основе WebStart.

C>>Сколько серверов в твоём случае потребуется?
G>Думаю что один + сервер БД.
Не хватит. 800*1000 = 800000 запросов где-то в 5 секунд. Что-то многовато. Даже если оптимизировать (не запрашивать каждый раз всё), то всё равно нагрузка будет очень нехилая.

G>>>Хотя мне не нравится сама идея держать на клиенте мегабайт данных и их обновлять их постоянно.
C>>Их там около 30 мегабайт.
G>"Там" это где? Ты передаешь по 30 мб данных на клиентов? А что они с ними делают?
Смотрят.

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

Можно было бы вынести на сервер кое-что, но тогда многие операции выполнялись бы не мгновенно, а с многосекундной задержкой (на передачу результатов).

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

G>Посчитай сколько запросов к базе будет.
G>Хотя достаточно одного джоина.

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

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

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

А>>А можно просветить почему lazy load "препоганейший"??
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>Хотя достаточно одного джоина.

Просто справедливости ради замечу, что проблема здесь вовсе не в самом LL, а в том как он используется.
При желании можно заставить тот же Hiberante загрузить пользователя с его группами как раз за один селект c джойном, хотя есть и другие достаточно эффективные способы загрузки коллекций.
Вот например (Join fetching): http://docs.jboss.org/hibernate/core/3.3/reference/en/html/performance.html#performance-fetching

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

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

C>>>Уже третий раз говорю, что оно невозможно. Или потребует таких извращений на уровне БД, что Hibernate будет цветочками.
G>>Ну покажи чтоли что у тебя там за система такая с ACL.
C>Есть организации, и пользователь может работать в нескольких организациях. Организации объединены в иерархии, внутри каждой организации ещё и набор иерархических ролей.
Ну так а сами ACL как выглядят?

C>Объекты могут принадлежать одновременно нескольким иерархиям, причём их набор может меняться во время жизни объекта.

G>>>>Очень даже жилец. И как раз с BLToolkit такой вариант проще всего сделать.
C>>>Сейчас у меня 800 сущностей. Ты хочешь, чтобы по восьмистам таблицам тысяча клиентов одновременно постоянно выполняла запросы?
G>>А сейчас как клиенты узнают об изменениях?
C>Им они присылаются сервером.

G>>Ты же говорил что у тебя веб. Значит делают запросы.
C>Где я говорил про веб? У меня "толстый клиент" на основе WebStart.

Ну если так — тогда еще проще. Все изменения которые происходят прогоняются через механизм разрешений, и отправляются клиентам в них нуждающимся.
Это вообще ортогонально доступу к данным получается. И через АОР прикручивается.

C>>>Сколько серверов в твоём случае потребуется?
G>>Думаю что один + сервер БД.
C>Не хватит. 800*1000 = 800000 запросов где-то в 5 секунд. Что-то многовато. Даже если оптимизировать (не запрашивать каждый раз всё), то всё равно нагрузка будет очень нехилая.
ну с чего ты взял что 800 запросов будет. Будет один батч от одного клиента, всего максимум 200 запросов в секунду, большая часть запросов даже до БД не дойдет так как метки последнего изменения будут закешированы на сервере.

G>>>>Хотя мне не нравится сама идея держать на клиенте мегабайт данных и их обновлять их постоянно.
C>>>Их там около 30 мегабайт.
G>>"Там" это где? Ты передаешь по 30 мб данных на клиентов? А что они с ними делают?
C>Смотрят.
И что это за данные? Даже если картинки — это очень много.
Что показывается пользователю в итоге?

G>>Человеку никак нереально просмотреть такой объем в разумные сроки.
C>Речь идёт не о табличных данных. Например, нужна способность смотреть данные по расписанию для определённого департамента для планирования события, причём для планирования нужно учитывать, чтоб не было overtime'а. Это выглядит для пользователя очень безобидно, но внутри требует перелопатить кучу данных.
Ну так и пусть данные лопаятся средствами сервера, бд, OLAP системы, а пользователю отдается конечный результат.

C>Можно было бы вынести на сервер кое-что, но тогда многие операции выполнялись бы не мгновенно, а с многосекундной задержкой (на передачу результатов).
Какие задержки на передачу результатов? Передать картинку размером с экран (около 200 кб) через интернет — дело десяти секунд. А реально данных для отображения будет на порядок меньше.

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

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

G>>Посчитай сколько запросов к базе будет.
G>>Хотя достаточно одного джоина.

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

А>Идею понял.
А>Мне кажется, что описанная проблема это ошибки дизайна, а не LL.
LL и есть ошибка дизайна в большинстве случаев.
Явная загрузка данных из БД всегда рулит, но она нарушет "красоту" ООП.

А>Тоесть, вышеописанную ситуацию можно обернуть в какой нить класс, который при первом обращении к коллекции груп делают тот же самый запрос с джоином.
А>Это просто мысли. Я могу и ошибаться.

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

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

G>

G>var q = from u in users
G>        select new {u.Name, Groups = u.Groups.Select(g => new {g.Name})};
G>

G>И получит только необходимые данные ровно одним запросом.

EF точно так умеет? Это некислая оптимизация, дровишки проверенные?

Кстати, маппинг коллекций вроде как был считался признаком H/ORM, или без LL не считается?
Так без LL можно и хибер настроить.

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

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

foreach(var user in db.Users.Select(u => new { u.Id, u.Name }))
{
    Console.WriteLine(user.Name);
    foreach(var ug in db.UserToGroup().Where(ug => ug.UserId == user.Id)).Select(ug => ug.GroupId))
    {
        var group = db.Groups.Where(g => g.Id == ug.GroupId).Single();
        Console.WriteLine("    " + group.Name);
    }
}

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

Здравствуйте, 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 столбца. Сам умножишь?

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

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

Здравствуйте, 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>А у меня благодаря поддержанию когерентности данных на клиентах и сервере можно делать кучу интересных вещей. Скажем, анализ типа "а что если?".
Это ты о чем?

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

почитал топик и ей богу не пойму как мне на вопрос ответить — а зачем тогда на SL чето мучацца писать если есть стандартные клиентские апликухи и их доставка через IIS?
По сути программирование на SL превратилось из программирования ActiveXа для страницек в написание самостоятельных приложений причем получите дополнительно тонны геморроя и кучу багов — таки зачем нам это все?

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

После переквалификации под ASP.NET сплю спокойно — наработанные технологии, все просто и понятно и глюки уже все давно повычищены, и Вам рекомендую то же )))

ну а у кого азарата много или ради любопытства — пожалуйста- SL и WPF Вам в руки!

Здравствуйте, 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 оправдан, так как чаще всего эти операции приводят к обращениям к памяти самого процесса, поэтому нет затрат на пересечение границ процессов и количество вызовов роли почти не играет.

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

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

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

А класс то тут зачем? Вот налепливание классов в подобных ситуациях (и циклов, впрочем тоже) и есть ошибка дизайна. Сам же сказал "нужен джоин". Ну, так за чем дело встало?

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

VD>>Не. Лучше не создавать условий для проблем, чем обучать разработчиков тому где разложены грабли.
G>Это не грабли.

Ну, ну. Разубеждать тебя не буду. Сам со временем осознаешь.

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

Здравствуйте, 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 точно так умеет? Это некислая оптимизация, дровишки проверенные?

Блин, ёлы-палы. Так может любой 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>а мыслящий реляционными понятиями и в хибере выберет все что нужно одним запросом.

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

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

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

Здравствуйте, <Аноним>, Вы писали:

А>почитал топик и ей богу не пойму как мне на вопрос ответить — а зачем тогда на SL чето мучацца писать если есть стандартные клиентские апликухи и их доставка через IIS?
А>По сути программирование на SL превратилось из программирования ActiveXа для страницек в написание самостоятельных приложений причем получите дополнительно тонны геморроя и кучу багов — таки зачем нам это все?

Ну выше yorick назвал главную причину: современный WEB2 ето букет из технологий и языков программирования, помноженный на количество версий/спецификаций/стандартов + особенности реализаций броузеров. Во всем етом надо шарить, изучать приемы / подходы / рецепты / инструменты — вообщем нудно и так сразу не поедешь, возникает естественное желание чиста взять спортивный супер-кар от Microsoft в лице Silverlight-а и ай-да педаль газа под коврик

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

А так в принципе покататься рекомендую — ето местами захватывающе и действительно на SL можно делать такие вещи, что waauuuu

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

VD>Ну, а зачем же проламываться сквозь объекты чтобы понять как этот гичер там себе эти объекты в реляцию превращает? Не проще ли когда и система и программист говорят на одном языке?

VD>Маразм ведь получается! Мы сначала скрываем от программиста тот факт, что данные то у нас реляционные, а потом этот программист вынужден догадываться о том как же его обманывают и подстраивать все так, чтобы все заработало.

Я рассматриваю построение модели не как способ сокрытия реляционности, а как способ создать удобный ДСЛ для запросов.

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

Здравствуйте, 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>Такой код на любой платформе будет работать оптимально и при этом код станет компактнее и понятнее (не нужно будет разглядывать тела циклов, чтобы понять, что происходит)?

Не понял, что именно сделать джоином?

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

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

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

Z>Я рассматриваю построение модели не как способ сокрытия реляционности, а как способ создать удобный ДСЛ для запросов.

Удобнее чем LINQ все равно создать не получится. Так что ты прост делаешь бессмысленную работу.

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

G>Linq2SQL так не умеет вроде.

С чего бы это?

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

G>Не понял, что именно сделать джоином?

Выборку данных.

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

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

G>>Linq2SQL так не умеет вроде.

VD>С чего бы это?

Надо бы проверить, но я как-то раз нарывался на то что linq-подзапросы с linq2sql выполняются отдельными запросами.

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

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

G>>Не понял, что именно сделать джоином?

VD>Выборку данных.

Я же и говорю что явный джоин гораздо лучше LL.

А проблема SELECT N+1 в основном не так явно выглядит.
Обычно что-то в этом роде:

public class Order
{
    //LLCollection не IQueryable, поэтому при ленивой загрузке вытягиваются полные объекты
    public LLCollection<OrderLine> OrderLines { get; }

    public decimal Total
    {
        get
        {
            return OrderLines.Sum(l => l.Price * l.Quantity);
        }
    }
}

//в другом методе, в другой сборке, написанной другим человеком
...
var orders = dal.GetSomeOrders(...)
var sum = orders.Sum(o => o.Total);   
...

Ну вот как-то так.

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

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

Z>>Я рассматриваю построение модели не как способ сокрытия реляционности, а как способ создать удобный ДСЛ для запросов.

VD>Удобнее чем LINQ все равно создать не получится. Так что ты прост делаешь бессмысленную работу.

Так LINQ прикручивают к гибернейту и если год назад я утверждал, что та реализация тупиковая, то сейчас вижу нормальное решение.
А год назад не было альтернатив с поддержкой линка для нормального построения модели под требуемые нам СУБД.
Впрочем и сейчас тулкит в продакшен пускать рисковано.

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

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

G>

G>public class Order
G>{
G>    //LLCollection не IQueryable, поэтому при ленивой загрузке вытягиваются полные объекты
G>    public LLCollection<OrderLine> OrderLines { get; }

G>    public decimal Total
G>    {
G>        get
G>        {
G>            return OrderLines.Sum(l => l.Price * l.Quantity);
G>        }
G>    }
G>}

G>//в другом методе, в другой сборке, написанной другим человеком
G>...
G>var orders = dal.GetSomeOrders(...)
G>var sum = orders.Sum(o => o.Total);   
G>...
G>

G>Ну вот как-то так.

Если GetSomeOrders возвращает запрос, то они просто сокомбинируются и в результате получится единый запрос который будет оптимизирован SQL-сервером.

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

VD>>Удобнее чем LINQ все равно создать не получится. Так что ты прост делаешь бессмысленную работу.

Z>Так LINQ прикручивают к гибернейту и если год назад я утверждал, что та реализация тупиковая, то сейчас вижу нормальное решение.
Z>А год назад не было альтернатив с поддержкой линка для нормального построения модели под требуемые нам СУБД.
Z>Впрочем и сейчас тулкит в продакшен пускать рисковано.

Допишет до коныа, отладит и будет все ОК. Кибернэйт пока что тоже полноценно LINQ не поддерживает.

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

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

G>>

G>>public class Order
G>>{
G>>    //LLCollection не IQueryable, поэтому при ленивой загрузке вытягиваются полные объекты
G>>    public LLCollection<OrderLine> OrderLines { get; }

G>>    public decimal Total
G>>    {
G>>        get
G>>        {
G>>            return OrderLines.Sum(l => l.Price * l.Quantity);
G>>        }
G>>    }
G>>}

G>>//в другом методе, в другой сборке, написанной другим человеком
G>>...
G>>var orders = dal.GetSomeOrders(...)
G>>var sum = orders.Sum(o => o.Total);   
G>>...
G>>

G>>Ну вот как-то так.

VD>Если GetSomeOrders возвращает запрос, то они просто сокомбинируются и в результате получится единый запрос который будет оптимизирован SQL-сервером.
Нет, потому что вычисление тотала не будет распознано.
Кроме того начитавшись фаулера люди пишут DAL, возвращающий коллекции объектов, а не IQueryable.

Я аналогичный код видел в одном проекте.

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

G>Нет, потому что вычисление тотала не будет распознано.

Это почему же?
Да и на крайняк должна быть ошибка типизации.

G>Кроме того начитавшись фаулера люди пишут DAL, возвращающий коллекции объектов, а не IQueryable.

Это, да.

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

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

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

G>>Нет, потому что вычисление тотала не будет распознано.

VD>Это почему же?
Ну потому что тотал возвращает decimal. Для получения внутреностей придется IL разбирать.

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

C>>Можно. Но в UDF это делается уродливо. Проходили уже, первая версия ровно так и работала — делался row-level security в Оракульной БД.
C>>Оно в итоге под своим весом всё упало.
G>Я же и говорю — кешировать надо.
А ты думаешь это так просто?

C>>На клиенте данные не фильтруются (я идиот, что ли?)
G>А где фильтруются? Ты же говорил что обработка не ложится на SQL...
G>Или я что-то не так понял.
На сервере перед выдачей клиенту, специальным кодом. На практике, отфильтровывается не так много объектов, так что даже особо не оптимизировали изначальное получение данных.

C>>О, так у нас уже всё через определённый слой идёт? И никаких массовых update'ов нет?
G>Если есть массовые апдейты, то вмето конкретного ключа можно получить предикат на выборку нужных записей.
G>Но я сейчас EF использую, у него с массовыми операциям совсем плохо.
Предикат будет работать и на клиенте?

C>>Так поздравляю, ты почти написал H/ORM! Ещё чуть-чуть, и оно будет готово.
G>

Ну если пара сотен строк кода для реализации такого функционала — H/ORM, то да, я написал H/ORM

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

G>>>И зачем тогда их все тянуть на клиента?
C>>А то, что ты можешь часть фильтрации делать на клиенте. Скажем, поиск по словам в таблице.
G>По каким словам, в какой таблице?
Есть у тебя таблица типа с колонками "Имя", "Адрес", "Город", "Телефон". И рядом с ней поле ввода, и если туда ввести "Jo D 123", оно найдёт запись "John Doe, Some street, Some City, (123)-13241246". Мгновенно, точнее будет искать прямо пока ты вводишь.

Чрезвычайно удобная фича.

G>>>Ну с ACL уже разобрались — вполне ложится на SQL.
C>>Не ложится.
G>Ну покажи где?
Построение иерарихй.

G>Я так понимаю что стоит создать в базе списски эффективных ACL и эффективных ролей для пользователя (например на триггерах). Тогда можно фильтровать записи на севрере прямо в запросе, без вытягивания acl из базы.
Я же говорю — получается жуть. Меняется ACL у родителя — и нужно пересчитывать кэши всех детей. Не пропуская ничего, вдобавок.

Кроме того, сейчас у меня код — database independent. И работает под PostgreSQL, Oracle и (прости Боже!) MySQL. Как такое же на триггерах сделать?

G>>>Можем еще что-нибудь разобрать, не сомневаюсь что тоже окажется нормально ложащимся на SQL.
C>>Спорим?
G>ну давай.
Товар принадлежит одной или нескольким группам (обычный many-to-many). Нужно найти все наборы групп, и вывести для них товары.

Т.е. у нас есть "Brick" в группах "Materials" и "Tools for Killers" и "Knife" в группе "Tools for Killers". Нужно вывести:
"Materials, Tools for Killers" -> "Brick"
"Tools for Killers" -> "Brick"
"Tools for Killers" -> "Knife"

Причём название группы должно быть хитро отсортировано (скажем, по весу). Последняя попытка дала килобайтный SQL-запрос. Хотя императивно оно пишется в десяток строк кода.

А ещё есть запросы со всякими running sums и delta'ами между строками...

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

G>>>Причем для последних работать эффективнее будет.
C>>Проблема с их _обновлением_.
G>Никаких проблем. last modified отлично работает.
Ты ещё скажи "SQL отлично работает". Каким образом ты будешь обновлять связные кэши?

G>>>Кроме того решение на HTTP будет неограниченно масштабироваться.
C>>А кто будет фильтровать результаты для каждого пользователя? Видимо, reverse proxy?
G>В этом случае reverse proxy не поможет. Кеш на клиенте все равно работать будет.
А как насчёт инкрементальности? Будем все 500 килобайт результатов каждого запроса перегружать пару раз в пару секунд?

В общем, ты даже и близко не понимаешь сложности задачи.

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

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

C>>>Можно. Но в UDF это делается уродливо. Проходили уже, первая версия ровно так и работала — делался row-level security в Оракульной БД.
C>>>Оно в итоге под своим весом всё упало.
G>>Я же и говорю — кешировать надо.
C>А ты думаешь это так просто?
Все равно придется писать код вычисления "эффективных ACL" и прав пользователя, причем именно в БД, чтобы не тащить кучу данных из базы.
А вызывать этот алгоритм в триггере на изменения и складывать результаты в таблицу гораздо проще.

C>>>На клиенте данные не фильтруются (я идиот, что ли?)
G>>А где фильтруются? Ты же говорил что обработка не ложится на SQL...
G>>Или я что-то не так понял.
C>На сервере перед выдачей клиенту, специальным кодом. На практике, отфильтровывается не так много объектов, так что даже особо не оптимизировали изначальное получение данных.

C>>>О, так у нас уже всё через определённый слой идёт? И никаких массовых update'ов нет?
G>>Если есть массовые апдейты, то вмето конкретного ключа можно получить предикат на выборку нужных записей.
G>>Но я сейчас EF использую, у него с массовыми операциям совсем плохо.
C>Предикат будет работать и на клиенте?
ну если надо, то да.

G>>>>И зачем тогда их все тянуть на клиента?
C>>>А то, что ты можешь часть фильтрации делать на клиенте. Скажем, поиск по словам в таблице.
G>>По каким словам, в какой таблице?
C>Есть у тебя таблица типа с колонками "Имя", "Адрес", "Город", "Телефон". И рядом с ней поле ввода, и если туда ввести "Jo D 123", оно найдёт запись "John Doe, Some street, Some City, (123)-13241246". Мгновенно, точнее будет искать прямо пока ты вводишь.
С задержкой, равной латентности сети.

G>>>>Ну с ACL уже разобрались — вполне ложится на SQL.
C>>>Не ложится.
G>>Ну покажи где?
C>Построение иерарихй.
CTE уже отменили?

G>>Я так понимаю что стоит создать в базе списски эффективных ACL и эффективных ролей для пользователя (например на триггерах). Тогда можно фильтровать записи на севрере прямо в запросе, без вытягивания acl из базы.
C>Я же говорю — получается жуть. Меняется ACL у родителя — и нужно пересчитывать кэши всех детей. Не пропуская ничего, вдобавок.
Да, именно так.
И часто меняется ACL сильно родительской записи? И какова глубина иерархий?

C>Кроме того, сейчас у меня код — database independent. И работает под PostgreSQL, Oracle и (прости Боже!) MySQL. Как такое же на триггерах сделать?
Писать триггеры под разные базы, тем более их довольно небольшое количество.

G>>>>Можем еще что-нибудь разобрать, не сомневаюсь что тоже окажется нормально ложащимся на SQL.
C>>>Спорим?
G>>ну давай.
C>Товар принадлежит одной или нескольким группам (обычный many-to-many). Нужно найти все наборы групп, и вывести для них товары.

C>Т.е. у нас есть "Brick" в группах "Materials" и "Tools for Killers" и "Knife" в группе "Tools for Killers". Нужно вывести:
C>"Materials, Tools for Killers" -> "Brick"
C>"Tools for Killers" -> "Brick"
C>"Tools for Killers" -> "Knife"

C>Причём название группы должно быть хитро отсортировано (скажем, по весу). Последняя попытка дала килобайтный SQL-запрос. Хотя императивно оно пишется в десяток строк кода.

EF:

var q = from p in db.Products        
        select {Product = p, Groups = p.Groups.OrderBy(g => g.Wheight)};

Вот как-то так.

C>А ещё есть запросы со всякими running sums и delta'ами между строками...
Ну это тот самый случай когда императивный код в SQL рулит.
Хотя я бы в MS SQL сложные аггрегаты делал бы с помощью CLR расширений.

C>Так что не надо считать реляционную модель концом всего. Это неплохой подход, но далеко не единственный и далеко не всегда лучший.
Как раз реляционная работа с данными — самый лучший вариант работы с данными.
Вот только некоторые простые для императивной обработки вещи в SQL потребуют correlated subquery и офигенную сложность выполнения.

G>>>>Причем для последних работать эффективнее будет.
C>>>Проблема с их _обновлением_.
G>>Никаких проблем. last modified отлично работает.
C>Ты ещё скажи "SQL отлично работает". Каким образом ты будешь обновлять связные кэши?
изменился last modified — кеш обновился.
Ты знаешь как кеширование в HTTP работает?

G>>>>Кроме того решение на HTTP будет неограниченно масштабироваться.
C>>>А кто будет фильтровать результаты для каждого пользователя? Видимо, reverse proxy?
G>>В этом случае reverse proxy не поможет. Кеш на клиенте все равно работать будет.
C>А как насчёт инкрементальности? Будем все 500 килобайт результатов каждого запроса перегружать пару раз в пару секунд?
А зачем их перезагружать? Они реально пару раз в секунду меняются?
Повысить гранулярность можно, тогда придется гораздо меньше перезагружать.

C>В общем, ты даже и близко не понимаешь сложности задачи.
Да сложность задачи я отлично понимаю.
Я вот сложности твоего решения не понимаю.

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

C>>А ты думаешь это так просто?
G>Все равно придется писать код вычисления "эффективных ACL" и прав пользователя, причем именно в БД, чтобы не тащить кучу данных из базы.
А данные всё равно будут подниматься перед выдачей их клиенту. Так что однофигственно.

G>А вызывать этот алгоритм в триггере на изменения и складывать результаты в таблицу гораздо проще.
Ничуть. Особенно приятно, что количество таблиц примерно утраивается, ну и для ACLей ещё нужно имитировать "наследование", которое в БД нормальными средствами не делается.

Я уже ходил этим путём: http://www.rsdn.ru/forum/db/2396453.flat.aspx

C>>Предикат будет работать и на клиенте?
G>ну если надо, то да.
Надо.

C>>Есть у тебя таблица типа с колонками "Имя", "Адрес", "Город", "Телефон". И рядом с ней поле ввода, и если туда ввести "Jo D 123", оно найдёт запись "John Doe, Some street, Some City, (123)-13241246". Мгновенно, точнее будет искать прямо пока ты вводишь.
G>С задержкой, равной латентности сети.
С задержкой, минимально ограниченной латентностью сети. К примеру, если пользователей порядка 2000 и у каждого из них по 3 адреса — запрос уже будет выполняться ощутимое время. А ещё учитываем время на передачу результатов. На практике оно весьма тормозно получается.

А ещё учитываем возможность использования wildcard'ов, которые замечательно убивают даже полнотекстовые индексы (которые весьма недёшевы, кстати).

В общем, пока ты будешь оптимизировать базу данных — я напишу за минуту простой линейный перебор в самом нереляционном стиле, и не буду мучаться. Он работает на клиенте доли миллисекунды без всяких оптимизаций.

C>>Построение иерарихй.
G>CTE уже отменили?
Ага. На MySQL'е, к примеру. Да и вообще они какие-то нереляционные и делают SQL полным по Тьюрингу.

C>>Я же говорю — получается жуть. Меняется ACL у родителя — и нужно пересчитывать кэши всех детей. Не пропуская ничего, вдобавок.
G>Да, именно так.
G>И часто меняется ACL сильно родительской записи? И какова глубина иерархий?
5-10 элементов. В паре вырожденных случаев около 50.

В общем, очень и очень хрупкое решение.

C>>Кроме того, сейчас у меня код — database independent. И работает под PostgreSQL, Oracle и (прости Боже!) MySQL. Как такое же на триггерах сделать?
G>Писать триггеры под разные базы, тем более их довольно небольшое количество.
Во-во. И ACLи тоже. И запросы. И можно ли всё это сделать на MySQL с его странным языком триггеров и SP? А как быть с транзакциями —

Спрашивается: ну и где наглядность L/ORM остаётся-то? Как обычно — только в теории?

C>>Причём название группы должно быть хитро отсортировано (скажем, по весу). Последняя попытка дала килобайтный SQL-запрос. Хотя императивно оно пишется в десяток строк кода.
G>EF:
G>

G>var q = from p in db.Products        
G>        select {Product = p, Groups = p.Groups.OrderBy(g => g.Wheight)};
G>

G>Вот как-то так.
Не-не. Это и я могу. Ты мне сделай так, чтоб оно список товаров выводило в том виде, в котором я его написал.

Оно реляционными методами эффективно не решается.

C>>А ещё есть запросы со всякими running sums и delta'ами между строками...
G>Ну это тот самый случай когда императивный код в SQL рулит.
G>Хотя я бы в MS SQL сложные аггрегаты делал бы с помощью CLR расширений.
Не знаю, может мне везёт, но у меня почему-то большинство таких отчётов.

C>>Так что не надо считать реляционную модель концом всего. Это неплохой подход, но далеко не единственный и далеко не всегда лучший.
G>Как раз реляционная работа с данными — самый лучший вариант работы с данными.

Скажи это Гуглу, создателям Couch DB и языка K.

G>Вот только некоторые простые для императивной обработки вещи в SQL потребуют correlated subquery и офигенную сложность выполнения.
Необязательно. Я могу взять нужные данные и руками по ним запустить обработку. На нормальном Turing-complete языке.

C>>Ты ещё скажи "SQL отлично работает". Каким образом ты будешь обновлять связные кэши?
G>изменился last modified — кеш обновился.
G>Ты знаешь как кеширование в HTTP работает?
"last modified" _на_ _что_?

C>>А как насчёт инкрементальности? Будем все 500 килобайт результатов каждого запроса перегружать пару раз в пару секунд?
G>А зачем их перезагружать? Они реально пару раз в секунду меняются?
G>Повысить гранулярность можно, тогда придется гораздо меньше перезагружать.
???
Повышаем гранулярность — и перегружаем всю "гранулу" при её изменении. Только объём увеличится.

C>>В общем, ты даже и близко не понимаешь сложности задачи.
G>Да сложность задачи я отлично понимаю.
G>Я вот сложности твоего решения не понимаю.
А нету сложности. Вся сложность в 50 килобайтах кода перехватчиков событий. И после этого оно всё автоматически.

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

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

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

C>>>А ты думаешь это так просто?
G>>Все равно придется писать код вычисления "эффективных ACL" и прав пользователя, причем именно в БД, чтобы не тащить кучу данных из базы.
C>А данные всё равно будут подниматься перед выдачей их клиенту. Так что однофигственно.
Да ну? Клиенту для отображени ясовсем немного данных надо.

G>>А вызывать этот алгоритм в триггере на изменения и складывать результаты в таблицу гораздо проще.
C>Ничуть. Особенно приятно, что количество таблиц примерно утраивается, ну и для ACLей ещё нужно имитировать "наследование", которое в БД нормальными средствами не делается.
Я говорю про таблицу для эффективных acl. Это будет 2-3 таблицы на всю базу.

C>Я уже ходил этим путём: http://www.rsdn.ru/forum/db/2396453.flat.aspx

Это совсем не тот путь.

C>>>Есть у тебя таблица типа с колонками "Имя", "Адрес", "Город", "Телефон". И рядом с ней поле ввода, и если туда ввести "Jo D 123", оно найдёт запись "John Doe, Some street, Some City, (123)-13241246". Мгновенно, точнее будет искать прямо пока ты вводишь.
G>>С задержкой, равной латентности сети.
C>С задержкой, минимально ограниченной латентностью сети. К примеру, если пользователей порядка 2000 и у каждого из них по 3 адреса — запрос уже будет выполняться ощутимое время. А ещё учитываем время на передачу результатов. На практике оно весьма тормозно получается.
Я че-то туплю. Данные уже есть на клиенте (в этой самой таблице), так что все будет моментально работать, не переживай.

C>>>Я же говорю — получается жуть. Меняется ACL у родителя — и нужно пересчитывать кэши всех детей. Не пропуская ничего, вдобавок.
G>>Да, именно так.
G>>И часто меняется ACL сильно родительской записи? И какова глубина иерархий?
C>5-10 элементов. В паре вырожденных случаев около 50.
Ну это совсем немного.

C>В общем, очень и очень хрупкое решение.
Это потому что ты не умеешь его готовить.

C>>>Кроме того, сейчас у меня код — database independent. И работает под PostgreSQL, Oracle и (прости Боже!) MySQL. Как такое же на триггерах сделать?
G>>Писать триггеры под разные базы, тем более их довольно небольшое количество.
C>Во-во. И ACLи тоже. И запросы. И можно ли всё это сделать на MySQL с его странным языком триггеров и SP? А как быть с транзакциями —
Ну не пиши по MySQL, одной беслатной БД в арсенале вполне достаточно.
Если программа работает с любой БД, то или она очень простая, или не использует возможностей БД и греет воздух.

C>Спрашивается: ну и где наглядность L/ORM остаётся-то? Как обычно — только в теории?
Наглядности станет больше — станет меньше императивного кода.

C>>>Причём название группы должно быть хитро отсортировано (скажем, по весу). Последняя попытка дала килобайтный SQL-запрос. Хотя императивно оно пишется в десяток строк кода.
G>>EF:
G>>

G>>var q = from p in db.Products        
G>>        select {Product = p, Groups = p.Groups.OrderBy(g => g.Wheight)};
G>>

G>>Вот как-то так.
C>Не-не. Это и я могу. Ты мне сделай так, чтоб оно список товаров выводило в том виде, в котором я его написал.
Большая разница чтоли?

var q = from p in db.Products        
        select {Product = p.Name, Groups = p.Groups.OrderBy(g => g.Wheight).Select(g => g.Name)};

А потом склеиваешь строки.

C>Оно реляционными методами эффективно не решается.
Что именно?
Как видишь запрос выше вполне решает. Или ты хочешь и строки склеивать в БД?

C>>>А ещё есть запросы со всякими running sums и delta'ами между строками...
G>>Ну это тот самый случай когда императивный код в SQL рулит.
G>>Хотя я бы в MS SQL сложные аггрегаты делал бы с помощью CLR расширений.
C>Не знаю, может мне везёт, но у меня почему-то большинство таких отчётов.
Тебе везет или ты что-то не так делаешь.
Ингда выгоднее хранить дельты и использовать indexed\materialized view.

C>>>Так что не надо считать реляционную модель концом всего. Это неплохой подход, но далеко не единственный и далеко не всегда лучший.
G>>Как раз реляционная работа с данными — самый лучший вариант работы с данными.
C>

C>Скажи это Гуглу, создателям Couch DB и языка K.
Couch DB — из другой оперы, там данные частично-структурированные.

G>>Вот только некоторые простые для императивной обработки вещи в SQL потребуют correlated subquery и офигенную сложность выполнения.
C>Необязательно. Я могу взять нужные данные и руками по ним запустить обработку. На нормальном Turing-complete языке.
Ну собственно тебе никто не мешает это сделать. Ты можешь посчитать аггрегаты один раз и хранить их.

C>>>Ты ещё скажи "SQL отлично работает". Каким образом ты будешь обновлять связные кэши?
G>>изменился last modified — кеш обновился.
G>>Ты знаешь как кеширование в HTTP работает?
C>"last modified" _на_ _что_?
На запрос.

C>>>А как насчёт инкрементальности? Будем все 500 килобайт результатов каждого запроса перегружать пару раз в пару секунд?
G>>А зачем их перезагружать? Они реально пару раз в секунду меняются?
G>>Повысить гранулярность можно, тогда придется гораздо меньше перезагружать.
C>???
C>Повышаем гранулярность — и перегружаем всю "гранулу" при её изменении. Только объём увеличится.
Не тупи. Высокая гранулярность — более "мелкие" гранулы.

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

C>>А данные всё равно будут подниматься перед выдачей их клиенту. Так что однофигственно.
G>Да ну? Клиенту для отображени ясовсем немного данных надо.
Опять же говорю — не немного.

C>>Ничуть. Особенно приятно, что количество таблиц примерно утраивается, ну и для ACLей ещё нужно имитировать "наследование", которое в БД нормальными средствами не делается.
G>Я говорю про таблицу для эффективных acl. Это будет 2-3 таблицы на всю базу.
Как на них констрейнты повесить?

C>>Я уже ходил этим путём: http://www.rsdn.ru/forum/db/2396453.flat.aspx
G>

Это совсем не тот путь.
Именно тот. По-другому не получается.

C>>С задержкой, минимально ограниченной латентностью сети. К примеру, если пользователей порядка 2000 и у каждого из них по 3 адреса — запрос уже будет выполняться ощутимое время. А ещё учитываем время на передачу результатов. На практике оно весьма тормозно получается.
G>Я че-то туплю. Данные уже есть на клиенте (в этой самой таблице), так что все будет моментально работать, не переживай.
В таблице могут быть не совсем все данные.

G>>>И часто меняется ACL сильно родительской записи? И какова глубина иерархий?
C>>5-10 элементов. В паре вырожденных случаев около 50.
G>Ну это совсем немного.
Более чем.

C>>В общем, очень и очень хрупкое решение.
G>Это потому что ты не умеешь его готовить.
Умею. Оно уже было так сделано. Передалал.

C>>Во-во. И ACLи тоже. И запросы. И можно ли всё это сделать на MySQL с его странным языком триггеров и SP? А как быть с транзакциями —
G>Ну не пиши по MySQL, одной беслатной БД в арсенале вполне достаточно.
G>Если программа работает с любой БД, то или она очень простая, или не использует возможностей БД и греет воздух.
Это просто с твоим архаичным подходом с кашей непонятно каких триггеров, UDF, кэширующих таблиц, странных кэшей, непонятных батчей так не получается. А с современными ORM — всё просто и без проблем делается.

C>>Спрашивается: ну и где наглядность L/ORM остаётся-то? Как обычно — только в теории?
G>Наглядности станет больше — станет меньше императивного кода.
Ага. Триггеры — это у нас уже не императивный подход?

C>>Не-не. Это и я могу. Ты мне сделай так, чтоб оно список товаров выводило в том виде, в котором я его написал.
G>Большая разница чтоли?
G>

G>var q = from p in db.Products        
G>        select {Product = p.Name, Groups = p.Groups.OrderBy(g => g.Wheight).Select(g => g.Name)};
G>

G>А потом склеиваешь строки.
Опять неверно. Нужно найти все _комбинации_ групп.

Вот ровно та же проблема: http://www.rsdn.ru/forum/db/2682769.flat.aspx

C>>Не знаю, может мне везёт, но у меня почему-то большинство таких отчётов.
G>Тебе везет или ты что-то не так делаешь.
G>Ингда выгоднее хранить дельты и использовать indexed\materialized view.
А мне не надо делать никаких видов под отдельные запросы, ничего. В БД хранятся ТОЛЬКО данные и НИКАКОЙ логики.

Single Responsibility Principle, однако.

C>>Скажи это Гуглу, создателям Couch DB и языка K.
G>Couch DB — из другой оперы, там данные частично-структурированные.
И что?

G>>>Вот только некоторые простые для императивной обработки вещи в SQL потребуют correlated subquery и офигенную сложность выполнения.
C>>Необязательно. Я могу взять нужные данные и руками по ним запустить обработку. На нормальном Turing-complete языке.
G>Ну собственно тебе никто не мешает это сделать. Ты можешь посчитать аггрегаты один раз и хранить их.
И обновлять их ВСЕ при каждом изменении. Даже если часть аггрегатов нужна раз в пятилетку.

G>>>Ты знаешь как кеширование в HTTP работает?
C>>"last modified" _на_ _что_?
G>На запрос.
На какой?

Ты видел поле с расписанием на скриншоте? Так вот, он зависит что-то около от 200 таблиц. Другой вид данных зависит от примерно такого же числа таблиц, но чуть-чуть других.

ЧТО мы будем слушать-то?

C>>Повышаем гранулярность — и перегружаем всю "гранулу" при её изменении. Только объём увеличится.
G>Не тупи. Высокая гранулярность — более "мелкие" гранулы.
А, ну ладно. Тогда проблемы с зависимостями. Скажем, пользователя надо показывать "недоступным", если он в это время запланировал meeting. Планирование meeting'ов и показ расписания — в очень разных частях БД.

Так что если мы слушаем только

Здравствуйте, yoriсk.kiev.ua, Вы писали:

YKU>Повторюсь: менять дизайн — это копейки. Если только вы не юзабелист/дизайнер интерфейсов... Но тогда сидите в Blend и работайте там, он специально для этого и предназначен.
Как можно говорить об интерфейсе не упоминая дизайн?? Вы этим не занимаетесь вообще или чувствуете недостаточно компетентным чтобы обсуждать? Не каждая контора может себе позволить дизайнера как отдельную сущность.

YKU>То ли дело зоопарк яваскриптов, который не компилится, непонятно как тестируется имеет внутри три-четыре ветки под разные броузеры.
Все уже сделано за вас — prototype/jquery/extjs/другая по вкусу библиотека вам в руки.

YKU>Вообще, у вас ИМХО с юзабилити какие-то напряги. Клиент не должен ничего копи-пейстить.
Смотря какой клиент, смотря с какой информацией работает. Нет никаких напрягов — просто упомянул одним из достоинств HTMLя то, что с ним нештатно доступны дополнительные функции, к которым пользователь привык и уже воспринимает как должное. Попробуйте выделить фрагмент в броузере и кликнуть правой кнопкой мыши — вот вам печать, перевод, сохранить, избранное, поиск, експорт + всякие там акселераторы (IE8) на выбор и т.д.
С SL большинство функций и приятных фенечек броузера становится недоступной (совсем не значит что невостребованной!).
Вам все ето не надо? Все ето можно сделать на SL? сомневаюсь, но флаг вам в руки

YKU>Вы всё скинули в кучу.
Зато у вас никакой кучи и нет. Да, с SL вы пишите только на одном языке и ето большой плюс, но етим вы и ограничены. Песочница Silverlight-а еще по-детски мала (поздравляю, в последней версии появился диалог SaveAs, ради интереса пробегитесь по форумам посмотрите какие воркароунды до етого предлагались...). Если вы чуствуете себя в ней комфортно — прекрасно, рад за вас и ваших пользователей. Я же пока воспользуюсь той функциональностью и богаством выбора, который предоставляет современный web, НЕ ИСКЛЮЧАЯ возможности реализации каких-то элементов на SL. И ето намного выгоднее позиция и для продукта и для его пользователей, чем постоянно спотыкаться, локти кусать и жить в ожидании — ну когдааааа же Microsoft ето сделает и то доделает...

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

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

C>>>А данные всё равно будут подниматься перед выдачей их клиенту. Так что однофигственно.
G>>Да ну? Клиенту для отображени ясовсем немного данных надо.
C>Опять же говорю — не немного.
То что ты показал на скриншоте требует не более 1 мб. А при умном подходе и того меньше.

C>>>Я уже ходил этим путём: http://www.rsdn.ru/forum/db/2396453.flat.aspx
G>>

Это совсем не тот путь.
C>Именно тот. По-другому не получается.
Соболезную. Но все равно не тот путь.

C>>>С задержкой, минимально ограниченной латентностью сети. К примеру, если пользователей порядка 2000 и у каждого из них по 3 адреса — запрос уже будет выполняться ощутимое время. А ещё учитываем время на передачу результатов. На практике оно весьма тормозно получается.
G>>Я че-то туплю. Данные уже есть на клиенте (в этой самой таблице), так что все будет моментально работать, не переживай.
C>В таблице могут быть не совсем все данные.
А зачем искать по данным, которые визуально не отображаются?

C>>>В общем, очень и очень хрупкое решение.
G>>Это потому что ты не умеешь его готовить.
C>Умею. Оно уже было так сделано. Передалал.
Если получилось очень хрупкое решение — значит не умеешь.
Весь веб так работает. Посмотри на сервисы гугла.

C>>>Во-во. И ACLи тоже. И запросы. И можно ли всё это сделать на MySQL с его странным языком триггеров и SP? А как быть с транзакциями —
G>>Ну не пиши по MySQL, одной беслатной БД в арсенале вполне достаточно.
G>>Если программа работает с любой БД, то или она очень простая, или не использует возможностей БД и греет воздух.
C>Это просто с твоим архаичным подходом с кашей непонятно каких триггеров, UDF, кэширующих таблиц, странных кэшей, непонятных батчей так не получается. А с современными ORM — всё просто и без проблем делается.
Не надо придавать эмоциональную окраску техническим вопросом. Подучись немного и триггеры, UDF и кеширующие таблицы станут для тебя вполне нормальными.
А в современными ORM все что удвлось тебе сделать — приложение, которому для старта требуется 30 метров выкачать.
При таком раскладе легче remote desktop использовать.

C>>>Спрашивается: ну и где наглядность L/ORM остаётся-то? Как обычно — только в теории?
G>>Наглядности станет больше — станет меньше императивного кода.
C>Ага. Триггеры — это у нас уже не императивный подход?
Нет, с чего бы?
Триггеры это просто функции, которые будут вызываться неявно. Внутри уже пишешь как захочешь.

G>>>>Вот только некоторые простые для императивной обработки вещи в SQL потребуют correlated subquery и офигенную сложность выполнения.
C>>>Необязательно. Я могу взять нужные данные и руками по ним запустить обработку. На нормальном Turing-complete языке.
G>>Ну собственно тебе никто не мешает это сделать. Ты можешь посчитать аггрегаты один раз и хранить их.
C>И обновлять их ВСЕ при каждом изменении. Даже если часть аггрегатов нужна раз в пятилетку.
А с чего ты взял что все обновлять надо? Ты же знаешь конкретные изменения, вот и обновляй зименившиеся аггрегаты.
И это все равно будет дешевле, чем пересчитывть аггрегаты при запросах.

G>>>>Ты знаешь как кеширование в HTTP работает?
C>>>"last modified" _на_ _что_?
G>>На запрос.
C>На какой?
На любой.

C>Ты видел поле с расписанием на скриншоте? Так вот, он зависит что-то около от 200 таблиц. Другой вид данных зависит от примерно такого же числа таблиц, но чуть-чуть других.
Да хоть от 1000.

C>ЧТО мы будем слушать-то?
Ты же заешь какие действия толькователя повлияют на таблицу, вот и пусть эти действия вызывают обновления last modified для таблицы.
Незачем на клиента тащить всю схему данных.

C>>>Повышаем гранулярность — и перегружаем всю "гранулу" при её изменении. Только объём увеличится.
G>>Не тупи. Высокая гранулярность — более "мелкие" гранулы.
C>А, ну ладно. Тогда проблемы с зависимостями. Скажем, пользователя надо показывать "недоступным", если он в это время запланировал meeting. Планирование meeting'ов и показ расписания — в очень разных частях БД.
См выше.

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

C>>Опять же говорю — не немного.
G>То что ты показал на скриншоте требует не более 1 мб. А при умном подходе и того меньше.
Угу. А потом roundtrip на каждый щелчок.

G>>>Я че-то туплю. Данные уже есть на клиенте (в этой самой таблице), так что все будет моментально работать, не переживай.
C>>В таблице могут быть не совсем все данные.
G>А зачем искать по данным, которые визуально не отображаются?
Чтобы отобразить их.

C>>Умею. Оно уже было так сделано. Передалал.
G>Если получилось очень хрупкое решение — значит не умеешь.
G>Весь веб так работает. Посмотри на сервисы гугла.
У Гугла очень простые сервисы, которые обслуживает кластер из сотен тысяч машин.

Вдобавок, часть приложений у них таки по моей схеме работает. К примеру, GMail c Google Gears (который в offline работает, да). Или их электронная таблица — они там отправляют на сервер только лог измений, а почти все расчёты идут на клиенте (вот ведь, никто не сказал кретинам оттуда, что проще каждый click на сервер отправлять!).

Так что мимо.

C>>Это просто с твоим архаичным подходом с кашей непонятно каких триггеров, UDF, кэширующих таблиц, странных кэшей, непонятных батчей так не получается. А с современными ORM — всё просто и без проблем делается.
G>Не надо придавать эмоциональную окраску техническим вопросом. Подучись немного и триггеры, UDF и кеширующие таблицы станут для тебя вполне нормальными.
Не, до такого состояния разума я не дойду. Я видел в кого превращаются профессиональные DBA, спасибо.

G>А в современными ORM все что удвлось тебе сделать — приложение, которому для старта требуется 30 метров выкачать.
Не 30 Мб, я же уже сказал это. Меньше 5Мб — около 30 секунд на медленном соединении.

А после начальной загрузки можно и с модема работать, кстати. Без всяких проблем ВООБЩЕ. Реально спасло пару раз, когда из каналов связи был только тормозной и дорогой GPRS.

G>При таком раскладе легче remote desktop использовать.
Не проще.

G>>>Наглядности станет больше — станет меньше императивного кода.
C>>Ага. Триггеры — это у нас уже не императивный подход?
G>Нет, с чего бы?
Да, с того бы.

G>Триггеры это просто функции, которые будут вызываться неявно. Внутри уже пишешь как захочешь.
Угу, именно. Это процедуры, которые запускаются при модификации данных. В них ничерта нет от реляционности — это просто вариант AOP.

C>>И обновлять их ВСЕ при каждом изменении. Даже если часть аггрегатов нужна раз в пятилетку.
G>А с чего ты взял что все обновлять надо? Ты же знаешь конкретные изменения, вот и обновляй зименившиеся аггрегаты.
Нет, я не знаю конкретные изменения.

G>И это все равно будет дешевле, чем пересчитывть аггрегаты при запросах.
Не будет.

G>>>>>Ты знаешь как кеширование в HTTP работает?
C>>>>"last modified" _на_ _что_?
G>>>На запрос.
C>>На какой?
G>На любой.
В том числе, и на запрос "выбери мне первое число, которое не представимо в виде суммы двух простых чисел"?

C>>Ты видел поле с расписанием на скриншоте? Так вот, он зависит что-то около от 200 таблиц. Другой вид данных зависит от примерно такого же числа таблиц, но чуть-чуть других.
G>Да хоть от 1000.
Ну да. Чего мелочиться, пусть хоть миллион будет!

C>>ЧТО мы будем слушать-то?
G>Ты же заешь какие действия толькователя повлияют на таблицу, вот и пусть эти действия вызывают обновления last modified для таблицы.
НЕТ, я НЕ ЗНАЮ какие действия толькователя повлияют на таблицу.

Более того, МНЕ ЭТО НЕ НУЖНО знать. А вот тебе придётся руками отслеживать ВСЕ неявные связи, иначе появятся возможности получения неконсистентной информации?

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

Стоит ли говорить, что у меня ещё и ВСЁ транзакционно-безопасно и гарантирован строгий порядок доставки событий?

G>Незачем на клиента тащить всю схему данных.
Почему?

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

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

C>>>Опять же говорю — не немного.
G>>То что ты показал на скриншоте требует не более 1 мб. А при умном подходе и того меньше.
C>Угу. А потом roundtrip на каждый щелчок.
Это не так страшно, тем более при кешировании результатов.

C>>>Умею. Оно уже было так сделано. Передалал.
G>>Если получилось очень хрупкое решение — значит не умеешь.
G>>Весь веб так работает. Посмотри на сервисы гугла.
C>У Гугла очень простые сервисы, которые обслуживает кластер из сотен тысяч машин.
Заметил такую тенденцию на формуме — неудачные технические решения оправдываются сложностью задачи и наоборот удачные решения объявляют чуть ли не тривиальными вещами.
Даю руку на отсечение что любой из гугловых сервисов сложнее того что пишешь ты.

C>Вдобавок, часть приложений у них таки по моей схеме работает. К примеру, GMail c Google Gears (который в offline работает, да). Или их электронная таблица — они там отправляют на сервер только лог измений, а почти все расчёты идут на клиенте (вот ведь, никто не сказал кретинам оттуда, что проще каждый click на сервер отправлять!).
рассчеты на клиенте абсолютно ортогональны тому что тут обсуждается.

C>>>Это просто с твоим архаичным подходом с кашей непонятно каких триггеров, UDF, кэширующих таблиц, странных кэшей, непонятных батчей так не получается. А с современными ORM — всё просто и без проблем делается.
G>>Не надо придавать эмоциональную окраску техническим вопросом. Подучись немного и триггеры, UDF и кеширующие таблицы станут для тебя вполне нормальными.
C>Не, до такого состояния разума я не дойду. Я видел в кого превращаются профессиональные DBA, спасибо.
Меньше эмоций, разум чище будет.

G>>А в современными ORM все что удвлось тебе сделать — приложение, которому для старта требуется 30 метров выкачать.
C>Не 30 Мб, я же уже сказал это. Меньше 5Мб — около 30 секунд на медленном соединении.
Ого, хорошее у тебя медленное соединение. У меня ADSL в лучшие времена не так быстро работал.

G>>>>Наглядности станет больше — станет меньше императивного кода.
C>>>Ага. Триггеры — это у нас уже не императивный подход?
G>>Нет, с чего бы?
C>Да, с того бы.
Ну так обоснуй.

G>>Триггеры это просто функции, которые будут вызываться неявно. Внутри уже пишешь как захочешь.
C>Угу, именно. Это процедуры, которые запускаются при модификации данных. В них ничерта нет от реляционности — это просто вариант AOP.
А чем aop противоречит реляцонности?
Это вообще разные категории.

C>>>И обновлять их ВСЕ при каждом изменении. Даже если часть аггрегатов нужна раз в пятилетку.
G>>А с чего ты взял что все обновлять надо? Ты же знаешь конкретные изменения, вот и обновляй зименившиеся аггрегаты.
C>Нет, я не знаю конкретные изменения.
Такого не бывает. Ты же программу пишешь и обрабатываешь конкретные действия пользователей, которые соответствуют конкретным сценариям работы системы, которые приводят к конкретным изменениям данных.
Другое дело что у тебя код построен так что ты не можешь из его массы выделить эти самые сценарии, но это уже проблема кода.

G>>И это все равно будет дешевле, чем пересчитывть аггрегаты при запросах.
C>Не будет.
Будет. Кроме того с точки зрения пользователя повысится производительность.
Пользователь желая увидеть данные готов ждать гораздо меньше, чем при желании данные изменить.
Например заходя на сайт хочется видеть страницу сразу, а постя сообщение на форум подождать пару секунд — впнолне терпимо.

G>>>>>>Ты знаешь как кеширование в HTTP работает?
C>>>>>"last modified" _на_ _что_?
G>>>>На запрос.
C>>>На какой?
G>>На любой.
C>В том числе, и на запрос "выбери мне первое число, которое не представимо в виде суммы двух простых чисел"?
Конечно, а чем он хуже других?
Только имеет ли смысл вообще запрашивать что-либо в таком случае?

C>>>ЧТО мы будем слушать-то?
G>>Ты же заешь какие действия толькователя повлияют на таблицу, вот и пусть эти действия вызывают обновления last modified для таблицы.
C>НЕТ, я НЕ ЗНАЮ какие действия толькователя повлияют на таблицу.
Это я уже понял.

C>Более того, МНЕ ЭТО НЕ НУЖНО знать. А вот тебе придётся руками отслеживать ВСЕ неявные связи, иначе появятся возможности получения неконсистентной информации?
Я не создаю неявных связей, у меня все связи явные.

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

C>Стоит ли говорить, что у меня ещё и ВСЁ транзакционно-безопасно и гарантирован строгий порядок доставки событий?

И что тебе с этого? Длинее и толще?

G>>Незачем на клиента тащить всю схему данных.
C>Почему?
Потому что это лишний расход трафика и бесполезное нагревание воздуха серверной.

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

C>>Угу. А потом roundtrip на каждый щелчок.
G>Это не так страшно, тем более при кешировании результатов.
1) Что кэшировать-то? Вот я нажал на ячейку — и мне надо показать подробные детали для неё. Шансы что я нажму на неё второй раз — не особо велики.
2) Как инвалидировать будем-с?

C>>У Гугла очень простые сервисы, которые обслуживает кластер из сотен тысяч машин.
G>Заметил такую тенденцию на формуме — неудачные технические решения оправдываются сложностью задачи и наоборот удачные решения объявляют чуть ли не тривиальными вещами.
G>Даю руку на отсечение что любой из гугловых сервисов сложнее того что пишешь ты.
Давай.

C>>Вдобавок, часть приложений у них таки по моей схеме работает. К примеру, GMail c Google Gears (который в offline работает, да). Или их электронная таблица — они там отправляют на сервер только лог измений, а почти все расчёты идут на клиенте (вот ведь, никто не сказал кретинам оттуда, что проще каждый click на сервер отправлять!).
G>рассчеты на клиенте абсолютно ортогональны тому что тут обсуждается.
Ничуть. Вообще, GMail работает ровно так же, как и мой код. С той лишь разницей, что они вместо H/ORM используют какое-то своё кластерное хранилище.

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

C>>Не 30 Мб, я же уже сказал это. Меньше 5Мб — около 30 секунд на медленном соединении.
G>Ого, хорошее у тебя медленное соединение. У меня ADSL в лучшие времена не так быстро работал.
Это где-то скорость 1.5Мбит. Действительно, не совсем медленное.

G>>>Триггеры это просто функции, которые будут вызываться неявно. Внутри уже пишешь как захочешь.
C>>Угу, именно. Это процедуры, которые запускаются при модификации данных. В них ничерта нет от реляционности — это просто вариант AOP.
G>А чем aop противоречит реляцонности?
Вообще-то, да. Он к ней неприменим. Реляционная алгебра — это просто алгебра работы с множествами, которая позволяет делать гибкие структурированные хранилища.

Хранимые процедуры, триггеры, CTE — уже не имеют никакого отношения к реляционной алгебре. Соответственно, глупо утверждать что программа с большим числом хранимок и триггеров более "реляционна", чем программа с H/ORM.

Пропоненты L/ORM именно так пока и делают.

G>>>А с чего ты взял что все обновлять надо? Ты же знаешь конкретные изменения, вот и обновляй зименившиеся аггрегаты.
C>>Нет, я не знаю конкретные изменения.
G>Такого не бывает. Ты же программу пишешь и обрабатываешь конкретные действия пользователей, которые соответствуют конкретным сценариям работы системы, которые приводят к конкретным изменениям данных.
Ещё как бывает со сложными моделями. У меня сейчас более тысячи разных операций. Для каждой операции в твоём подходе необходимо знать как она повлияет на всё остальное.

Может ты не работал с большими и сложными моделями?

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

C>>>>На какой?
G>>>На любой.
C>>В том числе, и на запрос "выбери мне первое число, которое не представимо в виде суммы двух простых чисел"?
G>Конечно, а чем он хуже других?
Нууу...

G>Только имеет ли смысл вообще запрашивать что-либо в таком случае?
А вот надо. Как делать будем?

C>>Более того, МНЕ ЭТО НЕ НУЖНО знать. А вот тебе придётся руками отслеживать ВСЕ неявные связи, иначе появятся возможности получения неконсистентной информации?
G>Я не создаю неявных связей, у меня все связи явные.
Я говорю не про FK. Я уже привёл пример, когда изменение одного кусочка данных повляет на другой, не связанный напрямую с ним.

C>>Ещё насчёт неконсистентности — у тебя ещё будут и несколько параллельных "отслеживателей", слушающих события. Причём порядок их отработки — ничем не определён. Так что запросто полчаем сценарий, когда в одной части окна данные обновятся, а в другой части будут висеть старые.
G>И с чего они висеть там останутся?
А не прошёл HTTP-запрос. Пакетик потерялся, и он ждёт retransmit'а. Или файрвол решил задержать ответ до проверки нет ли в нём вирусов.

Оба случая вполне реальные.

C>>Стоит ли говорить, что у меня ещё и ВСЁ транзакционно-безопасно и гарантирован строгий порядок доставки событий?
G>

И что тебе с этого? Длинее и толще?
Угу.

G>>>Незачем на клиента тащить всю схему данных.
C>>Почему?
G>Потому что это лишний расход трафика и бесполезное нагревание воздуха серверной.
Нет. Лишний расход траффика — у тебя. У меня сейчас дневной расход на приложение — около 10Мб. 5Мб на начальную загрузку (надо бы её оптимизировать...), а дальше считанные байты на трансляцию изменений.

Т.е. оно реально может использоваться на модеме.

Для твоей модели оно недостижимо.

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

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

C>>>Угу. А потом roundtrip на каждый щелчок.
G>>Это не так страшно, тем более при кешировании результатов.
C>1) Что кэшировать-то? Вот я нажал на ячейку — и мне надо показать подробные детали для неё. Шансы что я нажму на неё второй раз — не особо велики.
Вот подробные детали и кешируй. Даже если второй раз запрошено никогда не будет это не даст заметного оверхеда. Причем кеш ответов не вносит оверхед в отличе от кеширования данных.

C>2) Как инвалидировать будем-с?
last modified

C>>>Вдобавок, часть приложений у них таки по моей схеме работает. К примеру, GMail c Google Gears (который в offline работает, да). Или их электронная таблица — они там отправляют на сервер только лог измений, а почти все расчёты идут на клиенте (вот ведь, никто не сказал кретинам оттуда, что проще каждый click на сервер отправлять!).
G>>рассчеты на клиенте абсолютно ортогональны тому что тут обсуждается.
C>Ничуть. Вообще, GMail работает ровно так же, как и мой код. С той лишь разницей, что они вместо H/ORM используют какое-то своё кластерное хранилище.
С чего ты взял? Исходники видел?

C>Там ровно так же на клиенте хранится кэш данных, с которым работает JavaScript-код. GMail ровно так же как и я вместо прямых запросов "дай данные для этой ячейки" использует подход "загрузить и положить в кэш данные", которые уже и отобржаются.
Это всегда так будет. Отличие в том, что GMail получает данные необходимые для отображения, а ты тянешь на клиента модель из базы.

C>>>Не 30 Мб, я же уже сказал это. Меньше 5Мб — около 30 секунд на медленном соединении.
G>>Ого, хорошее у тебя медленное соединение. У меня ADSL в лучшие времена не так быстро работал.
C>Это где-то скорость 1.5Мбит. Действительно, не совсем медленное.
Интересно, откуда латентность в 200 мс на таких каналах?

C>Хранимые процедуры, триггеры, CTE — уже не имеют никакого отношения к реляционной алгебре. Соответственно, глупо утверждать что программа с большим числом хранимок и триггеров более "реляционна", чем программа с H/ORM.
Как раз можно, томому что теже триггеры и CTE работают именно с реляционными данными, тогда как H/ORM хочет сделать вид что работа идет с объектами.

G>>>>А с чего ты взял что все обновлять надо? Ты же знаешь конкретные изменения, вот и обновляй зименившиеся аггрегаты.
C>>>Нет, я не знаю конкретные изменения.
G>>Такого не бывает. Ты же программу пишешь и обрабатываешь конкретные действия пользователей, которые соответствуют конкретным сценариям работы системы, которые приводят к конкретным изменениям данных.
C>Ещё как бывает со сложными моделями. У меня сейчас более тысячи разных операций. Для каждой операции в твоём подходе необходимо знать как она повлияет на всё остальное.
Не знаю как тебе, а мне не удавалось писать программы в которых я не знаю что происходит.
И для каждого сценария я могу сказать к каким изменениям он приводит.

C>Может ты не работал с большими и сложными моделями?
Работал

G>>Будет. Кроме того с точки зрения пользователя повысится производительность.
G>>Пользователь желая увидеть данные готов ждать гораздо меньше, чем при желании данные изменить.
G>>Например заходя на сайт хочется видеть страницу сразу, а постя сообщение на форум подождать пару секунд — впнолне терпимо.
C>Ты не учитываешь, что некоторые изменения должны делаються очень быстро. Если координатор, который должен распределить пару тысяч смен, должен по 10 секунд ждать на каждую операцию — он придёт к тебе домой и тебя застрелит.
Ну да, выдумывание небылиц — хороший способ обоснования свой позиции, с чего ты взял 10 секунд?
Даже если взять того же оператора и представить что пересчет аггрегатов в запросе выполняется в 100 раз быстрее 0.1 секунду, то на отображение 10000 записей ему придется ждать около 20 минут. И это прижедтся испытать каждому пользователю, который попытается просмотреть расписание.

G>>Только имеет ли смысл вообще запрашивать что-либо в таком случае?
C>А вот надо. Как делать будем?

C>>>Более того, МНЕ ЭТО НЕ НУЖНО знать. А вот тебе придётся руками отслеживать ВСЕ неявные связи, иначе появятся возможности получения неконсистентной информации?
G>>Я не создаю неявных связей, у меня все связи явные.
C>Я говорю не про FK. Я уже привёл пример, когда изменение одного кусочка данных повляет на другой, не связанный напрямую с ним.
И что? Ты создавая программу не знаешь какие действия на какие данные повлияют?

C>>>Ещё насчёт неконсистентности — у тебя ещё будут и несколько параллельных "отслеживателей", слушающих события. Причём порядок их отработки — ничем не определён. Так что запросто полчаем сценарий, когда в одной части окна данные обновятся, а в другой части будут висеть старые.
G>>И с чего они висеть там останутся?
C>А не прошёл HTTP-запрос. Пакетик потерялся, и он ждёт retransmit'а. Или файрвол решил задержать ответ до проверки нет ли в нём вирусов.
Этона каталах, которые по 1,5 мбит выдают? Сам в это веришь?

C>Оба случая вполне реальные.
Ну встретить динозавра тоже вполне реально, даже с вероятностью отличной от нуля.

G>>>>Незачем на клиента тащить всю схему данных.
C>>>Почему?
G>>Потому что это лишний расход трафика и бесполезное нагревание воздуха серверной.
C>Нет. Лишний расход траффика — у тебя. У меня сейчас дневной расход на приложение — около 10Мб. 5Мб на начальную загрузку (надо бы её оптимизировать...), а дальше считанные байты на трансляцию изменений.

А в моем подходе не будет начальной загрузки и теже 5 метров будут растянуты по времени. И потом тоже будут "считанные байты" на изменения.

C>Т.е. оно реально может использоваться на модеме.

Я плакал

C>Для твоей модели оно недостижимо.
Ну я как раз через GPRS часто в интернете сижу. Если бы мне кто-нибудь предложил скачать 5 метров просто чтобы начать пользоваться программой, то я бы сразу послал такой сервис.

Короче хватит практиковаться в выдумывании небылиц. Адекватного описания преимуществ твоего подхода не видно, а все что есть вполне делается и без h\orm.

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

C>>1) Что кэшировать-то? Вот я нажал на ячейку — и мне надо показать подробные детали для неё. Шансы что я нажму на неё второй раз — не особо велики.
G>Вот подробные детали и кешируй. Даже если второй раз запрошено никогда не будет это не даст заметного оверхеда. Причем кеш ответов не вносит оверхед в отличе от кеширования данных.
Торможение в первый раз — уже неприемлимо.

C>>2) Как инвалидировать будем-с?
G>last modified
Это требует _каждый_ _раз_ делать запрос на сервер при нажатии на ячейку. Пофиг что оно вернёт "304 Not Modified" — всё равно нужен отдельный запрос.

C>>Ничуть. Вообще, GMail работает ровно так же, как и мой код. С той лишь разницей, что они вместо H/ORM используют какое-то своё кластерное хранилище.
G>С чего ты взял? Исходники видел?
Нет. Презентации о его архитектуре.

C>>Там ровно так же на клиенте хранится кэш данных, с которым работает JavaScript-код. GMail ровно так же как и я вместо прямых запросов "дай данные для этой ячейки" использует подход "загрузить и положить в кэш данные", которые уже и отобржаются.
G>Это всегда так будет. Отличие в том, что GMail получает данные необходимые для отображения, а ты тянешь на клиента модель из базы.
Мимо. GMail точно так же загружает сразу больше данных, чем видно. Просто с EMail'ом всё просто.

А вот их приложение с электронной таблицей вообще почти всё на клиенте работает.

G>>>Ого, хорошее у тебя медленное соединение. У меня ADSL в лучшие времена не так быстро работал.
C>>Это где-то скорость 1.5Мбит. Действительно, не совсем медленное.
G>Интересно, откуда латентность в 200 мс на таких каналах?
Из-за конечной скорости света, глюкодромных ADSL и промежуточных хостов. Латентность имеет мало отношения к пропускной способности канала.

C>>Хранимые процедуры, триггеры, CTE — уже не имеют никакого отношения к реляционной алгебре. Соответственно, глупо утверждать что программа с большим числом хранимок и триггеров более "реляционна", чем программа с H/ORM.
G>Как раз можно, томому что теже триггеры и CTE работают именно с реляционными данными, тогда как H/ORM хочет сделать вид что работа идет с объектами.
Нет, H/ORM работает с объектным представлением реляционных данных.

Сам по себе H/ORM так же "реляционен" как и голый SQL.

C>>Ещё как бывает со сложными моделями. У меня сейчас более тысячи разных операций. Для каждой операции в твоём подходе необходимо знать как она повлияет на всё остальное.
G>Не знаю как тебе, а мне не удавалось писать программы в которых я не знаю что происходит.
Ты знаешь, когда у тебя в программе на C# запускается GC?

Вот и мне неинтересно знать.

G>И для каждого сценария я могу сказать к каким изменениям он приводит.
Я тоже. Если специально посмотреть. Но зачем?

C>>Ты не учитываешь, что некоторые изменения должны делаються очень быстро. Если координатор, который должен распределить пару тысяч смен, должен по 10 секунд ждать на каждую операцию — он придёт к тебе домой и тебя застрелит.
G>Ну да, выдумывание небылиц — хороший способ обоснования свой позиции, с чего ты взял 10 секунд?
Даже пара секунд — уже много. Уже даже доли секунды — слишком много.

G>Даже если взять того же оператора и представить что пересчет аггрегатов в запросе выполняется в 100 раз быстрее 0.1 секунду, то на отображение 10000 записей ему придется ждать около 20 минут. И это прижедтся испытать каждому пользователю, который попытается просмотреть расписание.
Ты забываешь, что в том виде, который смотрит координатор никакие сложные аггрегаты не считаются.

C>>Я говорю не про FK. Я уже привёл пример, когда изменение одного кусочка данных повляет на другой, не связанный напрямую с ним.
G>И что? Ты создавая программу не знаешь какие действия на какие данные повлияют?
Не знаю. Поэтому и сделал систему, где мне и знать это необязательно.

C>>А не прошёл HTTP-запрос. Пакетик потерялся, и он ждёт retransmit'а. Или файрвол решил задержать ответ до проверки нет ли в нём вирусов.
G>Этона каталах, которые по 1,5 мбит выдают? Сам в это веришь?
Я же говорю — случаи реальные. Точнее, достоверно случившиеся. Вот буквально вчера пользователь пожаловался, что файл из системы документ-менеджмента в приложении не могут закачать. Оказалось, что излишне прыткий антивирус перехватил обращение, и не отдавал последний байтик пока не проверит всё тело (защищённое HTTPS — чего он там сканировал?). Чем вызывал таймаут в приложении.

C>>Нет. Лишний расход траффика — у тебя. У меня сейчас дневной расход на приложение — около 10Мб. 5Мб на начальную загрузку (надо бы её оптимизировать...), а дальше считанные байты на трансляцию изменений.
G>

G>А в моем подходе не будет начальной загрузки и теже 5 метров будут растянуты по времени. И потом тоже будут "считанные байты" на изменения.
Не будут. У тебя загрузка одного вида займёт в лучшем случае килобайт 500. А их переключают кучу десятков раз в день.

C>>Т.е. оно реально может использоваться на модеме.
G>

G>Я плакал
Плачь. Требование реально.

C>>Для твоей модели оно недостижимо.
G>Ну я как раз через GPRS часто в интернете сижу. Если бы мне кто-нибудь предложил скачать 5 метров просто чтобы начать пользоваться программой, то я бы сразу послал такой сервис.
А твой сервис с торможением по минуте на _каждое_ действие пошлют ещё дальше.

G>Короче хватит практиковаться в выдумывании небылиц. Адекватного описания преимуществ твоего подхода не видно, а все что есть вполне делается и без h\orm.
Ну да. Твой подход требует:
1) Большого расхода времени.
2) В 10-100 раз большего количества серверов.
3) Гораздо более сложного программирования — ручного отслеживания зависимостей.
4) Мешанины UDF, SP и прочих "радостей".
5) Зависимость от конкретной БД.
6) Не будет работать на модеме.
...

Зато у него один плюс — не будет использоваться H/ORM. Самому-то не смешно?

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

C>>Торможение в первый раз — уже неприемлимо.
G>Да ты че? а как же 5 метров первая загрузка?
Не строй дурачка. Разовая трата в 5Мб допустима, а вот торможение на КАЖДОЙ операции — нет.

G>>>last modified
C>>Это требует _каждый_ _раз_ делать запрос на сервер при нажатии на ячейку. Пофиг что оно вернёт "304 Not Modified" — всё равно нужен отдельный запрос.
G>Ну да, с каналом в 1,5 мбит это пройдет незаметно.
А с GPRS?

Да и вовсе не так незаметно.

C>>Сам по себе H/ORM так же "реляционен" как и голый SQL.
G>Ты видимо не понимаешь что означает термин "реляцонный".
Относящийся к реляционной алгебре.

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

G>Задержка в пределах секунды для сохранения — вполне нормально.
Там нет "сохранения". Есть мгновенная реакция — пользователь тыкнул, и должен сразу быть ответ.

C>>Ты забываешь, что в том виде, который смотрит координатор никакие сложные аггрегаты не считаются.
G>В другом считаются, без разницы.
А там где считаются — оно не создаёт проблем.

G>>>А в моем подходе не будет начальной загрузки и теже 5 метров будут растянуты по времени. И потом тоже будут "считанные байты" на изменения.
C>>Не будут. У тебя загрузка одного вида займёт в лучшем случае килобайт 500. А их переключают кучу десятков раз в день.
G>Давай не будем мерятся качаемыми данными, в твоем случае в среднем получится больше.
Голословно. Я тебе уже показал ДВА РАЗНЫХ вида (а всего их 8 штук, и ещё добавляются новые) одних и тех же данных. Между ними пользователи переключаются раз в пару минут. Как в твоём случае сделать переключение быстрым?

Ты так и не ответил.

G>>>Я плакал
C>>Плачь. Требование реально.
G>Как ты 5 метров на модеме выкачаешь?.
Без проблем. Около 40 минут времени.

Впрочем, этих 5Мб уже не стало. Вот только что закоммитил в staging поддержку персистентного локального кэша.

C>>А твой сервис с торможением по минуте на _каждое_ действие пошлют ещё дальше.
G>Уже минуты... хорошо ты выдумываешь...
На передачу 500Кб данных.

G>Время работы сервера в случае GPRS пренебрежительно мало по сравенинию со всеменем передачи данных.
Именно.

C>>Ну да. Твой подход требует:
C>>1) Большого расхода времени.
G>Докажи
Обращение к серверу на каждое действие. А это задержки.

C>>2) В 10-100 раз большего количества серверов.
G>Докажи
Выполнение ВСЕХ действий на сервере. У меня сервер, фактически, загружен только рассылкой изменений и простыми мутирующими операциями. Всё остальное делается на клиентах.

C>>3) Гораздо более сложного программирования — ручного отслеживания зависимостей.
G>Это зависит от структуры программы. В моем случае все зависимости явные.
Значит оно примитивное.

C>>4) Мешанины UDF, SP и прочих "радостей".
G>Которые улучшают производительность и уменьшают нагрузку на сеть.
Твоя архитектура вся уменьшает производительность и увеличивает нагрузку на сеть.

C>>5) Зависимость от конкретной БД.
G>Какой ужас...
Да.

C>>6) Не будет работать на модеме.
G>

Будет лучше чекм твой вариант
G>Короче не выдумывай небылицы.
Ты всё более неадекватен.

Таки предложи как сделать лучше чем моё решение. Критерии я написал выше (6 пунктов). Ждёмс....

Вот такие вот элегантные L/ORM.

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

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

C>>>Торможение в первый раз — уже неприемлимо.
G>>Да ты че? а как же 5 метров первая загрузка?
C>Не строй дурачка. Разовая трата в 5Мб допустима, а вот торможение на КАЖДОЙ операции — нет.
какое-то торможение ты сам придумал, даже 200 мс латентности канала не дадут заметной для пользователя задержки, а суммарный объем загружаемых данных за одну "сессию" работы будет меньше, чем у тебя.

G>>>>last modified
C>>>Это требует _каждый_ _раз_ делать запрос на сервер при нажатии на ячейку. Пофиг что оно вернёт "304 Not Modified" — всё равно нужен отдельный запрос.
G>>Ну да, с каналом в 1,5 мбит это пройдет незаметно.
C>А с GPRS?
С GPRS бужет немного заметно, но этогораздо лучше, чем ожидать загрузки 5 мб.

C>>>Сам по себе H/ORM так же "реляционен" как и голый SQL.
G>>Ты видимо не понимаешь что означает термин "реляцонный".
C>Относящийся к реляционной алгебре.
Ну и как объекты H/ORM относятся к реляционной алгебре. (Подсказка — никак)

G>>>>Ну да, выдумывание небылиц — хороший способ обоснования свой позиции, с чего ты взял 10 секунд?
C>>>Даже пара секунд — уже много. Уже даже доли секунды — слишком много.
G>>Ну да, у тебя тоже реалтайм софт по управлению ядерным реактором?
C>Нет, софт которым пользуются люди.
Люди пользуются миллионами сайтов, который работает как я описываю.
И может быть единицами программ, которые работаю как ты описываешь

G>>>>А в моем подходе не будет начальной загрузки и теже 5 метров будут растянуты по времени. И потом тоже будут "считанные байты" на изменения.
C>>>Не будут. У тебя загрузка одного вида займёт в лучшем случае килобайт 500. А их переключают кучу десятков раз в день.
G>>Давай не будем мерятся качаемыми данными, в твоем случае в среднем получится больше.
C>Голословно. Я тебе уже показал ДВА РАЗНЫХ вида (а всего их 8 штук, и ещё добавляются новые) одних и тех же данных. Между ними пользователи переключаются раз в пару минут. Как в твоём случае сделать переключение быстрым?
Да так же как в твоем, показывать последний сохраненный ответ.
Это к вопросу о передаваемых данных не имеет отношения/

G>>>>Я плакал
C>>>Плачь. Требование реально.
G>>Как ты 5 метров на модеме выкачаешь?.
C>Без проблем. Около 40 минут времени.

C>Впрочем, этих 5Мб уже не стало. Вот только что закоммитил в staging поддержку персистентного локального кэша.
И ты только сейчас догадался сделать персистентный кеш?
Я бы с этого начал

Кстати кеш в HTTP персистентный в большинстве случаев.

C>>>А твой сервис с торможением по минуте на _каждое_ действие пошлют ещё дальше.
G>>Уже минуты... хорошо ты выдумываешь...
C>На передачу 500Кб данных.
А откуда передача 500 кб данных? Это будет делаться максимум один раз.

G>>Время работы сервера в случае GPRS пренебрежительно мало по сравенинию со всеменем передачи данных.
C>Именно.
Ну так лучше сократить время передачи и нагрузить севрер рассчетами, что я собственно и предлагаю.

C>>>Ну да. Твой подход требует:
C>>>1) Большого расхода времени.
G>>Докажи
C>Обращение к серверу на каждое действие. А это задержки.
Но суммарно это время будет меньше времени выкачивания 5 мб.
Кроме того эти задержки вполне возможно сделать незаметными.

C>>>2) В 10-100 раз большего количества серверов.
G>>Докажи
C>Выполнение ВСЕХ действий на сервере. У меня сервер, фактически, загружен только рассылкой изменений и простыми мутирующими операциями. Всё остальное делается на клиентах.
То есть у тебя сервер только зря греет воздух.

C>>>3) Гораздо более сложного программирования — ручного отслеживания зависимостей.
G>>Это зависит от структуры программы. В моем случае все зависимости явные.
C>Значит оно примитивное.

Ты смешен.

C>>>4) Мешанины UDF, SP и прочих "радостей".
G>>Которые улучшают производительность и уменьшают нагрузку на сеть.
C>Твоя архитектура вся уменьшает производительность и увеличивает нагрузку на сеть.
Слив засчитан

C>>>5) Зависимость от конкретной БД.
G>>Какой ужас...
C>Да.
Ниче что большинство приложений работаю на конкретной БД.
Независимость от БД имеет смысл для решений, разворачиваемых на аренгдуемых хостинг-площадках.

C>>>6) Не будет работать на модеме.
G>>

Будет лучше чекм твой вариант
G>>Короче не выдумывай небылицы.
C>Ты всё более неадекватен.

C>Таки предложи как сделать лучше чем моё решение. Критерии я написал выше (6 пунктов). Ждёмс....
Да я уже предложил. Причем то что я предложил уже работает в вебе (и хорошо работает).
А ты только смог выдумать какие-то недостатки которых реально нет.

C>Вот такие вот элегантные L/ORM.
Самое смешное, что задача которую ты решаешь фактически является репликацией данных со сложными условиями.
А эта задача прекрасно решается и без ORM

C>>>Ничуть. Вообще, GMail работает ровно так же, как и мой код. С той лишь разницей, что они вместо H/ORM используют какое-то своё кластерное хранилище.
G>>С чего ты взял? Исходники видел?
C>Нет. Презентации о его архитектуре.
Где можно глянуть ?

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

SHE>Вот такие интересности ждут Вас при выборе Silverlight-a в качестве базовой технологии для front-end-а enterprise level приложения (back-office-а и т.д.):
Судя по списку "интерестностей" знакомство с сильверлайтом ограничилось туториалом

Иначе список был бы другим. А так — мелочевка вперемешку с непониманием, чем вебстраница отличается от сильверлайт приложения.

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

O>Судя по списку "интерестностей" знакомство с сильверлайтом ограничилось туториалом

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

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

SHE>Ну выше yorick назвал главную причину: современный WEB2 ето букет из технологий и языков программирования, помноженный на количество версий/спецификаций/стандартов + особенности реализаций броузеров. Во всем етом надо шарить, изучать приемы / подходы / рецепты / инструменты — вообщем нудно и так сразу не поедешь, возникает естественное желание чиста взять спортивный супер-кар от Microsoft в лице Silverlight-а и ай-да педаль газа под коврик

А так в принципе покататься рекомендую — ето местами захватывающе и действительно на SL можно делать такие вещи, что waauuuu

Соглсен. Используем сейчас ESRI Silverlight API — просто фантастика какая-то!!!

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

SHE>>но ничего по делу
O>Могу еще раз пройтись по пунктам, если есть желание.
Конечно есть, на то здесь и форум

O>С тех пор пишу ручками и радуюсь. Впрочем точно такая же ситуация и с html — пишем ручками, если нужен хороший результат. HTML — XAML 0:0
По крайней мере с HTML легче посмотреть результат (см. пункт ниже)

SHE>>Забудьте про изменения "на лету", как в ASP.NET. Мелочь?
O>Мелочь, конечно, но неприятно. Согласен.
угу

O>Я работаю с Инфрагистик, потому, что стандартный и девэкспрессовский грид, мягко говоря, не функциональны. (...)
O>O>Больше глюков пока не нашел.
Ну у них и прайс-лист блин, полторы штуки баксов за средненький комплект. Плюс наверняка те кто покупал для SL2 теперь еще выкладываются за апгрейд до SL3, по крайней мере из моего опыта приложение на SL2, с использованием Telerik под SL3 ооочень криво пашет. С ASP.NET=>ASP.NET2=>ASP.NET3.5 такого не было. Ну и оно надо такие сюрпризы?

А как тебе сильверлайт биндинг вообще, классы клепать не надоело? Конвертеры, в которые нельзя забиндить параметры (потому что майкрософт считает ето неправильным архитектурным решением). Скажи честно скока их у тебя их уже в проекте в папке Converters? А невозможность забиндить на анонимные типы — оборачивать любой селект LINQ-а отдельным классом — даже в ASP.NET таких ограничений нет... Может я че не так делаю, просвяти.

SHE>>- библиотеки. Иногда ето больно

O>Бывает, но обходится.
Как? Советуешь выкладываться по полторы штуки баксов?

то что для web-a валом валяется, в SL экзотика.
Причем для web-a я могу прикрутить ето в любом виде — как activeX, сервис или вообще cgi-шка. И чихать хотел на все SL песочницы.

SHE>>- нет XML/XSLT (есть Linq To Xml — пользуйтесь)
O>XmlReader/XmlWriter вроде тоже есть
Имел ввиду именно связку XML/XSLT. Часто приходится работать с данными в виде XML.
ОК, допустим забили на XSLT, парсим все ручками и генерим на выходе XAML. Ты пробовал привязать сгенеренный XAML к стилям приложения? попробуй и расскажи как. В asp.net ето простой инклуд css import.

SHE>>- проблемно с линками (открытие интернет ресурса в текущем или новом окне — ето придется продумавать SL программисту)
O>Мелочь
угу, а мне удобно этим пользоваться, не зря даже IE сделали multi-tab-ным.

SHE>> и URL mapping-ом (SL3 предлагает solution, правда примитивный но какой никакой)
O>А с ним-то какие проблемы?
Проблемы с сохранением прямого линка на какой-нибудь ресурс(читай страницу) приложения.

SHE>> + Copy/Paste любого контента в любое приложение — без проблем, с сохранением стилей или без
SHE>> + Сохранить на диск — в виде HTML, TXT, MHT (веб архив, со всеми картинками) — без проблем
SHE>> + Export таблиц — прямо в Excel (из IE, если установлен Office)
O>Смешно. (...)
O>Всего то и нужно сделать нормальный интерфейс, который все это умеет.
Ну так кто спорит — всего то.

SHE>>Любой unhandled exception приводит к crash-у всего приложения.
O>Ну да. Видимо придется позабыть о жабаскриптной практике забивать на все и грамотно работать с exceptions.
Да уж.
Если у тебя на web страничке отсутствует картинка — ето просто пустое место.
SL же падает с громким шумом.

SHE>>А интеграция с серверными решениями (тот же reporting) ето как правило геморрой тот еще.
O>С репортингом не сталкивался, но с сервер-сайдом интеграция отличная.
Поделись опытом. SL+WCF? Етот дебильный async-call, так что при чуть более сложной бизнес логике имеем кучу вложенных делегатов — красотаааа

SHE>>Вообщем я для себя сделал выводы насчет пригодности SL для написания бизнес приложений.
O>Я тоже сделал. Наконец-то можно забыть, как о страшном сне, эту жуткую помесь ASP.NET, AJAX, HTML & JScript и писать нормальные корпоративные приложения на SL. Еще очень сильно надеюсь, что часть указанных здесь пунктов заставят девелоперов писать нормальный UI, поменьше полагаясь на стандартно-ущербный от браузера.
А я повременю, пока он доростет до GoldLight и полностью меня устроит. Возможно к тому времени о его предке silverlight-е тоже давно забудят

Во всяком случае в долгосрочной перспективе для проекта на 2-5 лет уж точно выбор будет не в пользу SL — не улыбается мне каждые год два переписывать все под новую версию.
А от жуткой смеси AJAX, HTML & JScript разработки идут и в других направлениях — посмотри GWT подход — там весь страшный и ужасный AJAX компилируется и генериться из JAVA кода.

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

SHE>Ну у них и прайс-лист блин, полторы штуки баксов за средненький комплект.
За топовый с priority support. Без него штука баксов. Включает в себя ASP.NET & Silverlight. Так что, хоть на сильверлайте, хоть без него, ценник один.

SHE>Плюс наверняка те кто покупал для SL2 теперь еще выкладываются за апгрейд до SL3
У них ничего не было под SL2. Только-только этим летом выпустили первый релиз. У меня вообще сложилось ощущение, что до SL3 все было баловством, а только сейчас, летом, SL стартовал более-менее серьезно. И сам сильверлайт доклепали до удобоваримого состояния, и RIA вышла, и контролы поперли. Думаю к зиме ситуация кардинально улучшится, т.к. народ серьезно взялся за сильверлайт.

SHE>А как тебе сильверлайт биндинг вообще, классы клепать не надоело?
Байндинг весело. Пока не посидел и не угробил вечер на чтение статей в MSDN мозги плыли. Потом все встало на свои места и оно понравилось, действительно можно сделать дофига без извратов в коде.

SHE>Конвертеры, в которые нельзя забиндить параметры (потому что майкрософт считает ето неправильным архитектурным решением).
Не оно? Одна из первых ссылок в гугле.
http://betaforums.silverlight.net/forums/p/124198/280478.aspx

<Image Source="{Binding Converter={StaticResource imgConv}, ConverterParameter="{Binding Sex}" Stretch="Fill"  />

SHE>Скажи честно скока их у тебя их уже в проекте в папке Converters?
Хватает. В основном enums. Как бы их всех в один конвертер свести...

SHE>то что для web-a валом валяется, в SL экзотика.
Это понятно. SL молод пока ищщо. (см. выше) Не успели кучу контролов халявных наклепать, но процесс пошел.

SHE>Причем для web-a я могу прикрутить ето в любом виде — как activeX, сервис или вообще cgi-шка. И чихать хотел на все SL песочницы.
Тут не совсем понял, ты смешал в одном предложении client & server side.

SHE>Ты пробовал привязать сгенеренный XAML к стилям приложения?
Нет не пробовал.

SHE>угу, а мне удобно этим пользоваться, не зря даже IE сделали multi-tab-ным.
Тут без примеров сложно что-то сказать. Вероятнее всего ты проектируешь UI как привык, в веб-стиле.

SHE>Проблемы с сохранением прямого линка на какой-нибудь ресурс(читай страницу) приложения.
Тут-то какие проблемы? Есть URL, по которому маппер тебя пошлет на нужную вьюху, и если надо с параметрами, которые вьюхе будут переданы. В чем проблема потом этот линк сохранить?

SHE>Если у тебя на web страничке отсутствует картинка — ето просто пустое место.
SHE>SL же падает с громким шумом.
Падает. Если не обрабатывать исключения, то много чего падает. Согласен, веб подход тут не применим.

SHE>Поделись опытом. SL+WCF? Етот дебильный async-call, так что при чуть более сложной бизнес логике имеем кучу вложенных делегатов — красотаааа
SL+RIA. Красотаааа! Рекомендую попробовать, хотя инфрагистиковский грид его поддерживает пока с трудом. Обещают в ближайшее время исправится, но я думаю раньше ноября сервис релиза мы так и не дождемся.

От:	IT	linq2db.com
Дата:	01.10.09 03:57
Оценка:	29 (7)

	От:	SHEMA
	Дата:	29.09.09 17:16
	Оценка:	46 (5) +1

	От:	Cyberax
	Дата:	29.09.09 20:22
	Оценка:

От:	IT	linq2db.com
Дата:	29.09.09 15:48
Оценка:	5 (2) +2

	От:	yoriсk.kiev.ua
	Дата:	30.09.09 12:36
	Оценка:	38 (3)

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	01.10.09 12:02
Оценка:	+3

	От:	olegkr
	Дата:	07.10.09 14:16
	Оценка:	18 (1) +1

От:	VladD2	www.nemerle.org
Дата:	30.09.09 19:14
Оценка:	8 (1) +1

	От:	Ночной Смотрящий
	Дата:	29.09.09 18:27
	Оценка:	+2

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	29.09.09 18:45
Оценка:	+2

От:	IB	http://rsdn.ru
Дата:	30.09.09 17:06
Оценка:

От:	Кирилл Осенков	https://twitter.com/KirillOsenkov
Дата:	26.09.09 01:47
Оценка:

От:	samius	http://sams-tricks.blogspot.com
Дата:	28.09.09 14:54
Оценка:

От:	_FRED_	@ViIvanov
Дата:	28.09.09 15:02
Оценка:

От:	Овощ	http://www.google.com
Дата:	01.10.09 11:50
Оценка:

	От:	sergunok
	Дата:	24.09.09 22:43
	Оценка:

	От:	Аноним
	Дата:	27.09.09 12:04
	Оценка:

	От:	Аноним
	Дата:	27.09.09 12:41
	Оценка:

	От:	oleg.agafonov
	Дата:	27.09.09 17:32
	Оценка: