2013-02-14 11 views
6

私はドメイン/ビジネスオブジェクトが問題のドメインに基づいて作成され、物理データモデルまたは永続性構造に関する知識とは独立したドメインモデルアーキテクチャを持っています。今のところ私は軌道に乗っています。なぜなら、それは完全に受け入れられるからです。ドメインモデルとデータモデルの間にインピーダンスの不一致があることがよくあります。 DBAはデータを取得するためにデータベースを作成しました彼らはを必要としましたが、アプリケーション全体をドメインモデルまたはデザインにカプセル化しません。Entity Frameworkで.edmxで自分のドメインモデルオブジェクトを使用する

結果 - 私は自身のドメインモデルオブジェクトのセットを持っています。しかし永続化する必要のあるフィールドはすべてですはドメインモデル内のどこかに存在しますが、必ずしも私の自動生成.edmx POCOエンティティには存在しない形状である必要はありません。だから私はすべてのデータを持っている、それはちょうど完璧なの形状ではなく、自動生成されたPOCOエンティティが作成されているテーブルと同じです。

私は次のような文を作るconverting POCO entity to business entityEntity Framework 4 with Existing Domain Modelのように、このトピックに関するいくつかの記事を見てきました:

「 ドメインクラスと同じ名前を持つエンティティデータモデルのエンティティを作成しますザ・。エンティティプロパティもドメインクラスと同じ の名前とタイプを持つ必要があります。

What!私のドメインモデルを、データベースのデータモデル/テーブル構造の後にモデル化された正確にのPOCOに再形成させる必要があるのはなぜですか?たとえば、5つのプロパティを持つ私の場合、2はクラス 'A'に、3つはクラス 'B'にありますが、自動生成されたPOCOクラスはそれ自身のクラス 'A'に5つあります。

これは全体的な点です。私はオブジェクトモデルとデータモデルを分離したいが、まだEF 5.0のようなORMを使用してそれらの間をマッピングしたい。私は、そのような名前のクラスやプロパティをデータモデルで作成し、作成する必要はありません。

今EF 5.0での私の.edmxは私のためにPOCOクラスを生成しているが、私の質問はこれらを溶解し、にこのすべてのデータが含まれていますが、単に異なる形状の私ドメインオブジェクトをすべてを再配線する方法ですか?

ところで、コードファーストアプローチを使用して提案されたソリューションはオプションではありませんので、にしてください。自分のビジネスオブジェクトを.edmxに配線して、EF5を使用して(可能であれば、EF4の例は常にObjectContextからPOCOを継承しているため)いくつかのガイダンスやチュートリアル(ベスト)が必要です。

ありがとうございました。

答えて

2

これはEntity Frameworkの使用例とまったく同じです。私はここでいくつかの仮定をしています。まず、次のステートメントを作成します。

"ドメイン/ビジネスオブジェクトが問題のドメインに基づいて作成され、物理データモデルまたは永続性構造に関する知識とは独立したドメインモデルアーキテクチャがあります。

このドメインがEFデザイナで作成されたことを意味していますか?しかし、あなたは言う:

"しかし、永続化する必要のあるフィールドはすべて、私のドメインモデル内のどこかに存在するが、必ずしも私の自動生成.edmx POCOエンティティが持っている形ではない。

私の最初の仮定が間違っているように私に聞こえます。

次に、コードを先に閉じますか?ドメインモデル/ビジネスオブジェクトがコードベースであり、それらをリレーショナルデータベースに永続化したい場合は、これがコードの最初の使用例です。コードがあるので、今度はDbContextを作成して物理モデルにマップする必要があります。あなたは、コードベースのビジネス・オブジェクトのドメインモデルを持っていて、他のもののために使用されているEDMXをお持ちの場合は

私はあなたがリポジトリを作成したいと思います:あなたはそれを却下...ので、いくつかの考えをただし

自動マッパーや手動投影などを使用してエンティティを照会し、ビジネスオブジェクトを返すレイヤーです。

コードベースのビジネスオブジェクトのドメインモデルがあり、ビジネスオブジェクトを永続化する以外の目的に使用されていないEDMXを使用している場合は、ドメインをEDMXで表現してマップする必要があると言います既存のデータベースに追加します。これは実際にORMのユースケースです。 2つのドメインモデルと1つのモデルから1つのモデルがあなたのドメインにマッチし、1つがデータベースにマッチするモデルにマッピングすることは、不要な配管の層を追加することです。

上記の後者のアプローチは、EF用語で "モデルファースト"と呼ばれるものです。それらの大部分はモデルからdbを生成するだけですが、いくつかの記事が書かれています。そのステップを実行しないで、エンティティを既存のデータベースにマップします。

基本的な手順は、データベースから更新することで、dbオブジェクト(またはエンティティが作成される)を選択しないことです。または、デザイナー(あなたのようなものです)に存在する.edmxを取り出し、ビジネスドメインに合わせてエンティティを変更することができます。または、EDMXモデル内のすべてのエンティティを削除し、必要に応じてエンティティを作成してからすべてをマップします。

