Есть какие-нибудь мысли о DevExpress XPO ORM Package?

Плюсы и минусы по сравнению с чем? Есть много альтернатив, самая популярная из которых - nHibernate, с новой детской платформой ADO.NET Entity Framework.

В любом случае, есть сотни ответов в зависимости от вашей ситуации и требований.

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

«Зачем менять»?

Я успешно использовал XPO в течение многих лет в устоявшемся коммерческом продукте с несколькими сотнями пользователей. Я считаю, что он быстрый, гибкий и выполняет свою работу. В настоящий момент я не вижу необходимости в изменениях, поскольку объемы наших данных не особенно велики, а недостатки (в основном кеширование) - это то, что мы можем решить.

Если бы я начинал заново, я бы определенно посмотрел и на NHibernate, и на ADO.NET Entity Framework. Однако на практике все хорошо; Скорее всего, я бы посмотрел на коммерческую ситуацию по проекту, прежде чем решать технические вопросы.

Например, NHibernate имеет открытый исходный код - есть ли там жизнеспособное сообщество, которое поддержит инструмент и предоставит (при необходимости) коммерческую поддержку?

XPO поступает от поставщика инструментов, вероятно ли, что они останутся в бизнесе на протяжении всего срока службы продукта?

ADO.NET Entity Framework исходит от Microsoft, которая печально известна тем, что меняет технологии баз данных чаще, чем Ларри заправляет свой истребитель реактивным топливом - это тоже исчезнет?

Мне нравится тот факт, что вы можете просто создавать классы, а xpo создает для вас таблицы и отношения - так что вы можете начать с пустой базы данных.

Одна проблема, которая мне не нравится, - это когда я хочу удалить целую кучу вещей, она проходит через мою коллекцию и удаляет каждую из них. На это уходит много времени, поэтому для этого типа экземпляра мне пришлось написать некоторый собственный sql (удалить из таблицы, где бла). Я не специалист по XPO, но вот что я нашел.

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

Кроме того, он действительно прост в использовании и быстро работает.

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

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

При моделировании более сложных объектов вы должны использовать много синтаксиса, которому действительно нет места в вашей объектной модели, например XPCollection. Я хотел сохранить класс, в котором был словарь строк, но, к сожалению, XPO не смог автоматически сохранить его в базе данных.

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

С XPO в целом легко работать. Однако это может быть немного больно, когда вы планируете работать с устаревшей базой данных или пытаетесь внедрить ее в приложение для старых объектов. Самыми болезненными препятствиями, с которыми я столкнулся, были:

• все объекты должны наследоваться от классов, связанных с XPO, и / или использовать атрибуты, связанные с XPO. Итак, никаких объектов POCO
• нет поддержки постоянных полей только для чтения OOTB. Это возможно, но вам нужно немного взломать, чтобы XPO не обновлял поле в БД.
• нет поддержки ассоциаций предварительной фильтрации, что может вызвать чрезмерную нагрузку на сеть
• Плохая поддержка внешних составных ключей. Честно говоря, ни один ORM не обрабатывает составные ключи должным образом. Они считаются паттерном «анти-ORM».
• несколько мелких неприятностей

Как отметил Деннис в комментариях, XPO был значительно улучшен с тех пор, как я изначально написал этот ответ. В частности, следующие вещи больше не являются проблемой:

• нет сериализации, поэтому объекты XPO трудно использовать в сценарии с отказавшимися формами выигрыша, когда данные поступают через веб-службы. - XPO теперь поддерживает различные сценарии сериализации и может легко использоваться с WCF.
• вы не можете выполнить отображение отношения «многие ко многим» с вашей собственной промежуточной таблицей. Xpo хочет конкретное имя для таких промежуточных таблиц. - Это уже не тот случай
• нет поддержки перечислений в провайдере postgreSql - вам просто нужно написать действительно простой преобразователь значений, и у вас все хорошо.

Кроме того, следующие проблемы больше не будут проблемой со следующим выпуском XPO, который выйдет позже в этом году:

• нет поддержки ключей типа long
• нет поддержки схемы db в провайдере postrgeSql

В целом XPO был значительно улучшен. Устранены самые болезненные препятствия. Вы все еще можете столкнуться с проблемами при работе с устаревшей БД. Но в целом XPO пользоваться стало достаточно удобно.

Я работаю с ним в течение 6-7 месяцев, и продавец для меня был тот факт, что все их компоненты пользовательского интерфейса относительно без проблем работают с XPO, а их компоненты пользовательского интерфейса на высшем уровне.

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

Это все, что вам нужно сделать, чтобы начать писать объекты домена (попробуйте сделать то же самое в других системах):

using System;
using DevExpress.Xpo;
using DevExpress.Data.Filtering;
using NUnit.Framework;

namespace XpoTdd {
    public class Person:XPObject {
        public Person(Session session) : base(session) { }
        public string FirstName { get; set; }
        public string LastName { get; set; }
        [Persistent]
        public string FullName { get { return FirstName + " " + LastName; } }
    }
    [TestFixture]
    public class PersonTests {
        [Test]
        public void TestPersistence() {
            const string connStr = "Integrated Security=SSPI;Pooling=false;Data Source=(local);Initial Catalog=XpoTddTest";
            UnitOfWork session1 = new UnitOfWork();
            session1.ConnectionString = connStr;
            Person me = new Person(session1);
            me.FirstName = "Roman";
            me.LastName = "Eremin";
            session1.CommitChanges();
            UnitOfWork session2 = new UnitOfWork();
            session2.ConnectionString = connStr;
            me = session2.FindObject<Person>(CriteriaOperator.Parse("FullName = 'Roman Eremin'"));
            Assert.AreEqual("Roman Eremin", me.FullName);
        }
    }
}

XPO версии 10.2 теперь поддерживает как StoredProcedures, так и SqlQueries. См. Информацию здесь ...