2 топик стартер

Посмотрите вот этот обзор http://yuryskaletskiy.blogspot.com/2008/07/net-orm.html
Правда с минусами Nhibernate я полностюь не согласен, видимо вопрос о смене Nhibernate для автора был уже решен по другим причинам.

Тем не менее, обзор полезен, тем что вы можете провести своё исследование на эту тему и сопоставить результаты.




Posted via ActualForum NNTP Server 1.4

SeVa
Да, причина одна - все ORM слабо подходят для реальной жизни

чем обоснованно такое громкое заявление?
Posted via ActualForum NNTP Server 1.4

не хочу открывать холивар, отвечу кратко по существу.
SeVa
Объектная модель плохо стыкуется с реляционной,
....
Это "громкое" утверждение и в wiki присутствует Object-relational impedance mismatch

для этого и существуют ORM, которые позволяют сгладить все шероховатости, нормальная БД = нормальная стыковка, мы лично не испытываем вообще никаких проблем с этим.
Более того, структура БД генерируется на основе Объектной модели, а не наоборот.
SeVa
,ленивая загрузка и прочее шаманство.

ленивая загрузка это не из терминов ORM вообще, я делал ленивую загрузку или load on demand загрузка по требованию и до применения объектного подхода.
SeVa
Весьма сомнительный выигрыш только в одном - не нужны серверные процедуры,но за счет этого получаем жирный минус - низкая производительность(кеширование придумано не от хорошей жизни).

нормальные ОРМ нормально держат ХП.

Более подробно почитайте последнюю книгу Нильсона. Этот человек как раз занимался тем что использовал реляционный подход, затем перепрыгнул на ОО стал использовать ОРМ. и подбробно описал всю мотивацию, также честно указал недостатки этого подхода, но вывод один если вы хотите успешно решать серьезные задачи без DDD не обойтись.


Posted via ActualForum NNTP Server 1.4

SeVa
Вряд ли такие базы можно назвать нормальными с точки зрения DBA.Принципы
проектирования у них совсем другие.Разработчики клиентской части часто
перетягивают на себя одеяло и ноги чувствуют себя неудобно.

получаемые БД нормальные и правильные с точки зрения DBA
какие либо специфичные вещи теже, ХП например, добавляются в автоматическом режиме при генерации основной схемы БД.
Структура БД и работа с ней, покрыта тестами, планы запросов идеальны. присутствуют необходимые ключи, ссылочная целостность, что ещё нужно для счастья?
Может быть расстроится тот DBA, который не любит использовать суррогатные ключи, а использует настоящие бизнес ключи в соответствии с классикой жанра ))

SeVa
В жизни модели предметной области ничего не знают о БД, оптимальный вариант,когда
они совершенно не зависят от DAL и структуры хранения.ORM - это попытка
скрестить ужа с ежом и для DDD совершенно необязательная


Как объекты с БД получать будете?
ORM это обычный мост, между DM и DAL, чудес на свете не бывает, данные каким либо образом всё таки должны перекочевать из реляционной формы в объектную.
Кто то делает это вручную при помощи DataReader например, кто то предпочитает использовать проверенные временем готовые решения.
Также данные каким то образом должны попасть в БД, здесь тоже ограничений нет, хотите используйте ХП, хотите напрямую динамическим запросом.
Кому то нравится вручную или при помощи неких хелперов создать экземпляр класса SqlCommmand и вызвать его метод Execute.... я предпочитаю вызвать соответствующий метод у объекта-репозитория - myRepository.Save(obj);
В итоге, результат должен быть одинаков, если только программист в первом случае не ошибся в Sql запросах либо ещё где, а DBA в тоже самое время, не поменял что либо в БД.

Почитайте The Productive Programmer by Neal Ford, в середине книги описана поучительная история, когда стали городить свой некий ОРМ, со времнем развития проекта, это нечто обрастало неким функционалом, в итоге автор отметил, что если вернуть время назад, то он бы не стал тратить время зря и использовал бы готовое решение такое как ibatis или nhibernate, которое отмел на первой фазе разработки.

Резюме:
не нужно быть столь категоричным, есть вещи которые всегда останутся на стороне сервера и вещи которые можно смело выносить, одно другому не мешает, совмешайте подходы и будет счастье.
ещё раз обратите внимания на книгу Нильсона там вся мотивация есть, читайте, изучайте, пробуйте, тогда будет что обсудить, удачи )



Posted via ActualForum NNTP Server 1.4

>Оптимальные планы запросов для ORM и структура БД при таком проектировании - это из области фантастики.Подобная тема обсуждалась уже на форуме MS SQL