ここでは、モデルストアをインポートするためにEFデザイナを使用して作成したジングがあります(これを実行する唯一の方法は、エンティティを生成できるようにすることです)テーブル情報を削除するかどうかを尋ねるときはNOを押します。

http://screencast.com/t/8eiPg2kcp

私はこれにPOCOジェネレータを追加しませんでしたが、私がやったかどうかはPOCOクラスとしてデザイナーのエンティティが生成されます。

+0

* "このドメインはEFデザイナーで作成されたことを意味しますか?" *、ドメインクラスはデザイナーを使用せずに最初から作成されていません。 * "次に、コードをまず却下する" *、アプリケーションの制約であり、解雇ではありません。あなたの最後の段落は基本的に状況ですが、それは私の元の状況と質問を本当に再説明しています。私はそれを行う方法の具体例を探しています。私の研究から、概念的なレイヤマッピングを手動で変更するか、デザイナーがこのトリックを行うかもしれないが、私は例を探している。 – atconway

+1

基本的に、デザイナを使用してエンティティを作成します。その後、データベースに接続し、エンティティをデータベースに手動でマップします。私は、低摩擦の方法はデザイナーにデータベースをリバースエンジニアリングし、あなたのビジネスドメインに一致するようにエンティティを変更することだと思う...マッピング作業を簡略化します。 – PilotBob

+0

あなたのやりたいことにマッチする "モデルファースト"のアプローチを使って、私の答えは間違っていました。 – PilotBob

0

上記のステートメントは、あなたのポココに一致するようにドメインオブジェクトを書き直すことを示唆していません。ドメインモデルと一致するようにedmxを更新することをお勧めします。

例では、両方のテーブルの5つのプロパティすべてをマッピングするエンティティをedmxに作成することができ、EFは生成された単一のPocoとのマッピングをテーブルに管理します。

もちろんこれは、あなたが、あなたは、手動でEFと対話するときにPOCOSためにあなたのドメインオブジェクトを変換する必要があり

か、インタフェースとして、ドメイン・データ・オブジェクトを定義することができますいずれかを意味し、重複したドメインオブジェクトとPOCOSを有することを意味します本質的に各ポコをドメインオブジェクトの具体的な実装であると識別するポコスの部分的な実装を提供する。

この特定の猫には他にもいくつかの方法がありますが、edmxで使用するための定義済みのC#オブジェクトを提供できるとは思いません。

+0

* ...私はあなたがedmxで使用するための定義済みのC#オブジェクトを提供できるとは思わない*私はこれがPOCOサポートの全ポイントだと思った?私自身の*オブジェクトをEFで使用してください。それにかかわらず、高レベルの説明を裏付けるリンクやサンプルはありますか? – atconway

+0

ok、私のコメントを絞り込むことができます。 http://msdn.microsoft.com/en-gb/data/jj200620 – Bobbles

+0

POCOサポートのようなほとんどの例は、最初のコードであるようです。私はあなたのドメインのジオメトリがデータベースのスキームと一致しなければならないと仮定していると思います。 「コードファースト」は誤称です。彼らはそれを "コードベース"と呼ぶべきだった。 – PilotBob

0

(特定のビジネスロジックに適した)ViewModelを選択してコンテキスト内のデータを自動的にhttps://stackoverflow.com/a/8588843/201648のようにマップする方法があります。これは、AutoMapperを使用してエンティティプロパティをEFコンテキストからViewModelにマッピングします。これはあなたのためにすべてを行うことはありませんが、それは人生を少し楽にするかもしれません。これが自動的に行われる方法に不満がある場合は、AutoMapperを少し異なる方法で設定することができます(投影法を参照) - https://github.com/AutoMapper/AutoMapper/wiki/Projection

これは既にわかっているかもしれませんが、EDMXから自動的にPOCOを生成することも可能ですt4 - http://visualstudiogallery.msdn.microsoft.com/72a60b14-1581-4b9b-89f2-846072eff19d。部分クラスを生成するようにテンプレートを定義すると、そのPOCOのカスタムプロパティで別の部分クラスを作成できます。そうすることで、大部分のプロパティに自動的に入力させることができますが、コンテキスト/リポジトリからカスタムルールを入力する他のカスタムプロパティを持つことができます。これは、これらの生成から単調さを奪うため、上記の手法を使用してデータを再構成することに集中することができます。

あなたが真剣に両者に不満を感じている場合は、ストアドプロシージャをマップして、正確にフィールド名を取得することができます。これはもちろん、どのようにデータを扱うかに影響しますが、私はこれまでに最適化のために/私が欲しかったのと同じ手順が存在していました。 http://msdn.microsoft.com/en-us/data/gg699321.aspx

+0

私はEF5を使用しており、自動POCO生成は機能に組み込まれています。これは、問題である既存のドメインクラスではなく、データベースを直接反映するPOCOクラスです。私は、オブジェクト間のマッピングの使用を避けたいと思っています。これは私のORMが行うことなのです。つまり、* my *ビジネスエンティティをデータベースにマップします。私はそれが概念的な層を修正することを含むと確信していると私のシナリオの例を必要と信じています。 – atconway

関連する問題