Каковы критерии оценки ORM для .NET? [закрыто]


30

Я смотрю на оценку ОРМ.

Я использовал SubSonic , Linq-to-SQL и Entity Framework . У меня есть команда разработчиков от юниоров до старших.

Каковы критерии оценки ORM для .NET?


8
Там нет лучшего. Есть много вариантов, которые имеют множество плюсов и минусов. Каждый приносит что-то свое на стол.
Тони

Одно утверждение по терминологии: я бы сказал, что SubSonic, безусловно, не ORM. Больше о .. реляционном объекте. Он может генерировать только классы, которые непосредственно отражают схему таблицы вашей базы данных. По большей части он работает нормально, но этот момент дизайна очень важен, поскольку он находится на совершенно ином игровом поле, чем EF & NHib.
Квентин-старин

1
@qstarin: это делает SubSonic такой же ORM, как LINQ-to-SQL.
Джон Сондерс

очень хорошая мысль, Джон и qstarin. это тонкая грань того, что вы бы отнесли к категориям как средство реляционного объекта. SubSonic 3.0 предлагает функции, которые соответствуют концепции ORM. Вики говорит. «Преобразование данных между несовместимыми системами типов в объектно-ориентированных языках программирования. В результате создается« база данных виртуальных объектов », которую можно использовать из языка программирования». Более того, на ormbattle.net SubSonic рассматривается как ORM. Спасибо вам обоим за ваши отзывы
Ник

2
Я вижу, что Linq-to-SQL больше похож на прославленный генератор sql, чем на ORM ...
fretje

Ответы:


43

Это загруженный вопрос.
Есть много очень хороших ORM, подходящих к предмету с различными философиями.
Ни один из них не совершенен, и все становятся сложными, как только вы отклоняетесь от их золотого пути (а иногда даже когда вы придерживаетесь его).

Что вы должны спросить себя при выборе ORM:

  1. Что это нужно сделать для вас?
    Если у вас уже есть набор требований для вашего приложения, вам следует выбрать ORM, который лучше соответствует этим, а не гипотетический «лучший».

  2. Ваши данные являются общими или только локальными?
    Большая часть проблем в ORM вызвана тем, как они обрабатывают параллелизм и изменения данных в базе данных, когда несколько пользователей хранят версии одних и тех же данных.
    Если ваше хранилище данных предназначено для одного пользователя, то большинство ORM будут работать хорошо. Однако задайте себе несколько сложных вопросов в многопользовательском сценарии: как обрабатывается блокировка? Что происходит, когда я удаляю объект? Как это влияет на другие связанные объекты? Работает ли ORM близко к металлу бэкэнда или кэширует много данных (повышение производительности за счет увеличения риска устаревания).

  3. Хорошо ли адаптирован ORM для вашего типа приложения? С конкретным ORM может быть сложно работать (много производительности, сложно кодировать), если он используется в службе или находится внутри веб-приложения. Это может быть хорошо для настольных приложений.

  4. Вы должны отказаться от специфичных для базы данных улучшений?
    ORM, как правило, используют набор SQL с наименьшим общим знаменателем, чтобы гарантировать, что они работают с большим количеством различных серверных баз данных.
    Все ORM будут скомпрометированы с доступными функциями (если только они не предназначены специально для одного бэкэнда), но некоторые позволят вам реализовать дополнительные варианты поведения для использования определенных улучшений, доступных в выбранном вами бэкенде.
    Типичным улучшением, связанным с БД, являются, например, возможности полнотекстового поиска; убедитесь, что ваш ORM предоставляет вам доступ к этим функциям, если они вам нужны.

  5. Как ORM управляет изменениями в модели данных?
    Некоторые могут обновлять БД автоматически в определенной мере, другие ничего не делают, и вам придется делать грязную работу самостоятельно; другие обеспечивают основу для обработки изменений, которая позволяет вам контролировать обновления базы данных.

  6. Не хотите ли вы связать свое приложение с объектами ORM или предпочитаете обрабатывать POCO и использовать адаптер для постоянства?
    Первый обычно прост в обращении, но везде создает зависимости от объектов данных, специфичных для ORM, последний более гибок, за счет немного большего количества кода.

  7. Вам когда-нибудь понадобится передавать свои объекты удаленно?
    Не все ORM одинаковы, когда дело доходит до извлечения объектов с удаленного сервера, внимательно посмотрите на то, что возможно или невозможно сделать. Некоторые из них эффективны, другие нет.

  8. Есть ли кто-то, к кому вы можете обратиться за помощью?
    Есть ли хорошая коммерческая поддержка? Насколько велико и активно сообщество вокруг проекта?
    Какие проблемы возникают у пользователей с продуктом?
    Получают ли они быстрые решения?

