問題タブ [entity-framework-designer]

Entity Framework を使用する場合、モデルを作成するには基本的に 2 つの方法があります。SQL サーバーまたは Visual Studio EF デザイナーでモデルを作成します。それらの概要を以下に示します。

データベースから始める

最初に SQL サーバー DB にモデルを作成し、次に EF を指定して .edmx ファイルを作成します。このアプローチを使用すると、SQL サーバー管理スタジオを使用して、すべてのモデルと関係を作成できます。

Visual Studio EF デザイナーから始める

このアプローチでは、最初に Visual Studio でモデルを作成し、そこからデータベースを作成します。こうすることで、テーブルやリレーションシップをあまり気にする必要がないように思えます。

ここに私がしていることと、そのようにする理由があります

まず、SQL サーバー管理スタジオを使用してモデルを作成します。そのツールを使用してテーブルを作成および変更する方が簡単だと思うので、これを行います。また、何が作成されているかを正確に知っています。既存のデータベースを指すように EF モデルを作成します。その後、Visual Studio データベース プロジェクトを作成して、データベースがファイルにスクリプト化され、バージョン管理されます。変更が必要な場合は、データベースを変更してから、.edmx ファイルとデータベース プロジェクトを更新します。

これらの異なるアプローチの長所と短所は何ですか?また、どちらを使用するかを決定する基準は何ですか? 私はそれを間違っていますか？最初に Visual Studio でモデルを作成する必要がありますか?

オブジェクトをリレーショナル db 構造で表現する方法を誤解しています。

たとえば、次のような単純なテーブル構造があるとします。

それに基づいて Entity Framework モデルを生成すると、次のようになります。

ご覧のとおり、これは多対多の関連付けです。(どの料理にも多くの食材が含まれており、どの食材も多くの料理に使用できます)

では、ディッシュの材料の量など、追加のパラメーターが必要な場合はどうすればよいでしょうか? （もちろん、通常は、異なる料理の各材料ごとに異なる番号になります）.

追加の列をDish_FooIngridientテーブルに直接追加すると、自動モデル生成の機能が損なわれ、EF モデル デザイナーで関連付けを手動で修正し、後でいくつかの面倒なクエリを使用してオブジェクトを操作する必要があります。次のようなものに生成されるためです。

ご覧のとおり、必要のない冗長なプロパティが他にもあります。それを管理するためのより良い方法はありますか？複雑なプロパティや継承されたエンティティなどを使用している可能性がありますか?

EFでは、関数インポートを追加するときに、名前とSProcを指定するように求められます。次に、返品を決定できます（None、Scalers、Complex、およびEntitiesの場合があります）。

Complexを選択してから更新ボタンを押すとどうなりますか？ボタンを押したときにdbを台無しにしたと思いUpdateます。私は元に戻し、それからそれを押さなかった、そしてそれはうまくいく。

では、Updateは何をしますか？

デザイナーから EDMX モデルを更新して大規模なデータベースにテーブルを追加すると、出力ウィンドウに次のエラーが返されます。

次の例外のため、モデルを生成できません: コマンド定義の実行中にエラーが発生しました。詳細については、内部例外を参照してください。

着信表形式データ ストリーム (TDS) リモート プロシージャ コール (RPC) プロトコル ストリームが正しくありません。この RPC 要求で指定されたパラメーターが多すぎます。最大は 2100 です。データベースからのメタデータの読み込みに 00:00:04.5149496 かかりました。モデルの生成には 00:00:14.0108568 かかりました。次の例外のため、モデルを生成できません: コマンド定義の実行中にエラーが発生しました。詳細については、内部例外を参照してください。

着信表形式データ ストリーム (TDS) リモート プロシージャ コール (RPC) プロトコル ストリームが正しくありません。この RPC 要求で指定されたパラメーターが多すぎます。最大は 2100 です。データベースからのメタデータの読み込みに 00:00:04.2847682 かかりました。モデルの生成には 00:00:06.1297751 かかりました。

この問題をどのように回避/解決できますか?

エンティティ Entity Framework デザイナーの [プロパティ] ウィンドウにカスタム プロパティを追加する方法はありますか? T4 ファイルを拡張していくつかのリポジトリを自動生成しましたが、エンティティが集約ルートである場合にのみ実行したいと考えています。エンティティに True/False の "Is Aggregate Root" プロパティを追加したいと思っています....

Entity Framework Designer拡張機能を作成しようとしていますが、実際のEntityFramework4の例に従っています。この本は、これに非常によく似た例を提供します。ステップ6の「メモ」に注意してください。ここでは、ビルドアクションをVsixContentに設定するように指示しています。オプションとしてVsixContentはありません。なぜこれが起こるのかについて誰かが考えていますか？

ありがとう

編集：vsixファイルが生成されていないことに注意してください。 編集：VS2010 SP1 SDKを再インストールし、再起動しました。オプションが表示されます。ただし、vsixファイルはまだ生成されていません。

プロパティ ウィンドウに新しいプロパティを追加する EF デザイナー用の小さな拡張機能を作成しました。vsix プロジェクト (新しいプロジェクト -> c# -> 拡張性 -> vsix プロジェクト) を使用してこれを行いました。F5 キーを押すと、実験的な VS インスタンスが起動します。新しいプロジェクトを作成し、エンティティ データ モデルを追加して、エンティティを追加します。しかし、私のブレークポイントはヒットせず、プロパティが表示されません。私が間違っているかもしれないことについてのアイデアはありますか?

編集: コードを Github に置きました: https://github.com/devlife/Sandbox

編集: 提案されたように MEF コンポーネントをマニフェストに追加した後、拡張機能はまだ読み込まれません。マニフェストの写真は次のとおりです。

コード生成項目の追加オプションのために EF デザイナーが使用できる項目テンプレートを作成する方法を誰か教えてもらえますか? アイテム テンプレートを作成しましたが、夢のように機能します。ただし、コード生成項目の追加ダイアログに表示する方法がわかりません。FWIW VSIX プロジェクトを使用してアイテム テンプレートを展開しています。

So I can't figure out how to properly construct my EF query to get the rows I want. I'm only working with two tables here.

The Entity Framework designer creates this edmx diagram for my db structure. The loop at the top represents the association table that I'm having trouble filtering.

The SQL 2005 db diagram looks like this. The GeoBoundaryAssociation table has a many-to-many relationship from both of it's only two columns back to the GeoBoundary table's primary key GeoID.

I can write the SQL query to get the rows I want rather easily. I only need to pass one variable to get my results.

When I try to write my EF query I can't seem to filter rows from either of the two columns in the Association table. Any help would be greatly appreciated.

As a short term fix I have added an ID column to the GeoBoundaryAssociation table in order to get EF to generate an Entity so I can filter it directly. But I'm sure there must be a better way to do this.