Здравствуйте, 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с есть нецелесообразно, а местами еще и вредно. Посему заявления, что проект априори под угрозой только потому что под Гибернейтом, смешные.
Я очень надеюсь, что в своем посте не допустил грамматических, орфографических ошибок, а также верно применил все термины дабы не дать пиплу комментировать не по сути. Если есть по сути — рад знакомству.

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

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

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

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

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

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

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

Здравствуйте, 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 сценариях.

Это еще что?

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

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

Здравствуйте, 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>А не надо делать денормализацию. Агрегаты просто нужно делать как отдельные процедуры, а данные хранить в нормализованном виде.
Для простых аггрегатов есть indexed\materialized view. Более сложные агрегаты можно делать на триггерах.
Совсем крутые аггрегаты, например по иерархическим мерам — уже OLAP.

Здравствуйте, 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'ы и парсящий их.