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

B>Все эти проблемы вытекают из того, что почти все популярные ORM-движки навязывают разработчику концепцию построения объектной модели из реляционной модели, а не наоборот

Не согласен. Класс SchemaExport в NHibernate умеет полностью создавать из пустой базы все необходимые объекты, заявленные в объектных маппингах -- таблицы, ключи, индексы, связи. А так же прочие объекты БД (если сильно надо) -- хранимки, функции, процедуры, триггера

Кроме того, там мейнстримом является именно дизайн ООП --> БД. Хотя никто не мешает идти в обратном направлении -- это часто нужно, когда legacy систему начинаешь ставить на NHibernate.

C>Боян в квадрате!!!
Боянофил?

ST>Что касается Change Tracking-а, то это есть попытка а) не делать лишней работы, в данном случае не нагружать базу сохранением неизмененных объектов, и б) избавиться от database-like контракта с методами Add, Update, Delete. Впрочем, от Delete избавиться не удасться. Впрочем, именно change tracking позволяет наибольший простор для оптимизаций и вариаций, и поэтому его редко вспоминают в качестве аргумента против ОРМ.
О котором Change tracking-е идёт реч. О слежении за поменявшимися обьектами или полями обьектов?

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

C>>Боян в квадрате!!!
Tom>Боянофил?
Боянофоб. Я в прошлых баяновых тредах на эту тему слишком много участвовал.

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

Tom>Хотелось бы в одном месте, например в одном топике собрать все проблемы которые вытекают из обьектно ориентированного способа работы с данными (БД) и использовании ORM средств.

Пока ты не начнёшь сам использовать ОРМ или что-то другое, так и будешь собирать проблемы в одном месте.

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

ST>>Что касается Change Tracking-а, то это есть попытка а) не делать лишней работы, в данном случае не нагружать базу сохранением неизмененных объектов, и б) избавиться от database-like контракта с методами Add, Update, Delete. Впрочем, от Delete избавиться не удасться. Впрочем, именно change tracking позволяет наибольший простор для оптимизаций и вариаций, и поэтому его редко вспоминают в качестве аргумента против ОРМ.
Tom>О котором Change tracking-е идёт реч. О слежении за поменявшимися обьектами или полями обьектов?

Оба
Все изменения, которые можно внести в объекты — это удалить объект, добавить объект, изменить содержимое объекта (Этими же операциями, кстати, покрываются и изменения в коллекциях объектов). Специфика СУБД такова, что все эти операции выполняются по-разному, и вторая особенность — их нужно выполнять явно для каждого измененного объекта. Если мы представим себе некое хранилище, которое позволяет быстро сохранять весь граф объектов (например, сериализация в хмл файл), то необходимость в Change Tracking как таковом пропадет в любом виде (если не считать за него необходимость явно добавлять новые объекты в граф).

С базой же приходится извращаться. Если позволяет совесть, мы вообще можем базу каждый раз поднимать в память в виде объектов, и сохранять их назад. Слежение за изменениями в таком случае не нужно. Если взять боолее гуманный вариант, то мы можем сохранять каждый доступный нам объект, проверяя, например, в базе IF EXISTS или даже предварительно делая SELECT по ключу. Так мы можем отловить изменения в содержимом, кроме удаления (нужно как-то определять, что объект удален) и добавления (если мы используем Unit Of Work. Если вызываем сохранение в виде session.Save(myNewJustAddedObject), то нам не нужно добавлять объекты явно).

Таким образом, ChangeTracking действительно выполняет немного двоякую роль: с одной стороны, он служит для получения объектов, которые должны быть сохранены, с другой стороны — определяет действие, которое необходимо произвести для сохранения объекта (добавить, обновить, удалить).

Сорри, занесло чуток в сторону от заданного вами вопроса

IT>Пока ты не начнёшь сам использовать ОРМ или что-то другое, так и будешь собирать проблемы в одном месте.
Последние лет 10 этим только и занимаюсь

ST>Все изменения, которые можно внести в объекты — это удалить объект, добавить объект, изменить содержимое объекта (Этими же операциями, кстати, покрываются и изменения в коллекциях объектов).
Tracking изменённых полей я ещё понимаю зачем нужен — но для чего отслеживать изменённые обьекты понимаю не очень. Почему сразу в базу изменения не отправлять? Или это хитрая оптимизация?
Нужна ли она в действительности

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

Z>Здравствуйте, Mike Chaliy, Вы писали:

MC>>FluentHNibernate, его AutoMapping фитчер. У нас все мапинги сторяться в рантайме и соотвевенно дублирования нет. Есть небольшие исключения, но они решаються кастомными конвеншенами.

