Рекомендации ORM/Persistence layer

Ответ 1

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

Я серьезно не люблю LINQ query-syntax, чем больше я работаю с ним (хотя я ЛЮБЛЮ языковые функции, связанные с ним, как Extension Methods и Expression Trees).

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

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

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

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

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

Теперь, когда я больше не работаю в компании, которая использует 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 в twitter), который оказался коммиттером в исходном коде проекта NHibernate, у меня действительно были бы серьезные проблемы.

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

Ответ 2

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

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

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

Недостатки:

• Не POCO

Ответ 3

Со всем уважением я категорически не согласен с вашей оценкой слабостей NHibernate.

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

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

Ответ 4

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

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

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

Ответ 5

LLBLGen.

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

Ответ 6

Напишите свой собственный 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
}

Ответ 7

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

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

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

Другие 10% трудности - просто незнание; Я этого не понимал. И это не ошибка NHibernate.

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

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

Ответ 8

Взгляните на EntitySpaces. Я не могу рекомендовать из своего личного опыта, но он отлично работает для одного из моих коллег (кто не в sof...)

Ответ 9

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

Ответ 10

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

Ответ 11

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

В терминах чистого ODB FastObjects от Versant, вероятно, стоит посмотреть.

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