Выбор OR Mapper для нового проекта - PullRequest
5 голосов
/ 04 августа 2010

Мы собираемся начать новый проект.Это будет группа веб-приложений с большим количеством общих компонентов.Он будет иметь до 50 000 посещений уникальных пользователей в день, и это будет своего рода панель управления.Все проекты будут собраны в asp.net mvc 2, и все они будут работать в одной базе данных SQL Server.

Мы были очень увлечены NHibernate, пока я не нашел ormbattle.net веб-сайт, где тесты производительности для NHibernate выглядят очень плохо по сравнению с другими картографами.В этом резюме я обнаружил неизвестную мне библиотеку. BLToolkit выглядит действительно многообещающе, но есть и преимущества, и недостатки.

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

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

В этом случае я выбираю один из этих способов:

  1. Не обращайте особого внимания на производительность и используйте Nhibernate или EF или просто L2SQL (какой из них будет лучше?)и использовать ORMapper, который имеет гораздо больше полезных функций.
  2. Сконцентрируйтесь на этой великолепной производительности и создайте собственное решение на основе этого BLToolkit, используя эту библиотеку в основном как очень хорошую базу.Возможно, мне не нужно кэширование, если я буду использовать кэширование действий в MVC.Вероятно, мне не нужны ассоциации, поскольку я могу написать хорошие запросы LINQ с выражениями соединения.Вероятно, мне не нужна ленивая загрузка, поскольку я буду тщательно строить точные методы, которые получат из БД все, что мне нужно.

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

Ответы [ 4 ]

4 голосов
/ 04 августа 2010

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

3 голосов
/ 04 августа 2010

Можете ли вы создать прототипы с парой различных ORM, которые вы рассматриваете, и посмотреть, достаточно ли они эффективны для ваших нужд?Вы могли бы написать некоторый одноразовый код «скачка производительности» и заполнить свои таблицы примерами данных, используя генератор данных в Visual Studio.

Я думаю, что выбор ORM основан на убеждении, что альтернативыне будет работать достаточно хорошо, это преждевременная оптимизация - если вы не сделали тесты, чтобы подтвердить ваши подозрения.

Что касается ormbattle.net, то здесь предполагаемый Ayende - он один из разработчиков NHibernate.Это не так давно, я не знаю, изменился ли ormbattle.net с тех пор.

LINQ to SQL больше не разрабатывается активно - поэтому если вы хотите использовать ORM от Microsoft, EFбыть лучшим выбором.

Я лично предпочитаю NHibernate вместо EF, но в текущей версии EF действительно более полная реализация LINQ, чем в текущей версии NHibernate.NHibernate 3 (выйдет позднее в этом году) будет иметь полную поддержку LINQ, а также еще один API, безопасный для типов, называемый QueryOver .

2 голосов
/ 04 августа 2010

Очень открытый вопрос - в конце дня мы перечислили наши требования / ожидания и пошли оттуда.Вот некоторые из критериев выбора:

  • Поддержка LINQ
  • Поддержка POCO против проприетарных / встроенных объектов
  • Стремительная загрузка / отложенная загрузка
  • Разрешитьпользовательские Sprocs, когда требуется больше энергии

Некоторые ссылки Лучшее ORM для использования с C # 4.0

http://ormbattle.net/

Айенде сравнивает EF4 иNH2,5 + http://ayende.com/blog/archive/2010/01/05/nhibernate-vs.-entity-framework-4.0.aspx

Удачи

2 голосов
/ 04 августа 2010

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

У вас есть два основных варианта.

  • Выберите схему вашей системы и схему базы данных, а затем найдите систему доступа к данным, которая подходит для нее.
  • Или выберите систему доступа к данным и спроектируйте схему базы данных, которая будет хорошо работать с ней.

Например, если вы выберете Nhibernate, вы обнаружите, что эксперты Nhibernate будут использовать данный стиль схемы базы данных (и объектов).Скопируйте их, и у вас будет меньше всего проблем.

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

Помните, что вы всегда можете обойти ORM и использовать рукописный SQL, если обнаружите, что ваш ORM замедляет работу для некоторых обновлений.

...