問題タブ [navigational-properties]

次のIQueryable<T>リポジトリがある場合:

そして、私はそれを次のように使用して特定の注文を取得します:

すべて良好。

今、私はEDMX に追加した OrderDetailsViewと呼ばれる SQL Server 2008 ビューを持っています。参加したいOrderIdというフィールドがあります。OrderとOrderDetailsViewの間は1 対 1です。

特定の Order と、対応する OrderDetailsView レコードを返したい。

ここでの正しいアプローチが何であるかはわかりません。

• Order エンティティのビューにナビゲーション プロパティを設定できますか? アソシエーションを追加できますが、デザイナーはそれがマッピングされていないと不平を言っています.FKが必要だと思いますが、明らかにViewにはFKを含めることはできません。

• 明示的な結合を行う必要がありますか? もしそうなら、それはそれらが関連付けのない独立したエンティティであることを意味するので、別のリポジトリが必要になります.2つのリポジトリ間でJOINを実行できないため、2つのデータベース呼び出しが必要です.

理想的には、私はこれをしたいと思います:

しかし、前述のように、View を指すナビゲーション プロパティを追加できるかどうかはわかりません。

何か案は？

私は次のようなEFモデルの一部です。

概要：

• 場所には多くの投稿があります
• Postは抽象クラスです
• ディスカッションは投稿から派生します
• ディスカッションには多くのコメントがあります

今、私が達成しようとしているクエリ：

それらのディスカッションに関連するディスカッションやコメントなど、ロケーションID1234に関する情報を取得します。

私はこのような議論とコメントを得ることができます：

しかし、 LocationエンティティのPostsナビゲーションに基づいて取得できないようです。

私はこれを試しました：

どちらがコンパイルされますが、エラーが発生します：

System.ArgumentException：インクルードパス式は、エンティティによって定義されたプロパティを参照する必要があります。オプションで、ネストされたプロパティまたはSelectの呼び出しも参照する必要があります。パラメータ名：パス

何か案は？私はおそらく投稿から「後方」に行くことができます：

しかし、それは私のリポジトリの観点からは厄介で意味的に間違っています（場所に関する情報を取得するために投稿リポジトリを通過する必要はありません）。

何か案は？

編集

それで、それについてもっとよく考えた後、私はそれOfType<T>がフィルター操作であることに気づきました。ご存知のように、EFは積極的な読み込みによるフィルタリングをサポートしていません。唯一のオプションは、すべてを取得するか、匿名タイプの射影を使用することです。

メタデータが多すぎるため、すべてを取得することはできません。だから私は匿名型の投影を試みています。

POCOでLinq-to-Entitiesを使用して、DBの最初のアプローチでEF4モデルを実行することで壁にぶつかりました...

とを介して関連付けられている 2 つのテーブルがCustomerあります。列は次のとおりです。NamePrefixNamePrefixId

この例では、Customerエンティティにはナビゲーション プロパティがありますNamePrefix。NameOfPerson他のエンティティで使用できるように、複合型を作成しました。複合型は、、、、で構成NamePrefixIdさLastNameれFirstNameますMiddleInitial。しかし、現在、ナビゲーション プロパティで次のエラー メッセージが表示されますNamePrefix。

これを達成する方法はありますか？

私はEntity Framework、WebForms、.Net Framework 3.5を使用しています.Entityのナビゲーションプロパティになっている外部キーの更新も含むエンティティモデルを使用して、データベースのレコードを更新したいと考えています.

どうやってやるの？次のような別のクエリを含む方法を見てきました

DB に行かずにそれを行うにはどうすればよいですか?

これが私のシナリオです（テーブル）：

これら 3 つのテーブルを EDMX モデルにインポートすると、Employee と Department の 2 つのエンティティが得られます。Entity Employee にはナビゲーション プロパティ Departments があり、エンティティ Department にはナビゲーション プロパティ Employees があります。

そして、これはすべて問題ありません。実はこういうの好きです。

