Доброго дня, коллеги) Меня вот интересует вопрос, есть ли ORM удовлетворяющая следующим требованиям:
1. Отсутствие сессий, работа с сущностями по принципу (ProductRepository.Insert(product) /Update(product). т.е. во первых: вся каскадность ложится на плечи репозитория а не задается в маппинге. во вторых: Все изменения в базу данных обозначаются в явном виде.
2. Самодостаточность (Нет необходимости вручную писать запросы к БД). Т.е. генерация SQL
3. Открытый исходный код, или хотя бы возможность его купить (очень не маловажная деталь).

Т.е. вообще я представляю себе идеальную ORM как гибрид датасета с NHibernate. от NHibernate оставить критерии и идею маппинга (так чтоб небыло необходимости наследоваться от каких-то классов). А принцип сохранения и загрузки аля DataSet.

Ваше мнение?

МСУsibkitА принцип сохранения и загрузки аля DataSet.
Нахрена?

Это даст возможность в ручную определять что сохранять, а что удалять и как. Не гоняя циклом сущности в интерцепторе.

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

С полезностью писать запросы самому я не соглашусь. Т.к. анализируя последние месяцы работы понимаю, что написал бы их уже миллион (И это самый большой минус датасета кстати). Nhibernate-вские критерии позволяют очень просто генерировать запросы при этом довольно качественно. (Хочу тут похвастоваться, что исправил баг в исходниках NHibernate, не позволяющий использовать одну таблицу в одном запросе несколько раз :)).

Объектные СУБД не устраивают в плане того, что не всегда приходится всё делать с нуля и очень часто попадаются проекты под уже спроектированную и заполненную базу данных.

Собственно NHibernate это то в чем я сейчас, и уже достаточно давно работаю, но у него есть большие минусы.
Во первых: Я не понимаю как масштабировать проект с его использованием (Думаю, что никак). Т.е. когда библиотека DAO с маппингом и всем вытекающим не одна (Пример: Компания ведет деятельность по разным направлениям, соответственно касса одна, менеджеры одни, клиенты одни, а вот логика CRM систем совершенно разная) Было бы идеально реализовать возможность дополнения маппингом уже существующие библиотеки.

Во вторых: NHibernate очень не прозрачно отслеживать все изменения. Гораздо удобнее делать Update(entity), чем Flush().
В третьих: к NHibernate приходится писать много костылей, он очень мощный, но куда не капни поглубже везде есть грабли свои (Например сейчас столкнулся с проблемой абстрактных классов - загружаю объект абстрактного класса, а он прокси и приходится педальным способом выяснять что это за объект)


Собственно к чему я завел эту тему. Буквально пол года назад мне кто-то сказал, что пишет свою ORM - тогда я над ним посмеялся. А сейчас поработав и полностью проникнувшись двумя технологиями у меня уже накопилось достаточно идей, как можно собрать самое лучшее из DataSet и NHibernate. Просто очень не хочется изобретать велосипед.

SolYUtorsibkit
Это даст возможность в ручную определять что сохранять, а что удалять и как. Не гоняя циклом сущности в интерцепторе.

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


Бывают случаи, когда хибер не применим (или плохо применим). К примеру, обновлять 100 000 записей будет мучительно долго. Но я бы повнимательнее посмотрел на ваша архитектуру, может в ней проблема.


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

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


Иногда такие случаи бывают, когда проще решить именно запросом. Ясное дело для банальных CRUD Nhibernate гораздо удобнее.


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

SolYUtor
sibkit
Собственно NHibernate это то в чем я сейчас, и уже достаточно давно работаю, но у него есть большие минусы.
Во первых: Я не понимаю как масштабировать проект с его использованием (Думаю, что никак). Т.е. когда библиотека DAO с маппингом и всем вытекающим не одна (Пример: Компания ведет деятельность по разным направлениям, соответственно касса одна, менеджеры одни, клиенты одни, а вот логика CRM систем совершенно разная) Было бы идеально реализовать возможность дополнения маппингом уже существующие библиотеки.

Что вы понимаете под масштабированием?
Что мешает замапить существующие библиотеки?


Что касается "масштабирования" - здесь я возможно не правильно выразился. Имеется ввиду наращивание функционала всей системы в целом (включающей несколько проектов), без изменения работающих проектов и с возможностью использовать существующий код (в виде dll библиотек)

