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

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

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

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

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

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

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

Здравствуйте, 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

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

А>И ежу понятно, что ежели у вас 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, Вы писали:

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 и функциональной обработки списков.

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

А>Вот я с 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, как я уже сказал, без разницы где рулить. Она занимается только тем, что умеет делать хорошо и не вносит в дизайн приложения никаких искусственных ограничений. Единственная проблема — уровень подготовки разработчиков.

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

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

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

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

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

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