問題タブ [entity-framework]

エンティティフレームワークは、別のCRUDコードジェネレーターの単なる名前ですか？

それともそれ以上のものがありますか？

私は最近、Entity Framework (EF) の短所について詳しく話しているポッドキャストを聞いていました。

しかし、彼らの意見は、私が収集できるものから、(私が) 一粒の塩で受け取る必要があるかもしれません:

• 彼らは ORM の専門家でした。
• 彼らはORMツールか趣味で生計を立てていました
• 彼らは大規模なアプリケーションに ORM ツールを使用していました
• 彼らはまた、私が必ずしも関心を持っていない ALT.NET の超戦術にも非常に関心を持っていました (まだ)。

私の全体的な質問は次のとおりです。

• 現在、Entity Framework はどのような種類のプロジェクトに適していますか?

しかし、私がその質問でどこに向かっているのかを理解するのに役立つかもしれないいくつかのサブ質問があります:

1. EF は何もないよりも優れていますか? 私はすべてを手作業で行うのにうんざりしています。
2. LINQ to SQL と同様に「同じ問題を解決する」ことに近づいていますか? 2a. はいの場合、一方が他方より適しているのはいつですか? *このタグが付いた質問を調べていたときに、この質問に関するスレッドを見つけたので、気にしないでください *
3. 大量の管理用 CRUD フォームなど、単純な「クイック アンド ダーティ」アプリケーションに適していますか?

編集: 好奇心旺盛な人のために、私は主に小規模から中規模のアプリケーションに取り組んでいます。それはあなたの反応を導くことができるかどうか。

LINQ to ADO.net Data Services クエリを実行するときに、Expand キーワードを使用する代わりの方法があるかどうか疑問に思っています。expand メソッドは目的のデータを取得しますが、使用するサブオブジェクトをすべて事前に把握しておく必要があります。私の絶対的な好みは、それらのサブオブジェクトにアクセスするときに遅延ロードされることですが、これはオプションではないようです (この遅延ロードを get on そのサブオブジェクト プロパティに追加することもできますが、データ サービス参照の更新を行うと消去されます)。

この状況に対する提案/ベストプラクティス/代替手段はありますか? ありがとう。

===== MailingAddress を持つ Member を使用したコード例 =====

作品:

優先します (これが行って MailingAddress をロードした場合は本当に好きです)

または、少なくとも (注: サービス操作で LINQ to Entities として実行すると、MailingAddressReference を使用してこれに似たものがサーバー側で機能します)

クラス名を取得してC#で文字列に変換する方法はありますか?

Entity Framework の一部として、.Include メソッドは、クエリの実行時に結合する文字列のドット区切りリストを受け取ります。参加したいクラスモデルがあり、リファクタリングと将来のコードメンテナンスの理由から、このクラスを参照するときにコンパイル時の安全性を確保したいと考えています。

したがって、私がこれを行うことができる方法はありますか:

インスタンスなしで GetType() を実行できるとは思いません。何か案は？

Entity Framework の最適なガイダンスの方向性を教えてください。

.SaveChanges() メソッドの使用法に関する良い情報を持っている人はいますか?

データ コンテキスト オブジェクトで .SaveChanges() メソッドを使用しようとすると、さまざまな問題が発生します。既存のデータ ソースからデータを取得し、適切な EntityFramework/DataService オブジェクトを作成し、作成したオブジェクトにデータを入力し、それらのオブジェクトをコンテキストに追加してから、.SaveChanges を呼び出してそのデータを保存しています。

私が思いついたシナリオ (およびそれらに関連する問題) は次のとおりです...各シナリオでは、DataTable の行からデータを取得してオブジェクトを生成し、それらをコンテキストにアタッチする foreach ループがあります。彼らが行く。(注: SetLink 呼び出しを介してアタッチされた 3 つのオブジェクト「メンバー」と 2 つの「アドレス」) - 基本的に、これは 1 つのデータ ストアからデータを取得し、それを Data Services によって公開されるデータ ストアに変換するための変換ツールです。

