c# - DevExpress XPO ORM パッケージについて何か考えはありますか?

Question

XPOは、私の会社で選択したオブジェクトリレーショナルマッパーです。長所と短所について何か考えはありますか？

製品に関する一般的な感想や逸話を探していました。XPO に切り替えるつもりはありません。アプリ内に存在するハードコーディングされた SQL 文字列を取り除き、すべてのデータアクセスを完全に ORM に移行しています。

score 16 · Accepted Answer

他の人はおそらく技術的な回答 (クエリ構文、キャッシングの使用、既存のデータベース構造へのマッピングの容易さなど) を提供するでしょうが、確立された ORM レイヤーがある場合、回答はおそらく

「なぜ変える」？

私は、数百人のユーザーを持つ確立された商用製品で XPO を何年もうまく使用してきました。高速で柔軟性があり、仕事をしていると思います。私たちのデータボリュームは特に大きくなく、欠点 (主にキャッシング) は回避できるものであるため、現時点では変更する必要はないと考えています。

もし私が新たに始めるなら、間違いなく NHibernate と ADO.NET Entity Framework の両方を検討するでしょう。ただし、実際には、すべてが適切です。技術的な質問の前に、プロジェクトの商業状況を確認する可能性が最も高いでしょう。

たとえば、NHibernate はオープンソースです。ツールをサポートし、(必要に応じて) 商用サポートを提供する実行可能なコミュニティはありますか?

XPO はツールベンダーから提供されたものですが、製品の存続期間中、ビジネスを継続する可能性はありますか?

ADO.NET Entity Framework は、ラリーが戦闘機にジェット燃料を充填するよりも頻繁にデータベーステクノロジを変更することで悪名高い Microsoft から提供されています。

score 11 · Accepted Answer

XPO を使用するのは非常にイライラします。ORM の主なアイデアは、基礎となるデータ構造を抽象化することです。しかしすぐに、デフォルトの文字列の長さが 60 文字にハードコードされていることに気付くでしょう。そのため、すべての文字列の周りにこれらの醜い string.unlimited を追加することになります。抽象化はここまで...

より複雑なオブジェクトをモデル化する場合、XPCollection のように、実際にはオブジェクトモデルにはない多くの構文を使用する必要があります。クラスに文字列の辞書を持つクラスを保存したかったのですが、残念ながら XPO はこれをデータベースに自動的に保存できませんでした。

そのため、単純な型では問題なく機能しますが、より複雑なものを保存する場合はすぐに機能しなくなります。それは彼らの平凡なサポートと相まって、本当に多くのことが望まれています.

score 5 · Accepted Answer

私はそれを 6 ～ 7 か月間使用してきましたが、私にとって売り手は、すべての UI コンポーネントが XPO と比較的シームレスに動作し、UI コンポーネントが一流であるという事実でした。

フォーラムの監視が不十分で、有用なトラフィックがほとんどないことに気付く人もいるかもしれませんが、これは事実です。ただし、秘密はチケットに記入することです。すべてのサポートチケットに迅速かつ正確に対応します。

score 4 · Accepted Answer

全体として、XPOは操作が簡単です。ただし、レガシーデータベースを使用する場合や、ブラウンフィールドアプリに導入する場合は、少し面倒なことがあります。私がぶつかった最も苦痛な障害は次のとおりでした：

すべてのオブジェクトは、XPO関連のクラスから継承するか、XPO関連の属性を使用する必要があります。したがって、POCOオブジェクトはありません
読み取り専用の永続フィールドOOTBはサポートされていません。可能ですが、XPOがDBのフィールドを更新しないようにするには、少しハッキングする必要があります。
過度のネットワーク負荷を引き起こす可能性のある事前フィルタリングアソシエーションはサポートされていません
外部複合キーのサポートが不十分です。公平を期すために、複合キーを適切に処理するORMはありません。それらは「反ORM」パターンと見なされます。
いくつかの小さな迷惑

デニスがコメントで指摘したように、私が最初にこの回答を書いたので、XPOは大幅に改善されました。特に、以下のものはもはや問題ではありません。

シリアル化が行われないため、XPOオブジェクトは、データがWebサービスを介して送信される、接続されていないWinフォームシナリオで使用するのは困難です。-XPOは現在、さまざまなシリアル化シナリオをサポートしており、WCFで簡単に使用できます。
独自の暫定テーブルを使用して多対多の関係マッピングを行うことはできません。Xpoは、そのような暫定テーブルに特定の名前を付けたいと考えています。-これはもはや当てはまりません
postgreSqlプロバイダーでは列挙型はサポートされていません-本当に単純な値コンバーターを作成するだけで、問題ありません。

また、以下の問題は、今年後半にリリースされる次のXPOリリースでは問題になりません。

longタイプのキーはサポートされていません
postrgeSqlプロバイダーでのdbスキーマのサポートなし

全体として、XPOは大幅に改善されました。ほとんどの痛みを伴う障害物が取り除かれました。従来のDBで作業しているときにも、問題が発生する可能性があります。しかし、一般的に、XPOは非常に使いやすくなりました。

score 2 · Accepted Answer

XPO バージョン 10.2 は、StoredProcedures と SqlQueries の両方をサポートするようになりました。ここで情報を参照してください...

score 0 · Accepted Answer

何と比べたメリット・デメリットは？そこには多くの代替手段がありますが、最も人気のあるのは nHibernate で、ブロック上に新しいキッド 'ADO.NET Entity Framework' があります。

とにかく、状況や要件に応じて、何百もの答えがあります。

score 0 · Accepted Answer

クラスを作成するだけで、xpo がテーブルとリレーションシップを作成するので、空のデータベースから始めることができるという事実が気に入っています。

私が気に入らない問題の 1 つは、大量のものを削除したい場合です。それは私のコレクションを通過し、それぞれに対して削除を行います。これには時間がかかるため、この種のインスタンスでは、カスタム SQL を作成する必要がありました (テーブルから削除してください)。私は XPO の専門家ではありませんが、私が見つけたものです。

score 0 · Accepted Answer

これは、ドメインオブジェクトの作成を開始するために必要なすべてのことです (他のシステムでも同じことを試してください)。

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);
        }
    }
}

score 0 · Accepted Answer

いくつかのコレクションを持つ複雑なオブジェクトを削除するには、非常に長い時間がかかるという事実を認めます。これまでのところ、ドキュメントやフォーラムはこれについて私を助けることができませんでした.

それとは別に、使い方は本当に簡単で、すぐに使い始めることができます。

また、メモリ使用量を把握するのも非常に困難です。設計に複雑な大きなオブジェクトがあり、それらを操作することは、想定していたよりも大きなメモリを消費しました。

c# - DevExpress XPO ORM パッケージについて何か考えはありますか?

9 に答える 9

Related

Reference