しかし、XREF テーブルにさらにフィールドを追加したい場合に問題が発生します。たとえば、DateCreated、UserId フィールドを使用して、変更がいつ誰によって行われたかを記録したいと考えています。これら 2 つのフィールドを XREF テーブルに追加すると、EDMX モデルには 2 つではなく 3 つのエンティティが表示されます。大きな問題ではありませんが、コーディングはすでに完了しているので、(コーディングを避けるための) 簡単な解決策を探しています。

質問:新しいフィールドを XREF (相互参照) テーブルに追加して、エンティティを 2 つだけ保持することはできますか? はいの場合、日時とユーザー ID 情報を更新するにはどうすればよいですか?

(日付とユーザー ID を使用して) 更新できるようにするには XREF エンティティが存在する必要があると思いますが、ナビゲーション プロパティ EmployeesDepartmentXREFs ではなく、 Departments と Employees を持つナビゲーションプロパティが本当に好きです。

これの中間点はありますか？ベストプラクティスは何ですか?

ありがとう。

Linq クエリと Entity Framework (4.1) の理解を深めようとしています。次の 2 つのクエリを見てください。どちらのクエリも、車種名 (CarType.Name) を返します。

最初のクエリでは、結合を使用し、ナビゲーション プロパティ CarType を無視しました

次に、ナビゲーション プロパティ CarType を使用しました

LinqPad で両方を実行したため、Guid.Parse 関数があります。

これらを実行すると、最初のステートメントがより速く実行されます。LinqPad は 00:00:036 を報告します。2 番目のステートメントの実行が遅くなり、LinqPad は 00:00:103 を報告します

結果を見ると、ナビゲーション プロパティの代わりに結合を使用する Linq クエリの方が高速であるように見えます。本当にそうですか？誰かがこれに光を当ててください。Linq クエリを作成する際に従うべき一般的なガイダンスやベスト プラクティスはありますか?

ありがとう

EF4.3、POCO、遅延読み込み、およびIValidatableObjectインターフェイスを使用しています。

契約エンティティと1対1の関係にあるローンエンティティがあります。コントラクトには、必要な場合を除いてアンロードしたままにしておくのが最適な一連のデータが含まれています。

私の問題は...ローンエンティティに変更を加える場合、Validateメソッドは、関連する契約エンティティをロードして、ローンの状態（またはステータス）に応じてデータが有効であることを確認することを目的としています...しかし、契約はナビゲーションプロパティはnullのままですか？SaveChangesが呼び出される直前にローンをクイックウォッチすると、コントラクトデータが読み込まれ、SaveChangesは正常に続行されます。それ以外の場合は、失敗します。

誰かが私がこの振る舞いを見ている理由を説明することができれば、私は最も感謝するでしょう。

乾杯

クレイグ

これは短い質問の長い紹介です、ごめんなさい!!

私はEF 4.3.1 Code Firstで作業しており、次のモデルを持っています

そして、多対多マッピングを使用して、他のクラス ライブラリで定義されている私の DBContext クラス:

これで問題なく動作します。しかし、メソッドに気付くAction.AuthorizeRole(Role role)と、役割の承認ロジックが複雑である可能性があると簡単に推測できます (現在は承認済みの検証がいくつかありますが、任意の検証である可能性がありますよね?)。モデル。しかし... Requirements for Creation POCO Proxiespublic virtual ICollection<Role> Roles {get; set;}によると、少なくとも getter はロール コレクションを公開する必要があります。つまり、Action クラスのクライアントは、検証ロジックをバイパスしてロールを追加または削除できます。はい、遅延読み込み、変更追跡、動作が必要なので、プロキシを作成する必要があります。

public virtual ICollection<Role> Roles {get; set;}よろしくお願いします。後でプロキシの作成をテストするために、このプロパティを非パブリック プロパティにする方法をいくつかテストすることにしました。プロキシが生成したサブクラスは自分のクラスであり、継承者は信頼するがクライアントは信頼しないため、プロパティprotectedを so のようにすることにしましたprotected virtual ICollection<Role> Roles {get; set;}。しかし、もちろん、次の行でコンパイルエラーが発生しました

