2

私たちは、MSSQLデータベースから「データベースファースト」アプローチで生成された複数のプロジェクト/アセンブリにわたっていくつかの関連するドメインモデルを生成できるようにするORM/ドメインモデリングツールを求めています。どのツールが私たちのニーズを満たすかを理解するために、いくつかの助けが必要です。

要件は次のとおりです。

  1. プロジェクト間の関係

    • 私たちのドメインは多数のモジュールに分割されており、クライアント（ソースコードを提供するクライアント）ごとにすべてのモジュールを使用するわけではないため、クライアントが表示したりアクセスしたりする必要のないすべてのロジックを「プラグを抜く」必要があります。 。
    • たとえば、共有データ（主に一般的なルックアップ情報）を独自の共通アセンブリに格納する必要があります。
    • モデル間に双方向の関係は必要ありません（循環参照が発生するため）。子の関係の終わりのみが生成されます。

  2. プロジェクト間の継承

    • 上記と同様に、共通の機能を1つのドメインモデルの基本クラスに抽象化し、それらを継承できるようにする必要があります。
    • 注：ドメイン間の継承リンクは制限され、サブドメインごとに1つまたは2つだけになります。
    • 注：問題ではありませんが、「タイプごとのテーブル」または「クラステーブル継承」を使用して、リレーショナル（DB）スキーマで継承をモデル化しています。

  3. 生成されるクラスは次のとおりです。

    1. DataContract/DataMember属性でマークされています
    2. プロパティの変更を通知する（INotifyPropertyChanged実装を介して）
    3. 部分的なOn*PropertyName * Changed（）メソッドがあります（たとえば、Linq toSQLおよびEntityFrameworkで生成されたオブジェクトに従って）
    4. （理想的ですが、必須ではありません）関連するコレクションタイプは、INotifyCollectionChangedを実装する必要があります。

これらの基準をサポートする（またはサポートするための回避策がある）ORMツールに関するフィードバックをいただければ幸いです。

注：これまで見てきたツール（ただし、これで完全に除外されるわけではありません）：

  • LightSpeed（素敵ですが、プロジェクト間の継承を簡単にサポートしていません）。
  • LLBLGen（複雑ですべてを網羅していますが、AsSeparateProjectsモードを使用してグループ化すると、継承はもちろん、モデル間の関係もサポートされていないようです）。
  • Entity Framework（私は迷子になりました...ドメインを複数のモデルに分割したときのデザイナーの話はあまり良くありませんでした）。
4

2 に答える 2

1

それはあなたが求めているものの逆のように聞こえるかもしれませんが、私はおそらくEFコードファーストを見るでしょう。すべてPOCO、DbSet、およびDbContextクラスの上に構築されているため、継承を非常に簡単に機能させることができます。

共有モデルと抽象DbContextを共通のアセンブリに入れます。顧客固有のアセンブリに特定のモデルと最終的なDbContextを用意します。

WinFormsの前面には、セットを監視可能にする方法のサンプルコードがあります。INotifyPropertyChangedを自分で処理する必要がありますが、それは非常に簡単です。

EF Code Firstの欠点は、すべてのクラスを生成する方法がないことです。そうは言っても、それらは書くのに十分単純なので、アプリの残りの部分をコーディングしている間、私はおそらく必要に応じてそれらを書くでしょう。あらゆる形式の汎用の自動化ツールでは、どのモデルとプロパティが共通に属するのか、顧客固有に属するのかを判断するのに問題があります。

于 2011-03-08T19:58:47.913 に答える
1

要件はEFに関する論文で一般的に説明されているものではないため、これには確かに小さな概念実証プロジェクトが必要です。

1.と2については、これらの記事（パート1、パート2）に目を通し、複数のEDMX間で関係と継承の両方を使用できることを証明する簡単なソリューションを作成してみてください。

最後のポイントは、EDMXからクラスを生成するためのカスタムT4テンプレートによって満たされます-POCOテンプレートから始めて、その生成機能を変更します。

于 2011-03-08T07:48:16.880 に答える