Доброго дня, коллеги) Меня вот интересует вопрос, есть ли 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,

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

ViPRos,

Муть какая-то! А при чем тут ORM? И зачем мне генерирование пользовательских интерфейсов? Думаю вы путаете мягкое с теплым. Или вообще не читали о чем здесь идет речь

ViPRosну ОРМ какой вы хотели там встроен, потому и писал

Только она отдельно не продается и уж об исходниках вообще говорить не приходится. Идите занимайтесь рекламой в другом месте, терпеть не могу, когда так делают.

ViPRossibkit,

никто ничего не рекламирет, а куски которые вас интересуют можно было обсудить
там всего-то несколько сотен строк

То, что мне надо, в несколько сотен строк кода не может уложиться. Как минимум надо сделать реализацию диалекта, хотя бы для одной СУБД (Это уже несколько сотен строк кода) + механизмы трансляции объектного запроса (аналог ICriteria в хибернэйте - и тут малой кровью не обойтись). По моим предварительным оценкам это около 3-4 человекомесяцв. Это при том, что всё максимально просто. Главное, чтобы это была работоспособная и действительно полезная система.
Окончательное решение еще не принято. Но Nhibernate уже реально усложняет жизнь (Сегодня реализовывали механизм клонирования графа сущностей для пересохранения в БД - вот сейчас анализирую - в Датасете это пол часа делов, с хибернэйтом же приходится изрядно поизвращаться тут и клонирование через сериализацию и инициализация индивидуальная для каждого типа элемента.
Моё мнение: Хибернэйт отличная штука, но только не для очень больших и не наделенной сложной логикой проектов. Когда приходилось разрабатывать web приложения, как сейчас помню - Nhibernate был просто идеальным инструментом.

ViPRos,

Я тя умоляю, ну не надо постить сюда скриншоты. Лучше расскажи как устроена ваша ORM и продаете ли вы сместе с исходниками? Если нет, то и рассказывать ничего не надо. Не надо больше скриншотов

ViPRossibkit,

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

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

Курдльsibkitбез хранимых процедур иногда просто не обойтись.

А мне, пожалуйста, расскажите, какой в них смысл?!! Я считаю, что без триггеров сложно обойтись - они являются элементом поддержки целостности данных и логики предметной области. Но на кой черт нужны ХП?!!

Когда требуется обработать большое количество данных и тянуть их на клиента нецелесообразно.

Ну а вообще я сам стараюсь избегать их использования. Везде где можно без них - делаю без них. Бизнес логика в БД - это дурной тон

ViPRos,

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

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

ViPRossibkit,

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

Ёптиль моптиль, ну это сильно ограничивает её применение. ИМХО, только для чего-то типа справочников. Вот у меня сейчас сразу такой элементарный пример: Есть, например, заявка и менеджер. У заявки есть состояние и есть ссылка на менеджера. Так вот, в зависимости от состояния заявки (Зарегестрирована, Обрабатывается, отменена), изменения в нее может вносить либо один (на которого ссылка) либо все менеджеры. Как это можно разрулить?