現在、プロパティは保護されており、Action クラスまたはその継承者の外部ではアクセスできず、確かにmyDBコンテキスト クラスはそれらの 1 つではないためです。

myDBそのため、プロパティ(プロパティ) を公開せずに、クラスからプロパティにアクセスしようとする必要がありました。そして、私は反射について考えました。私のコンテキストクラスは次のようになりました：

new methodExtractPropertyValueに注意してください。多対多マッピング命令での呼び出しです。これは正しく機能しますか？HasMany メソッドは、Action を受け取り、何か (この場合は Role) の ICollection を返す関数を期待しており、それが取得されています。しかし、いいえ、動作しません。もちろんコンパイルされますが、実行時に、「この式は obj => obj.MyProperty のような有効なプロパティでなければなりません」のような例外が発生しました。

わかりました、それは「直接的な」プロパティである必要があり、DBContext クラスにアクセスできる必要があります。プロパティを protected internal に設定し、DBContext クラスをドメイン クラス ライブラリ (すべてのエンティティが定義されている場所) に移動することにしました。 . 私の財産は次のように見えました：

そして、このような私の DBContext クラスは、最初に持っていたものとまったく同じですが、すべてのエンティティと同じクラス ライブラリで定義されているだけです。

そして、これは問題なく動作します。したがって、チェックする必要があるのは、プロキシの作成、つまり、遅延読み込みと変更の追跡だけです。プロパティがパブリックではなく内部で保護されているため、機能しないのではないかと心配していましたが、すべてスムーズに機能しました。

では、質問・お願いです。プロキシを作成するためにナビゲーション プロパティを実際にパブリックにする必要がない場合は、protected で十分です (関係マッピングにそのプロパティを使用する機能にのみ影響すると想定しているため、internal out を省略しています)。 HasMany メソッドのプロパティを抽出する式、またはさらに良いことに、プロパティはマップされているタイプのプロパティである必要があり、ランダムなコレクションではないことを理解しているため、文字列 propertyName を受け取る HasMany のオーバーロードがないのはなぜですかパブリック プロパティでなくても、プロパティ自体を検索します。これにより、非パブリック ナビゲーション プロパティを使用できるようになります。これは、私の観点では、きちんとデザインされたオブジェクト ドミアンを可能にします。

多分私はここで何かを逃しています。

どうもありがとう。

Entity Framework Code First を使用しており、必要のないときに Insert、Update、および Delete のエンティティの変更をロールバックしようとして問題が発生していSaveChanges()ます。

具体的には、いくつかの補助テーブルを変更するために、TableEditor として使用している datagridview があります。datagridview は にバインドされていDbSet<TEntity>ます。

Update のロールバックは正常に機能しているようです。currentValues を OriginalValues に戻すように設定し、状態を に変更しunchangedます。

レコードがグリッドビューに挿入されると (ただし、変更は保存されません)、エンティティ クラスには表示されず、二度と表示されません...だから、dbSet に到達しないと思います。ロールバックはありません。これに必要ですか？

しかし、私の主な問題は Delete にあります:

私が理解していることから、レコードが「削除」されると (例: )、 SaveChanges が呼び出されるまで、tableData.Remove(currentItem);単に削除対象としてマークされます。State をdeletedback からに変更するunchangedと、ロールバックが処理されるはずですよね?

レコードは再び表示されますが、レコードのナビゲーション プロパティは失われています。(つまり、外部キーと他のエンティティとの必要な関係を含む列)。どうしてこれなの？？！

これが私がこれまでに持っているものです：

使用例:

ナビゲーション プロパティがレコードから消える理由はありますか? （または、それらを取り戻すために何ができますか？）

私はDbContextを使用しているので、ロールバック メソッドを次の行に置き換えました。

ただし、レコードがまだ欠落しているため、これはコンテキストをリロードしていないようです...Refresh間違って使用していますか?

これは私の問題の可能な解決策のように思えますが、なぜナビゲーション プロパティが削除されるのか疑問に思っています。