SolYUtor
sibkit
Во вторых: NHibernate очень не прозрачно отслеживать все изменения. Гораздо удобнее делать Update(entity), чем Flush().
В третьих: к NHibernate приходится писать много костылей, он очень мощный, но куда не капни поглубже везде есть грабли свои (Например сейчас столкнулся с проблемой абстрактных классов - загружаю объект абстрактного класса, а он прокси и приходится педальным способом выяснять что это за объект)

Что мешает делать Session.SaveOrUpdate()?
Зачем выяснять настоящий тип абстрактного класса? Вы про SOLID принципы слышали?

Причем здесь SaveOrUpdate? Если сущность в сессии, то при флаше изменения в ней сохраняются в базу. независимо от того делался ей Session.SaveOrUpdate или Session.Update. Читайте теорию.

Что касается абстрактных классов, то требуется не просто выяснить тип, а дозагрузить этот класс. Сейчас я это делаю вот таким вот костылем:
if (line.Subject.SubjectTypeIndex==1)
{
CalculationRecurciveSubject cps = session.Get<CalculationRecurciveSubject>(line.Subject.Id);
}
возможно, это оттого, что у меня не самая последняя версия, но тем не менее, приходится вставлять костыли. А вот ваш вопрос "Зачем выяснять настоящий тип абстрактного класса?" считаю глупым.

SolYUtor
sibkit
Собственно к чему я завел эту тему. Буквально пол года назад мне кто-то сказал, что пишет свою ORM - тогда я над ним посмеялся. А сейчас поработав и полностью проникнувшись двумя технологиями у меня уже накопилось достаточно идей, как можно собрать самое лучшее из DataSet и NHibernate. Просто очень не хочется изобретать велосипед.


Давайте. Всласть поработав над своим маппером, поймёте, почему nhibernate такой, какой он есть.
Прекрасно представляю объем работы который придется совершить. Nhibernate далеко не совершенен.

МСУP.S. А, вообще, тема ниачём.
Тема о том, чтобы заменить NHibernate на что-то более управляемое и логически связанное. Вообще когда создавал, надеялся получить описание решения описанных проблем, например, в других мапперах, (т.к. сам все не изучишь - да и смысла нету). Но, возможно уже есть решение, которое мне подойдет - это был бы идеальный вариант.

Что касается идеи по поводу создания своего маппера: Я не ставлю перед собой цели создать что-то грандиозно громоздкое, наподобие NHibernate или EF. Вообще есть вот такие мысли:

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

Вот собственно и всё. Иными словами это датасет, только привязанный к критериям по имени классов и с классами вместо строк (что позволяет делать рефакторинг).

КурдльDataRelation, а не "constrain"
Да, верно DataRelation, а еще как вариант динамически создаваемые связи, чтоб в коде выглядело типа:
DataStorage ds;
Order order;

IRelation relation = new Relation<Order,OrderItem>("Id","OrderId");
IList<OrderItem> items = ds.Load(order,relation);

МСУЯ не вижу в хибере что-то неуправляемое и несвязанное логически. В любой ORM есть свои достоинства и недостатки. Одних - устраивает, других - нет. Во-вторых, никогда не поздно начать писать SQL-запросы вручную.

При всем уважении к NHibernate (я только на нем работаю с 2007-го) Было написано очень много всяческих костылей к нему, саморучно исправлены баги и изучен он мной просто вдоль и поперек. При этом вспоминая работу с ADO.NET вспомнил всю гибкость, при построении бизнес логики и удовольствие от полного контроля загрузки и сохранения данных. ИМХО лэйзи загрузки это такой напантованный механизм, который при первом взгляде красив и чертовски удобен, а при разработке сложных проектов становится непосильной ношей - у меня половина времени разработки уходит на отслеживание и проверки где там что загрузилось как сохранилось. + так или иначе NHibernate тянет лишние данные из базы. А при сложной структуре данных работа с ним превращается в какой-то ад.

МСУБольше времени потеряете, чем пользы будет.
Пользу сложно переоценить. Естественно, что тут, человеко-месяцем разработки не отделаешься, даже для самой примитивной реализации. И очень бы хотелось найти что-нибудь уже готовое (помоему раз четвертый это уже повторяю :)) Но когда на кону стоят проекты в 1000 человеко-месяцев, думаю 10-20 из них целесообразно выделить на разработку механизма, позволяющего прозрачно и гибко работать с данными.

ViPRossibkit,

есть у нас такое, никакого маппинга и т.д., но БД проектировать надо в самой системе :)
А что это такое? можно подробнее?