Z>Читаем внимательно, дублируются маппинги и схема данных. Маппинги у вас строятся автоматически по классам, а не по схеме данных.

Аха, тока у нас нема мапингов, у нас тока схема доменной модели и схема базы данных. Причем вторая по большей части тоже генериться. Так как всерано дублируеться. Мы по ходу смотрим на схема-лесс решения, пока што безуспешно. Для корпоративок данные должны быть структурированны. Хотя хз, будущее покажет.

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

IT>>Пока ты не начнёшь сам использовать ОРМ или что-то другое, так и будешь собирать проблемы в одном месте.
Tom>Последние лет 10 этим только и занимаюсь

Это ж скока проблема за 10ть лет то насобирать можно было ?

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

IT>>Пока ты не начнёшь сам использовать ОРМ или что-то другое, так и будешь собирать проблемы в одном месте.
Tom>Последние лет 10 этим только и занимаюсь

Собирательством или применением?

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

ST>>Все изменения, которые можно внести в объекты — это удалить объект, добавить объект, изменить содержимое объекта (Этими же операциями, кстати, покрываются и изменения в коллекциях объектов).
Tom>Tracking изменённых полей я ещё понимаю зачем нужен — но для чего отслеживать изменённые обьекты понимаю не очень. Почему сразу в базу изменения не отправлять? Или это хитрая оптимизация?
Tom>Нужна ли она в действительности

Нам нужна, у нас 90% действий проводиться над несколькими обьектами одновременно, соотвевено нужно накопить изменения, а потом их сбросить. Это UnitOfWork.

IT>Собирательством или применением?
Девелопментом

MC>Нам нужна, у нас 90% действий проводиться над несколькими обьектами одновременно, соотвевено нужно накопить изменения, а потом их сбросить. Это UnitOfWork.
А чем вам транзакции БД не UnitOfWork? Или это не так модно?

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

MC>>Нам нужна, у нас 90% действий проводиться над несколькими обьектами одновременно, соотвевено нужно накопить изменения, а потом их сбросить. Это UnitOfWork.
Tom>А чем вам транзакции БД не UnitOfWork? Или это не так модно?

А сколько времени вы будете ее держать?)

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

ST>>Все изменения, которые можно внести в объекты — это удалить объект, добавить объект, изменить содержимое объекта (Этими же операциями, кстати, покрываются и изменения в коллекциях объектов).
Tom>Tracking изменённых полей я ещё понимаю зачем нужен — но для чего отслеживать изменённые обьекты понимаю не очень. Почему сразу в базу изменения не отправлять? Или это хитрая оптимизация?
Каким образом сразу изменения отправлять? После изменения одного поля? В какой момент?

Tom>Нужна ли она в действительности
При изменияемых объектах конечно нужна.

G>Каким образом сразу изменения отправлять? После изменения одного поля? В какой момент?
Надо поменять данные — меняем сразу.

Tom>>Нужна ли она в действительности
G>При изменияемых объектах конечно нужна.
Или я чего то не понимаю или не прочувствовал но очень длительное время жили без change tracking-а вообще.

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

Tom>Всем привет,

Tom>Хотелось бы в одном месте, например в одном топике собрать все проблемы которые вытекают из обьектно ориентированного способа работы с данными (БД) и использовании ORM средств.

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

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

G>>Каким образом сразу изменения отправлять? После изменения одного поля? В какой момент?
Tom>Надо поменять данные — меняем сразу.
Ну и как это будет выглядеть? Поменяли поле — сразу полетел update?
Боюсь представить как это будет тормозить.

Tom>>>Нужна ли она в действительности
G>>При изменияемых объектах конечно нужна.
Tom>Или я чего то не понимаю или не прочувствовал но очень длительное время жили без change tracking-а вообще.
Потому что работали с неизменяемыми объектами.
Когда работают с запросами результаты выборки обычно не меняются (незачем просто).

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

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

MC>>>Нам нужна, у нас 90% действий проводиться над несколькими обьектами одновременно, соотвевено нужно накопить изменения, а потом их сбросить. Это UnitOfWork.
Tom>>А чем вам транзакции БД не UnitOfWork? Или это не так модно?
ИМХО грубовато....

M>А сколько времени вы будете ее держать?)
+1, а если это еще и меджу базами данных, так оно еще и в дистрибутед тразакцию ескалируеться.

Плюс к этому еще есть 1) локи, 2) есть ретрив операции которые хорошо оптимизируються кешами...