ORM / Консистенция уровня персистентности - PullRequest
26 голосов
/ 31 октября 2009

Я начинаю новый проект и ищу либо очень хороший ORM, либо постоянный уровень не на основе SQL.
Для этого проекта меня не волнует, как будут храниться данные, если их можно запрашивать и хранить с разумной скоростью, а главное - с помощью простых запросов.
Параллельность должна обрабатываться без проблем (интерфейс будет на другом уровне, и одновременно будет несколько пользователей, хотя необязательно работать с одними и теми же данными), и тем меньше мне придется сосредоточиться на слое данных (простые запросы, автоматические ленивые). загрузка и т.д.), тем лучше.
Я также хочу во что бы то ни стало избежать необходимости возиться со строковыми запросами, чтобы инструменты, поддерживающие LINQ или другие интуитивно понятные и, возможно, строго типизированные запросы, получали большой бонус.
Наконец-то, я действительно хочу работать с объектами POCO.
Вот список продуктов, которые я оценил, и почему они не подходят, просто чтобы я не видел совета по их использованию:

  • NHibernate: сумасшедшие вещи в формате xml, слишком много настроек, высокая сложность обслуживания и затраты на изменение модели, фабрики сессий грязны и не вписываются в мои потребности
  • Castle ActiveRecord: на основе NHibernate по-прежнему мало документации и некоторые проблемы, связанные с NHibernate. Кроме того, чтобы получить достойные модели, требуется так много атрибутов, что лучше создать схему вручную, а способ обработки отношений - позор.
  • Linq To SQL: отсутствуют объекты POCO и, согласно MS, со временем это не улучшится (EF - это то, к чему они стремятся)
  • Entity Framweork: хотя в v4 объекты POCO возможны, они все же довольно хакерские и вынуждают вас делать слишком много ручной работы, чтобы все настроить. Кроме того, v4 это просто бета
  • LLBLGen Pro: хорошо, особенно с адаптерами самообслуживания, но не с POCO. Кроме того, поставщик LINQ еще не совершенен. Наконец, удаление группы объектов невозможно через LINQ, что приводит к смешиванию API (один из которых далеко не интуитивен), и это мне не нравится.
  • XPO: все, кроме интуитивно понятных, очень медленных проблем параллелизма, а не POCO
  • SubSonic SimpleRepository: несколько минут я думал, что сплю. Беда подошла к концу, когда я понял, как эта штука не справляется с отношениями

Я также смотрел на MongoDB и CouchDB, но в этих случаях уловки со связанными объектами выглядели так, как будто они требовали слишком много тестирования, прежде чем все стало правильно. Кроме того, ни один из них не предлагает строго типизированные запросы.

Заранее спасибо за ваши предложения!

Ответы [ 11 ]

7 голосов
/ 31 октября 2009

Если вы можете позволить себе лицензию LLBLGen, сделайте это.

Мне серьезно не нравится синтаксис запросов LINQ, тем более я работаю с ним (хотя я ЛЮБЛЮ связанные с ним возможности языка, такие как методы расширения и деревья выражений).

Сначала я любил, как и все, но не знал, будет ли [[where employee.Name.StartsWith ("John Smit")]] в этом поставщике XYZ LINQ выполняться в операторе SQL или в LINQ to Objects (после SQL возвращает все результаты), и то, будет ли [[user.Roles.Contains (role)]] вообще работать или нет, является большим шагом позади.

LLBLGen может сделать удаление всех элементов без загрузки их так же просто, как

MyEntityCollection.DeleteAll( new MyEntity {Condition = value} );

Это довольно просто, и мне это нравится. Вы получаете ленивую загрузку, и вы устанавливаете активную / глубокую загрузку по умолчанию и / или для каждого запроса, используя Prefetch API. Вы можете создавать и динамически (и легко) создавать любой фильтр / сортировку / загрузку на бесконечных уровнях. Это очень мило.