• foreach ループの最後 (つまり、ループの外側) で、パラメータなしで .SaveChanges() を 1 回呼び出します。
  • 約 1/3 の OutOfMemory エラー (90,000 回の保存のうち 30,000 回) - 各保存項目はデータベースへの個別の SQL 呼び出しであるため、どのように発生しているのかわかりませんが、メモリ不足になる原因は何ですか?
• ループごとに 1 回、パラメータなしで .SaveChanges() を呼び出します
  • これは機能しますが、絶対に永遠にかかります（90,000回の保存で8時間）
• foreach ループの最後に .SaveChanges(SaveChangesOption.Batch) を 1 回呼び出します。
  • 同じ OutOfMemory エラーですが、データベースへの保存はありません
• ループごとに .SaveChanges(SaveChangesOption.Batch) を 1 回呼び出す
  • 404 見つからないエラー
• 10 ループごとに .SaveChanges(SaveChangesOption.Batch) を 1 回呼び出す
  • 400 Bad Request エラー (時折)
  • 何度か繰り返した後の OutOfMemory
• ループごとに 1 回コンテキストを作成するか、ループの開始時にコンテキストを変数として使用するか、使用可能なプライベート メンバー変数として使用するためのランダムな試行回数。
  • さまざまな結果、定量化できない、それほど良いものはありません

このような大量のデータの読み込みを行うときに、クライアント オブジェクトから .SaveChanges() を呼び出す方法として推奨されるものは何ですか? .SaveChanges() がどのように機能するかについて私が得ていないものはありますか? この機能をどのように利用すべきか、および Data Services を介してデータを保存する際の制限事項 (ある場合) について、詳細を提供できる人はいますか? .SaveChanges() メソッド呼び出しに関するベスト プラクティスはありますか? .SaveChanges() メソッド呼び出しに関する特に優れたドキュメントはありますか?

私は新しいプロジェクトを開始する準備をしており、エンティティ フレームワークを研究しています。私の質問は、エンティティを検証するための最良の戦略は何ですか? 私が取り組んできた他のプロジェクトでは、ほとんどの検証に属性を使用していましたが、明らかにこれはエンティティ フレームワークでは不可能です。プロパティセッターで部分メソッドを処理することによってこれを行う唯一の方法はありますか? すべてのアドバイスは大歓迎です。

VS.net 2008 で Entity Framework を使い始めるには何が必要ですか?

これを入力しながら vs.net 2008 の SP1 をダウンロードしています。

私が理解していることから、XMLを作成してから.exeツールを使用してコードを吐き出す必要がありますか?

既にデータベース スキーマが完成している場合、エンティティ フレームワークで何らかの方法でストレージ スキーマを生成できますか?

または、クラスを開発した場合、クラスとその関係を記述する他の xml を生成できますか?

だから私たちはアプリケーションを構築しています

• UI レイヤー (Web、モバイル、Ajax クライアントなど)
• サービス/API レイヤー
• ビジネスロジックレイヤー
• データ アクセス層

私たちの目標は、サービス層から DAL までの Entity Framework 依存関係を持つことです。つまり、サービス レイヤーは POCO (プレーンな古い CLR オブジェクト) のみを受け入れて返します。

私たちが現在行っていることは、POCO を EF エンティティに、またはその逆に変換するサービス層とビジネス ロジック層の間のマッピング層を手動でコーディングすることです。

つまり、ページにはフォームがあり、フォームには分離コードがあり、フォームのコンテンツを受け取り、POCO に詰め込み、サービス層に送信します。サービス レイヤーは EF エンティティに変換し、それをビジネス ロジック レイヤーに送信します。ビジネス ロジック レイヤーはエンティティに対して特定の変換を実行し、DAL とやり取りして永続化します。

はい、少し面倒ですが、もっと良い方法はないかと考えていました。

はい、誰かが EF Poco Adapter を公開したことは知っていますが、それはすべて C# で書かれており、VB.NET ソリューションを使用したいと考えています。

はい、NHibernate への切り替えは最後の手段です。すでに開発サイクルが進んでいるためです。