7

ドメイン/ビジネス オブジェクトが問題ドメインに基づいて作成され、物理データ モデルまたは永続構造に関する知識とは無関係に作成されたドメイン モデル アーキテクチャがあります。ドメイン モデルとデータ モデルの間にインピーダンスの不一致があることがよくあります。DBA は、必要なデータを取得するためにデータベースを作成しましたが、アプリケーション全体のドメイン モデルまたは設計をカプセル化するわけではありません。

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

POCO エンティティをビジネス エンティティに変換したり、Entity Framework 4 を既存のドメイン モデルを使用して次のようなステートメントを作成したりするなど、このトピックに関するいくつかの投稿を見てきました。

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

何！？まさか、データベース内のデータ モデル/テーブル構造を正確にモデル化した POCO にドメイン モデルを再形成する必要があるのはなぜですか? たとえば、5 つの特定のプロパティがある場合、2 つがクラス「A」にあり、3 つがクラス「B」にある可能性がありますが、自動生成された POCO クラスには、独自のクラス「A」に 5 つすべてがあります。

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

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

ちなみに、Code First アプローチを使用して提案されたソリューションはオプションではないため、これを提供しないでください。独自のビジネス オブジェクトを .edmx に接続して EF5 を使用する (可能であれば、EF4 の例は常に ObjectContext から POCO を継承するため) ガイダンスまたはチュートリアル (最適) が必要です。

ヘルプやガイダンスをいただければ幸いです。

4

3 に答える 3

1

This sounds like exactly the use case of Entity Framework. I am making a few assumptions here. First that when you make this statement:

"I have a domain model architecture in which my domain/business objects were created based on the problem domain and independent of any knowledge of the physical data model or persistence structures."

That you mean this domain was created in the EF designer? But then you say:

"However all of the fields that need to be persisted do exist somewhere or another within my domain model, but not necessarily in the shape that my auto generated .edmx POCO entities have them."

This sounds to me like my first assumption is incorrect.

Next, you dismiss code first? If your domain model/business objects are code based and you want to persist them to a relational database, that is exactly the use case for code first. You have the code, now you need to create your DbContext and map it to your physical model.

However you dismiss that... so some thoughts:

If you have a domain model of code based business objects and you have an EDMX that is used for other things I think you would want to create a repository layer that uses something like auto mapper or manual projections to query your Entities and return your business objects.

If you have a domain model of code based business objects and you have an EDMX that is not used for other things other than persisting your business objects I would say that you need to express your domain in an EDMX and then map it onto your existing database. This is really the use case for an ORM. Having two domain models and mapping from one model to the other where one model matches your domain and one matches your database is adding an extra un-needed layer of plumbing.

The latter approach above is what is called "Model First" in EF parlance. There are several articles written about it although the bulk of them just generate the db from the model. You would not do that step, rather you would map your entities onto your existing database.

The basic steps for this are to "update from the database" not selecting any of the db objects (or entities would be created). Or, you can take your exiting .edmx in the designer (which is sounds like you have) and modify the entities to match your business domain. Or just delete all the entities in your EDMX model, create your entities as you want them, and then map them all.

Here is a jing I made where I use the EF Designer to bring in the model store (the only way to do this is to allow it to generate entities) and then delete the entities allowing the Store information to stay by clicking NO when it asks if you want to delete the table info.

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

I didn't add the POCO generator to this, but if I did it would generate the Entities in the designer as POCO classes.

于 2013-02-15T19:11:00.417 に答える
0

1つのアプローチは、ViewModel（特定のビジネスロジックに適している）を選択し、 https：//stackoverflow.com/a/8588843/201648のように、コンテキストからのデータを自動的にマップすることです。これはAutoMapper、エンティティプロパティをEFコンテキストからViewModelにマップするために使用します。これはあなたのためにすべてを行うわけではありませんが、それは人生を少し楽にするかもしれません。これが自動的に発生する方法に不満がある場合は、AutoMapperを少し異なる方法で実行するように構成できます（プロジェクションを参照）-https ://github.com/AutoMapper/AutoMapper/wiki/Projection

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

両方に深刻な不満がある場合は、ストアドプロシージャをいつでもマップして、必要なフィールド名を自動的に取得できます。これはもちろんデータの操作方法に影響しますが、私は以前に最適化の目的でそれを行いました/私が望んでいたことを正確に実行する手順がすでに存在していました。http://msdn.microsoft.com/en-us/data/gg699321.aspxを参照してください

于 2013-02-15T13:55:05.977 に答える
0

上記のステートメントは、ドメイン オブジェクトを poco に一致するように書き直すことを示唆しているのではなく、ドメイン モデルに一致するように edmx を更新することを示唆しています。

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

もちろん、これはドメイン オブジェクトと poco が重複していることを意味します。つまり、EF とやり取りするときに、ドメイン オブジェクトを poco に手動で変換する必要があります。

または、ドメイン データ オブジェクトをインターフェイスとして定義し、各 poco をドメイン オブジェクトの具体的な実装として基本的に識別する poco の部分的な実装を提供することもできます。

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

于 2013-02-14T21:47:44.313 に答える