Есть только две проблемы, связанные с LLBLGen: во-первых, это цена, которую не все компании хотели бы заплатить, особенно учитывая шумиху над альтернативами Microsoft. Во-вторых, соглашение об именах, хотя и стандартное в теориях СУБД), такое как PredicateFactory вместо «где» или «filter» и Prefetch вместо глубокой загрузки и даже SortExpression вместо orderby, все это немного пугает разработчика, работающего с ним в первую очередь. времена, но вскоре вы научитесь любить их, учитывая силу и легкость, которые они дают. Говорят о поддержке POCO в LLBLGen 3.0. Я не могу сказать об этом, потому что я не знаю.

Теперь, когда я больше не работаю в компании, которая использует LLBLGen, компания использует LINQ to SQL главным образом потому, что она «проверена» во многих проектах без больших сбоев (в отличие от EF 1, в котором отсутствуют даже функции LINQ в LINQ to SQL). и имеет очень плохую производительность и может быть весьма ограничивающим в продвинутом отображении - что должно быть лучше для!) Я использовал оба в этой компании и ненавидел обоих. Решением для новых проектов остается LINQ to SQL, и мы делаем все возможное, чтобы преодолеть его ограничения. Этот веб-сайт StackOVerflow сам работает поверх него !!! Вы можете обойти это, чтобы выполнить SEMI-POCO (вам все еще нужно использовать некоторые связанные с L2S типы, когда дело доходит до ассоциаций).

Я также делаю небольшие проекты дома. Поскольку у меня больше нет лицензии LLBLGen, я решил изучить NHibernate и использовать его вместе с Fluent NHibernate и LINQ To NHibernate. Благодаря этому я узнал, что NHibernate ОЧЕНЬ силен. Это изменило то, как я работаю, благодаря некоторым функциям, таким как автоматическое обновление схемы БД (я почти никогда не трогал D при ее использовании). Иногда не хватает поставщика LINQ (в проекте NHibernate Contrib), но есть неопубликованный исходный код самого NHibernate, в котором содержится лучший поставщик LINQ (еще не пробовал). «Сеанс» в NHibernate имеет проблемы, когда вы занимаетесь веб-разработкой, аналогичной тем, которые связаны с DataContext в L2S или ObjectContext в EF (LLBLGen не страдает от этого благодаря самосопровождаемым сущностям).

Самой большой проблемой, с которой я столкнулся в NHibernate, была способность находить информацию. Слишком много частей, которые должны быть собраны определенным образом, и не так много указаний, может включать в себя расширенную информацию как для отображения, так и для запросов. Если бы у меня не было друга (Tuna Toksoz, @tehlike on twitter), который оказался коммиттером в исходном коде проекта NHibernate, у меня действительно были бы серьезные проблемы.

Мораль, которую я выучил, заключалась в следующем: если вы хотите что-то, что просто работает и немного базовое, используйте Linq To Sql или SubSonic, если вы хотите что-то посередине, и ваша производственная среда может позволить себе BETA .NET-версию (данный golive существует), используйте Entity Framework 4.0, если вы хотите что-то очень мощное и можете позволить себе трудный процесс обучения, переходите на NHibernate, И, ЛУЧШЕЕ ИЗ ВСЕХ, если вы можете позволить себе LLBLGen, ИСПОЛЬЗУЙТЕ ЕГО.

6 голосов
/ 02 ноября 2009

Взгляните на DataObjects.Net :

Преимущества:

  • Простая в разработке бизнес-модель с использованием простых классов и атрибутов
  • Схема базы данных автоматически генерируется во время выполнения, поэтому вам не нужно заботиться о том, как данные сохраняются
  • Автоматическая отложенная загрузка, прозрачное сохранение и т. Д ...
  • Действительно хорошая реализация LINQ
  • Высокая производительность

Недостатки:

  • Не POCO
4 голосов
/ 31 октября 2009

При всем уважении, я склонен абсолютно не соглашаться с вашей оценкой слабостей NHibernate.