Несколько ORM, на которые я смотрел:

  • XPO
    От разработчика Express: маленький и простой, ориентированный на код. Они используют его для своей прикладной платформы eXpressApp .
  • NHibernate
    бесплатный, но кривая обучения довольно крутая. Много вкусностей, но иногда трудно найти то, что действительно актуально во всей фрагментированной документации.
  • LLBLGen Pro
    очень зрелый проект, в него вложено не самое простое, но много мыслей.
  • Entity Framework
    . Последние релизы довольно хороши, и MS слушает, хотя это все еще немного молодо по сравнению с другими более зрелыми ORM.
  • DataObject.Net
    выглядит многообещающе, но также немного новичок, чтобы рисковать важным проектом, имхо. Впрочем, довольно активно.

Есть много других, конечно.

Вы можете взглянуть на противоречивый сайт ORM Battle, в котором перечислены некоторые критерии производительности, хотя вы должны знать, что предварительная скорость не обязательно является наиболее важным фактором для вашего проекта и что создателями веб-сайта является DataObject.Net.


3
Зная это, что ты выбрал?
Стивен Эверс

спасибо Renaud Bompuis, я не слышал о некоторых из перечисленных ORM. Предоставленная вами информация - отличная пища для размышлений, спасибо.
Ник

1
@SnOrfus: все еще использую XPO, но я собираюсь перейти на LLBLGen, он твердый, зрелый, и вы сохраняете контроль (так что вы все равно можете испачкать руки, если хотите / хотите), и это позволяет более адекватно разделять проблемы и повторное использование объекта (через адаптер).
Рено Бомпю

3
Стоит отметить, что Entity Framework сейчас находится в версии 4.1 и, безусловно, стоит посмотреть.
Шон Кирон

Мне нравятся Stored Procs на сервере и LINQ на клиенте. Попробуйте понизить это! Нет обучения, никаких сюрпризов, никаких версий, никаких сюрпризов!
NoChance

14

Я использую NHibernate и нашел его довольно хорошим.

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

Это не займет много времени, чтобы начать работу - просто сопоставьте ваш объект с моделью - я использую XML-файл, но вы можете свободно делать это в коде. Есть отличное сообщество, и лично я считаю, что работа Айенде очень полезна - я использую NHProf, который является инструментом профилирования SQL.

Я в основном использую готовые функции - прямое сопоставление объектов, но я также использую Hibernate Query Language, который довольно легко освоить.


Будьте осторожны, NHibernate может быть сложнее для более сложных моделей. Все это хорошо документировано и имеет очень хороший смысл, но если вы не знаете, вы можете столкнуться с проблемами. То есть кривая обучения высока, но она превосходна.
Мэтт Оленик

спасибо Сэм, я не использовал nhibernate, однако, по-видимому, он требует обширной настройки по сравнению с SubSonic, Linq-to-SQL и Entity Framework. Это не было бы идеально для моей команды разработчиков.
Ник

Если вам интересно, Айенде проводит семинар NHibernate на конференции YOW в Австралии - yowconference.com.au/melbourne/events_tracks/… - в ноябре / декабре. Один из парней, с которыми я работаю, какое-то время пользовался им, поэтому мне было полезно учиться у него.
Сэм Дж

3
@ Ник большую часть конфигурации можно автоматизировать. Я также проверил бы свободное дополнение.
stonemetal

@Nick, @stonemetal согласился, Fluent NHibernate делает вещи намного проще. Это не так быстро, как SubSonic, но все же стоит посмотреть.
Мэтт Оленик

