問題タブ [entity-framework-4]

私は自分のプロジェクトのORMツールを決定しようとしていますが、EF4について考えています。

この製品の主な（もしあれば）煩わしさ/制限は何ですか？また、キャッシュをサポートしていますか？

ありがとう

次のことができるようになりたいです。

私にはモデルがあり、その中にエンティティがあります。

このエンティティの構造は次のとおりです。

私が今欲しいのは、IDに基づいてクライアント名を取得することです。したがって、これを行うストアドプロシージャを作成しました。

ここで VS に戻り、ストアド プロシージャを含めてデータベースからモデルを更新します。

次のステップは、このストアド プロシージャを関数インポートとしてクライアント エンティティにマップすることです。

これもうまくいきます。

1 つのクライアントの名前を読み込もうとすると、実行時にエラーが発生します...

「データ リーダーは、指定された 'CSTestModel.Client' と互換性がありません。タイプ 'Id' のメンバーには、データ リーダーに同じ名前の対応する列がありません。」

メッセージでOKです。これを修正する方法を知っています (結果セット ID、名前、説明として返されます)。

この質問の背後にある私の考えは次のとおりです。

完全なエンティティ自体ではなく、エンティティの一部をロードしたいだけです。ここでは、データベースとの間の通信全体にストアド プロシージャのみを使用するという制限があります。

私の問題に対する解決策はありますか (複雑な型の作成、結果セット自体に対する LINQ を除く)? はいの場合、誰かが私を正しい方向に向けることができますか?

どうもありがとう、

ディミ

DevConnectionsの間に、私はSilverlightトラックを離れて、EF4についてのChrisSellsによる素晴らしい話に出くわしました。3.5SP1に対して現在可能なことには本当に感銘を受けました。同時に、重いPOCOアーキテクチャであるシステムを採用し、EF4をミックスに挿入することで、どのようなメリットがあるのだろうかと考えています。追跡を変更しますか？LINQ？私が考えていない他の何か？

EntityFrameworkファイルを作成しました。私のデータベースはMyDBと呼ばれています。私のEntityFrameworkファイルはMyDB.edmxであり、既存の接続文字列（MyDBConnectionString）を使用してedmxモデルを生成しました。

さらに2つの接続文字列を作成しました：
MyDBEntities
MyDBContainer

これらは何のためにありますか？それらはまったく同じように見え、両方とも私の古い接続文字列からの情報を持っています。

古い接続文字列はまだ必要ですか？

詳細情報で更新：

接続文字列は次のとおりです。

MyDBConnectionStringという最初のものを作成しました。次に、データベースVisual Studioからedmxモデルを生成したときに、MyDBEntitiesおよびMyDBContainer接続文字列を作成しました。他の2つ（エンティティとコンテナ）は何のためにありますか？元の接続文字列はもう必要ありませんか？

標準テンプレート「ASP.NET MVC 2 Web アプリケーション」ソリューション、空 (データが挿入されていないことを意味しますが、すべてのテーブルなどは準備ができて待機中) の SQL Server データベース、Entity Framework 4 モデル (edmx) があります。モデル内のすべてのエンティティに対して単純な CRUD コントローラーとフォーム ビューを生成する方法はありますか?

.EDMXファイルを右クリックしてをクリックGenerate Database From Modelすると、テーブル名が原因で結果のスクリプトが明らかに間違っています。生成されるのは次のスクリプトです。DROP TABLEパーツとパーツのテーブル名に注意してくださいCREATE TABLE。

なぜこれが一貫していないのですか？

これは明らかに再利用可能なスクリプトではありません。私が作成したのは、「住所」という名前のエンティティと「会社」という名前のエンティティなどです（すべて単数）。EntitySet 名は複数形です。「Pluralize New Objects」ブール値もこれを変更しません。それで、取引は何ですか？

価値があるのは、最初に、複数形化されていない名前のテーブルを持つデータベースを指すことで EDMX を生成したことです。いくつかの変更を加えたので、逆に戻りたいと思います。db-first モデルも model-first モデルもすべてのシナリオで理想的ではないため、前後に移動するオプションが必要です。また、複数の人が両方を使用することによるマージの問題がないように制御できます。同時に方法。

こんにちはみんな私は次の状況をモデル化する必要があります。私は2つの可能な選択肢を思いついたが、もっと良い解決策があるかどうか知りたい。

これが取引です...

簡略化されたスキーマ

これは簡単です。ユーザー用のテーブル、グループ用のテーブル、そしてユーザーをグループに関連付けるためのテーブル（多対多）

次に、ユーザーとグループの両方が所有できる他のエンティティ（つまり、記事）があります（1人のユーザーが所有できる、1つのグループが所有できる、またはユーザーとグループが所有できるなど）。

これが取引です。私はそれをできた：

A

ここで重要なのは、特定のユーザーが特定の記事を所有しているかどうかを確認したい場合、両方を確認する必要があるようです。これはT-SQLを使用すると簡単ですが、Entity Frameworkを使用したいと思います（これまでORMを使用したことがないので、xDを使用してください）。

この状況をどのようにモデル化しますか？

別のアプローチは次のとおりです。

B

すべてのユーザーのグループを作成し、そのユーザーの内部のみを含み、グループによってのみ所有権を管理します。これはあなたにとってどのように聞こえますか？

すべての人に感謝し、私の説明があまり明確でない場合は申し訳ありませんが、私の英語は完璧ではありません。

Linq-To-Sql の相対的な単純さと、Entity Framework のバージョン 1 で寄せられたすべての批判 (特に、不信任投票) により、「当面の間」Linq-To-Sql を使用することにしました。EF 4.0 がリリースされたので、EF 4.0 への移行を開始する時期が来ているのではないかと考えています。

質問:

1. Linq-To-Sql に対する EF 4.0 の長所と短所は何ですか?
2. EF 4.0 は最終的にプライム タイムの準備ができていますか?
3. 今こそ乗り換え時？

csdl、ssdl、ビューを生成せずに、edmgenツールでobjectLayerのみを生成するにはどうすればよいですか？

"％windir％\ Microsoft.NET \ Framework \ v4.0.30319 \ edmgen.exe" / mode：fullgeneration / c： "DataSource=。\sqlexpress;Initial Catalog = uqs; Integrated Security = SSPI" / project：generateEntityModel / entitycontainer ：uqsEntities / namespace：uqsModel / language：CSharp / outobjectlayer： "D：/uqsObjectLayer.cs"

このスクリプトでは、csdl、ssdl、およびビューを書き込む場所を記述していませんが、Windows VistaのC：\ Users \ adminUserに生成され、objectLayerはD：/uqsObjectLayer.csに生成されます。/ mode：EntityClassGenerationを使用する場合、this option requires the /incsdl argument and either the /project argument or the /outobjectlayer argument. The /language argument is optional.

しかし、私はcsdlファイルを使用したくありません。私が理解しているように、edmgen.toolはcsdlファイルなしではobjectlayerを作成できません。dbからオブジェクトレイヤーを生成するための代替方法またはツールはありますか？

で使用するTryGetObjectByKeyとObjectContext、エラーが返されます。値が重複するアイテムが既に存在します。

私の を見ると、が空objectContextであることがわかります。ObjectSet私は何を間違っていますか？ObjectSet手で、それを使用ToArrayして、またはデバッガーを使用して列挙すると、機能します。

LazyLoadingEnabledに設定されていtrueます。

別の EDMX から 2 つのテーブルを再利用しますが、それらは異なる名前空間にあり、objectSetアプローチしようとしている s ではありません。