Я думаю, что XML-отображения чрезвычайно просты и интуитивно понятны для создания. Добавление ссылки на NHibernate.dll и создание SessionFactory тоже не сложное дело. Обслуживание и управление изменениями значительно упрощены. Фабрики сессий и сессии очень просты для понимания и работы.

В целом, я думаю, что вы эмоциональны и не рациональны с вашей оценкой.

3 голосов
/ 31 октября 2009

Задумывались ли вы об использовании объектно-ориентированной базы данных, такой как db4o . Хотя я никогда не использовал его, я нашел его довольно интересным, когда обнаружил:

Он поддерживает запросы LINQ, использует POCO, и, если я правильно понял, данные просто хранятся в файле (установка базы данных не требуется).

Некоторые ссылки: учебник , сообщение на форуме

2 голосов
/ 01 декабря 2009

Я использовал LLBLGenPro, NHibernate и несколько объектных баз данных.

Моя первая рекомендация была бы для NHibernate с FluentNhibernate для обработки сопоставлений.

Я обнаружил, что 90% трудностей, связанных с использованием NHibernate, напрямую связаны с отображениями XML. Когда я переключил FluentNhibernate, боль ушла.

Остальные 10% сложности - это просто невежество; Я не поняла это. И это не вина NHibernate.

LLBLGenPro: Я понятия не имею, на что похожа поддержка Linq сейчас, но до поддержки Linq это была PITA для написания запросов. Я прочитал документы и получил их, но мои коллеги этого не сделали и постоянно жаловались на сложности путей предварительной выборки и тому подобное. Плюс, как вы сказали - не POCO. Добавьте к стоимости, и я бы сказал, что это намного больше проблем, чем стоит.

Если это не клиент-серверная архитектура, я бы предложил db40. Я использовал его на небольшом частном проекте, и мне понравилось. Легко использовать. Отличная маленькая объектная база данных.

2 голосов
/ 02 ноября 2009

Напишите свой собственный ORM

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

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

[TableMapping("Users", "User", "Users")]
public class User : EntityBase
{
    #region Constructor(s)
    public User()
    {
    }
    #endregion

    #region Properties

    #region Default Properties - Direct Field Mapping using DataFieldMappingAttribute

    private System.Int32 _UserId;

    private System.String _UserName;

    [DataFieldMapping("UserID")]
    [DataObjectFieldAttribute(true, true, false)]
    [NotNullOrEmpty(Message = "UserID Is Required.")]
    public override int Id
    {
        get
        {
            return _UserId;
        }
        set
        {
            _UserId = value;
        }
    }

    [DataFieldMapping("UserName")]
    [NotNullOrEmpty(Message = "Username Is Required.")]
    public string UserName
    {
        get
        {
            return _UserName;
        }
        set
        {
            _UserName = value;
        }
    }

    #endregion

    #region One-To-Many Mappings
    #endregion

    #region Derived Properties
    #endregion

    #endregion
}
2 голосов
/ 31 октября 2009

LLBLGen.

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

1 голос
/ 26 ноября 2009

Вы можете взглянуть на Telerik ORM . Я не использовал его в работе, но он был основан на Java ORM \ ODB под названием POET, который работал очень хорошо для меня несколько лет назад. Поскольку он использует улучшение сборки, он предлагает гораздо более прозрачный интерфейс, чем некоторые продукты, которые вы отклонили выше.

С точки зрения чистого ODB FastObjects от Versant , вероятно, стоит посмотреть.

Удачи - дайте нам знать, что вы решили пойти.

1 голос
/ 01 ноября 2009

Для меня ответом оказался LLBLGen Pro. В дополнение к его возможностям вы получаете специальную группу поддержки, которая заботится о том, чтобы помочь вам запустить ваш проект, и если вы обнаружите ошибку, в большинстве случаев вы получите исправление в течение нескольких часов или дней. Этого нельзя минимизировать, так как он позволяет вам продолжать работу, а не ждать релиза (месяцы?) Или исправлять ошибку самостоятельно.

1 голос
/ 31 октября 2009

Взгляните на Aspectize здесь

...