6

К сожалению, на моих последних трех работах у нас было три доморощенных ОРМ. В каждом случае они в основном сосали по разным причинам.

Недавно я оценивал Entity Framework 4 и его поддержку POCO (хороший обзор здесь ), и я действительно впечатлен тем, насколько приятно это не смотреть мне в лицо и заставляет меня чувствовать, что я снова программирую, а не собираю данные.


Я слышал, бывшие рабочие места, в которых я был похож на доморощенных ОРМ. спасибо за отзыв.
Ник

3
Доморощенные ОРМ всегда отстой. Лучшие из них всегда хуже, чем самые грязные публичные ОРМ.
Жак Преториус

@JacoPretorius Есть контрпримеры к этому ... но "как правило" ...
Pst


3

Мне очень нравится Linq to Sql. Все просто и имеет достойного дизайнера. Тем не менее, я надеюсь до конца жизни в пользу Entity Framework. Я хотел бы иметь возможность использовать возможность модифицировать генераторы, чтобы иметь возможность настраивать объекты.

Самое большое преимущество, которое они имеют перед другими (по моему мнению), состоит в том, что они из коробки с VS. Это также отрицательно в том, что вы находитесь во власти MS (см. Linq to Sql).


3

[ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: я работаю на DevExpress]

Вы можете увидеть скриншоты типичных приложений , созданных с помощью DevExpress сред разработки приложений здесь . Эта страница также содержит очень краткий обзор наших продуктов. Для более подробной информации о том , почему , я предлагаю вам проверить соответствующие страницы продукта на нашем веб-сайте.

Что касается DevExpress XAF и XPO, здесь есть хорошее объяснение того, почему следует выбирать наши прикладные платформы. Кроме того, мы предоставляем поддержку и документацию, что также важно и стоит упомянуть. Не стесняйтесь обращаться к нам в случае каких-либо вопросов.


Я все еще использую XPO, и я рад предстоящим обновлениям.
Рено Бомпюи

2

Мы используем NHibernate + Fluent NHibernate, с Linq-to-Sql для небольших проектов. Причиной этого является:

1) (Не основная причина) NHibernate, кажется, имеет более высокий фактор «уважения» среди разработчиков (это правда?),

2) По сравнению с linq-to-SQL, nHibernate позволяет отображать ORM между объектами Db и объектами, которые не отображаются 1-в-1,

3) Мы не сравнивали nHibernate с Entity Framework 4.0, но вот хорошее сравнение: http://ayende.com/blog/archive/2010/01/05/nhibernate-vs.-entity-framework-4.0.aspx

В nHibernate есть довольно крутая кривая обучения, и его карты XML могут быть довольно многословными, но начните с документации сайта Fluent Nhibernate и вернитесь назад.


1

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

С другой стороны, есть ряд очень хороших, некоторые из которых будут лучше соответствовать вашим личным обстоятельствам и философии, чем другие.


Изменить: Для чего стоит, я в настоящее время использую Linq для SQL - в основном потому, что он там, хотя отчасти потому, что он делает много правильно для минимальных усилий и, вероятно, снова перейдет к Entity Framework «потому что там есть» (хотя аналогично есть и много о EF4, что верно, а также кое-что, что не так). Беспокойство, особенно в отношении последнего, должно было бы быть связано с производительностью, но для большинства моих случаев это не является большой проблемой, и возможность запуска динамических данных и OData из моделей (L2S и EF) имеет для меня значительные преимущества с точки зрения " дешевый "выигрывает.


Спасибо за ваш отзыв Мерф. Я согласен с «лучшим» ОРМ. Тем не менее, я смотрю, чтобы ввести такую ​​более стандартизацию. Использование одного из ORM поможет новому разработчику и существующим разработчикам в моей команде. В настоящее время становится все труднее перемещаться между проектами и сервисами: subsonic, ADO.net, linq-to-sql и т. Д.
Ник