если БД правильная, проиндексована по требуемым полям, то и планы запросов правильные, можно обратный пример?

>С ORM, в частности с Hibernate, имел опыт работы(поэтому и выводы такие),когда по ним еще книжки не писали.

может быть тогда и стоит аппелировать именно к тому времени, и говорить о том, что тогда в области ОРМ у вас был отрицательный опыт работы с java Hibernate.

Я не говорю что ОРМ это панацея, который стоит пытаться применять везде, часть работы никак нельзя забрать у RDBMS, в тоже время в сложных приложениях, где приходится работать с объектами данные которых приходится подымать из БД, ОРМ является волшебной палочкой-выручалочкой.

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

> Это утверждать может только разрабтчик клиентской части

заинтрегован, давайте подробнее про БД, что дополнительно требуется?


>NHibernate - всего лишь порт с java Hibernate c с документацией по нему в самом подвале документации по Hibernate

Прежде чем говорить о чём то, наверное логичнее всего сначала посмотреть. как обстоят дела с литературой и документацией по NHibernate, является ли Nhibernate всего лишь портом с Java Hibernate и др.


>Да,знают об этом мужики,чтобы убедиться в этом, достаточно почитать обсуждения статьи,которою я приводилтынц.Запомнилось одно высказывание:Певоначально любая технология кажется молотком,которым можно забить любой гвоздь.Но ORM-это молоток,которым пытаются размешивают бананы.Эта технология применима,но с очень большими ограничениями.

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

SmD
Взгляд остановился на NHibernet && BLToolKit
В общем и частном эти фреймворки покрывают мои требования, но в каждой из них есть свои плюсы и свои минусы.
Вот например, тут в споре прозвучала фраза, что ORM навязывают свою политику проектирования бд. (немного перефразировал, но смысл вроде не поменялся).
Абсолютно НЕ согласен. ORM это чулок, который можно натянуть на любую ножку.
Далее было высказывание, что при использовании ORM есть сложности в оптимизации ( т.е. сказали, что "если правильно расставлены индексы..." и т.д.) Тоже не согласен, например при использовании BLToolKit мы можем сами составлять запросы, которые будут выбирать наши данные и превращать их в объекты. (чего нельзя сказать про NHibernate) Соответсвенно, если мы составляем запросы, то...

BLToolkit и NHibernate не в одной весовой категории, тем не менее интересно будет посмотреть на результаты тестирования.
Что касается что первично реляционная структура или объектная, то я отдаю предпочтение объектной (как завещал Буч :) ) т.е. при разработки новой системы, мы работаем только с POCO и маппингами NHibernate.
Вся проверка маппингов осуществляется на sqllite, это очень быстро и не требует установку какой либо отдельной СУБД. Остальные рюшечки, в виде schema, index, sp, view навешивается во время генерации запуском дополнительного DDL скрипта.

По поводу BLToolKit, у меня не было возможности достаточно близко пощупать его, но если я вас правильно понял по поводу превращения данных в объекты, то подобные свойства присущи и NHibernate, также в NHibernate существует возможность управлять запросами : join или select n+1, batch и т.д.

Кроме этого, в транке появилась новая возможность помечать объект ICriteria или IQuery как Future(), имея возможность спокойно насоздавать кучу Future(), а затем выполнить эти несколько запросов в один присест посредством MultiCriteria или MultiQuery.

Резюме: интересно было бы увидеть что есть в других фрейморках, того чего нет в Nhibernate, самому проводить исследования нет времени, практически Nhibernate закрывает весь требуемый функционал. но а вдруг ... :-)


Posted via ActualForum NNTP Server 1.4

SeVa
Я уже давал ссылку - CSLA,который в отличии от BtToolkit, постоянно развивается и есть отличная документация-книги,активный форум и масса других вкусностей.Сейчас появилась версия и для Silverlight(у меня большие подозрения,что это будет мейнстрим в ближайшие годы).DAL там на выбор разроботчика,есть и любители проверенных годами средств
ORM - не синоним DDD.Тот же Буч,сказал, что принципы ООП совершенно непригодны для БД.

BlToolkit и CSLA вообще некоректно даже ставить вместе, даже Nhibernate и CSLA можно сравнивать только в рамках сферы их пересечения в ОРМ тематике.
Сам CSLA я не использовал,читал книгу Expert C# 2005 Business Objects, пожалуй была одна из первых подробно посвященной сабжевой тематике, но то что я там увидел меня не обрадовало.
Я за честную модель предметной области, там же предлагалось использовать какие то базовые классы и садить всю домайн модель на необоснованое наследование.
Буду рад, если что то не догнал и заблуждаюсь. Поэтому интересно, в чём же заключается бенефит от использования CSLA , чем лучше чем NHIbernate?

