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

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

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

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

Это загруженный вопрос.
Есть много очень хороших 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.

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

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

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

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

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

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

Сравнение ORM и тесты на ORMBattle.NET

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

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

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

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

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

Мы используем 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 и вернитесь назад.

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

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

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

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

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

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

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

Ну, нет лучшего выбора, но я бы сказал, что обычный старый 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.

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