О, у меня нет проблем с поиском наиболее подходящего ORM для ваших вариантов использования, и я полностью согласен с желательностью задать вопрос поблизости. Я просто веду бесполезную кампанию против использования слова «BEST» в вопросах обмена стеками (-:
Мерф

1

Я бы посоветовал вам взглянуть на DevExpress XPO . Это вместе с DevExpress XAF облегчит жизнь любому разработчику, когда его кривая обучения будет пересечена.


XAF основан на XPO, который является ORM. Сам XAF основывается на этом и добавляет логику, «автоматический» интерфейс и т. Д.
Саша

Пожалуйста, объясните, почему вы считаете, что DevExpress XAF облегчит жизнь разработчику.

@ Саша, спасибо за подсказку. Я исправил свой пост.
Йоги Ян 007

@Mark, XAF наряду с XPO работает как ORM, а также как генератор UI, поэтому разработчику становится легко создавать полнофункциональные приложения в .NET с минимальным кодированием.
Йог Ян 007

Один комментарий с моей стороны к XAF: это отличная система для средне-сложных бизнес-логических сред, так как она ускоряет время разработки для тех, кто на них влияет. Недостатком является то, что на заданных границах его расширение занимает много времени. Например, иерархические пользователи (наряду с логикой, подобной командам) и «пользователь может видеть только элементы себя и / или своих подчиненных» не поддерживаются «из коробки». Таким образом, у XAF есть свои плюсы и минусы, и его действительно нужно оценить, если он подходит для проекта - ИМХО. Но это определенно хорошо сделанная основа, если она подходит.
Саша

1

Нам повезло с Entity Framework. Однако наша ситуация несколько необычна - мы собираем данные для группы отчетности, поэтому они фактически проектируют базу данных. Мы получаем БД, а затем просто используем EF для генерации классов доступа к данным из нее. Для нас это прекрасно работает, но мы просто выполняем массовую загрузку данных, поэтому я не могу поручиться за то, насколько хорошо это работает в более транзакционной среде.


2
Да, я фанат EF 4, он намного лучше, чем предыдущая версия.
Ник

1

NHibernate (+ FluentNHibernate) будет вариант по умолчанию для меня. Это очень гибкий, расширяемый и надежный. У него огромное количество пользователей, и он очень активно поддерживается. Недостатком является крутая кривая обучения.

LightSpeed ​​от MindScape прост и удобен, но все же достаточно гибок и способен. Он имеет дизайнерскую поверхность, такую ​​как L2S / EF и реализацию UnitOfWork.


LightSpeed ​​от MindScape выглядит действительно интересно.
Ник

1

Ну, нет лучшего выбора, но я бы сказал, что обычный старый Linq to SQL отвечает вашим потребностям. Это не «настоящий» ORM как таковой, но он очень легкий и дает вам гибкость в написании кода, даже не подозревая об этом, если это имеет смысл. Я имею в виду, что вы можете продолжать писать код в обычном режиме, не зная о Linq, кроме наличия dbmlфайлов. Вы по-прежнему можете писать над ним абстракции, используя шаблоны Repository или Gateway, и L2S выполняет основную роль ORM, которая заключается в обходе несоответствия объектов и отношений.

Entity Framework немного тяжеловат, и хотя я лишь немного поболтал с ним, он более «в твоем лице», чем базовый Linq to Sql, но EF намного больше истинного ORM, чем Linq. Я бы посмотрел на все критерии, которые вы ищете в ORM. Это просто потому, что вы хотите избежать написания необработанного SQL или, что еще хуже, иметь сотни хранимых процедур? Вам нужны какие-то дополнительные функции, которые не могут предоставить необработанные Linq to Sql? Вам нужно ответить на эти вопросы, но, исходя из ваших кратких требований («легкий и простой в использовании»), я думаю, что Linq немного проще, чем что-то вроде Subsonic, и встроен в Visual Studio.


0

ECO :) Это гораздо больше, чем ORM, в то время как поддерживаются конечные автоматы и исполняемый OCL (а именно EAL). Существует бесплатная версия с ограничением на 12 классов доменов, которая, на мой взгляд, должна быть очень удобной для небольших проектов.


4
Было бы полезно, если бы вы объяснили почему.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.