Совет уровня ORM/Persistence

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

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

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

Недостатки:

• Не POCO

With all respect, I tend to absolutely disagree with your assessment of NHibernate weaknesses.

I think XML mappings are extremely simple and intuitive to create. Добавление ссылки на NHibernate.dll и создание SessionFactory тоже несложно. Значительно упрощено сопровождение и управление изменениями. Сессионные фабрики и сеансы очень просты для понимания и работы.

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

Если вы можете позволить себе лицензию 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 вместо «where» или «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 - это способность находить информацию. Слишком много частей, которые нужно соединить определенным образом, и не так много рекомендаций могут включать расширенную информацию как для сопоставления, так и для запросов. Если бы не у меня был друг (Тунец Токсоз,

LLBLGen.

If you think your going to find something that ticks all your boxes then you could be waiting for a long time.

Take a look at EntitySpaces. I can't recommend from my own personal experience, but it works great for one of my colleagues (who is not into sof...)

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

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

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

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

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

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

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

С точки зрения чистого ODB FastObjects от Versant , вероятно, заслуживает внимания.

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

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

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

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

Остальные 10% трудности - просто незнание; Я этого не понимал. И это не вина NHibernate.

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

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