А по поводу высказывания Буча, хм. я не слышал об этом, хотелось бы получить ссылку на эту фразу, по моему Буч как раз строил некое гибридное решение используя РБД и ОО подход, при чём всё это и выползало в некое отображение реляционных данных в объектные, читай ОРМ, только в отличии от крутого Буча мы не будем писать свой ОРМ, а воспользуемся готовым решением и подберем красивый чулок с нужными рюшечками-фичами )
Мой опыт показывает, что принципы именно объектного анализа прекрасно применимы в реляционной БД, теже сущности и связи, разработчик РБД пользуется, может быть неосознанно :) , именно объектным подходом при построении концептуальной модели данных.


Posted via ActualForum NNTP Server 1.4

SeVa <nospam@sql.ru>;
Причины моего выбора в пользу CSLA:
- мухи и котлеты разделены.ООП совершенно не зависит от DAL и структуры БД.Соответственно,бизнес-объекты
не накладывают никаких требований на БД и наоборот, нет лишнего слоя со своими
ограничениями, усложнениями и тормозами.В результате -каждый слой полностью под
контролем,полная гибкость в членах и производительность.В каждом из них делаем
только то, для чего он больше всего заточен.

а что не так в этом плане в NHibernate? в чем бенефит всё таки.

SeVa
Базовых классы - это всего лишь обвеска без которой не обойтись: связывание,разграничение
доступа, валидация, сеарилизация,N-level undo,не нужно плодить интерфейсы,единый
код для 2х и 3х звенки и тд.В результате - минимум дополнительных телодвижений

а это уже к ОРМ не относится, с таким же успехом можно заюзать проекты Castle, Spring, Rhino Common

а вот обвеска такая в качестве базовых классов нафиг не нужна, это нарушение чистых классов модели предметной области со всеми вытекающими.


Posted via ActualForum NNTP Server 1.4

SeVa
Мне, в свою очередь, нафиг не нужна такая коряга между ног,как Hibernate. Для работы с БД мне такие косноязыки толмачи совершенно не нужны.Находить на ровном месте себе сложности, а потом их героически преодалевать у меня нет желания

хорошо, когда я говорю что мне что то не устраивает, я называю причину.
что такого есть у NHibernate (надеюсь что речь идет о NHibernate всё таки), что отпугивает вас?



Posted via ActualForum NNTP Server 1.4

SeVa
Для того чтобы не писать процедуры, берем монстроидальную приблуду, в результате получаем: дополнительные тормоза,глюки,ограничения,ставим на уши БД.А теперь ты, попытайся мне объяснить,мимо каких таких сахеров я прошел мимо.Абстрактые рассуждения о завещаниях теоретиков(у БД другие авторитеты) и так должно быть в чистом ООП,сразу будут посылаться в сад.Измерять все будем в моих телодвижениях,потраченных каллориях,в производительности и надежности

Мне теперь понятна ваша мотивация, мностроидальной приблудой в данном случае как раз является фрейморк CSLA, и вы подсадили на него свою DM. Возможно такое жесткое сцепление это нормально, если весь функционал CSLA на 100 % вас устраивает.
Я же предпочитаю как раз чистую модель, имею возможность в любой момент спрыгнуть с Nhibernate.
Для навешивание всяких рюшечек предпочитаю использовать свой собственный DSL.
Я изучу CSLA и возможно в следующей версии, сделаю поддержку CSLA для себя.

Не нашел исходников CSLA не подскажите где их можно взять? )

А Dimistry я посоветую погуглить.
В крайнем случае можно заменить lazy на свои query child.


Posted via ActualForum NNTP Server 1.4

SeVa
Если для прыжков,то в SCLA DAL можно заменить легко.

но reference на сборки CSLA останутся, пока читаю доку, смахивает на шампунь 2 в 1, буду смотреть дальше.



SmD
Выбор элемента по ID с маппингом (мс)
Тулкит 592мс Task _task = query.SelectByKey(_r);
Хибернет 355мс Task _task = (Task)session.Get(typeof(Task).FullName, (long)_r);

+ SeVa
если нужный Task будет в кэше сессии то метод Get вернет его без обращения к БД.
я сравнивал загрузку данных при помощи Nhibernate и при помощи DataReader, каких либо разительных отличий нет,
тем не менее, Nhibernate проделывает больше работы при загрузке данных и соответственно по определению не может быть быстрее чем простой DataReader.



Posted via ActualForum NNTP Server 1.4