タグ付けされた質問 「entity-framework」

Microsoftによって構築されたORMで、.Net Framework 3.5以降の一部として利用できます。


3
エンティティフレームワークはトラフィックの多いWebサイトに適していますか?
Entity Framework 4は、潜在的に1000ヒット/秒のパブリックWebサイトに適したソリューションですか? 私の理解では、EFは主に小規模またはイントラネットのWebサイト向けの実行可能なソリューションですが、人気のあるコミュニティWebサイトのようなものには簡単に拡張できません(SOがLINQ to SQLを使用していることは知っていますが、もっと例/証拠が欲しいです) ..) 現在、純粋なADO.NETアプローチを選択するか、EF4を選択するかの岐路に立っています。EFを使用した開発者の生産性の向上は、ADO.NET(ストアドプロシージャを使用)のパフォーマンスの低下ときめ細かいアクセスに値すると思いますか?トラフィックの多いWebサイトが直面する可能性のある深刻な問題は、EFを使用していたのですか? 前もって感謝します。

9
リポジトリはIQueryableを返す必要がありますか?
のインスタンスを返すリポジトリを持つプロジェクトをたくさん見てきましたIQueryable。これにより、追加のフィルターとソートをIQueryable他のコードで実行でき、異なるSQLが生成されます。私はこのパターンがどこから来たのか、それが良いアイデアであるかどうかに興味があります。 私の最大の懸念はIQueryable、データベースが列挙されると、しばらくするとデータベースにヒットするという約束です。これは、エラーがリポジトリの外部にスローされることを意味します。これは、Entity Framework例外がアプリケーションの別のレイヤーでスローされることを意味する場合があります。 また、過去(特にトランザクションを使用する場合)に複数のアクティブな結果セット(MARS)の問題に遭遇しましたが、このアプローチはこれがより頻繁に発生するように聞こえます。 リポジトリコードを終了する前に、常にLINQ式を呼び出すAsEnumerableかToArray、各LINQ式の最後でデータベースがヒットすることを確認しました。 IQueryableデータレイヤーのビルディングブロックとして戻ることが役立つかどうか疑問に思っています。あるリポジトリが別のリポジトリを呼び出してさらに大きなIQueryable。

4
大規模システムのEntity Framework-モデルの分割方法
私は、1000以上のテーブル、さらに数百のビュー、数千のストアドプロシージャを備えたSQL Serverデータベースを使用しています。新しいプロジェクトにEntity Frameworkの使用を開始したいと考えており、そのための戦略に取り組んでいます。ハングアップしているのは、テーブルを異なるモデルに分割する最良の方法です(最初にコードを作成する場合は、EDMXまたはDbContext)。私はすぐにいくつかの戦略を考えることができます: スキーマによる分割 テーブルはおそらく12個のスキーマに分割されています。スキーマごとに1つのモデルを作成できます。ただし、dboは500を超えるテーブル/ビューで非常に大きくなるため、これは完全ではありません。もう1つの問題は、特定の作業単位が複数のモデルにまたがるトランザクションを実行しなければならないことです。これにより、EFがこれをかなり簡単にすると仮定します。 意図 で分割するスキーマを気にする代わりに、モデルを意図で分割します。そのため、取得する粒度に応じて、アプリケーション、プロジェクト、モジュール、または画面ごとに異なるモデルを用意します。これに伴う問題は、UserやAuditHistoryなど、すべての場合に必ず使用する必要がある特定のテーブルがあることです。それらをすべてのモデルに追加しますか(DRYに違反すると思います)、それともすべてのプロジェクトで使用される別のモデルにありますか? まったく分割しないでください-1つの巨大なモデル これは開発の観点からは明らかにシンプルですが、私の研究と直感から、設計時、コンパイル時、そしておそらく実行時の両方でひどく実行できるようです。 このような大規模なデータベースに対してEFを使用するためのベストプラクティスは何ですか?具体的には、この大量のDBオブジェクトに対してモデルを設計する際にどのような戦略を使用しますか 私が上で持っているものよりもうまく機能すると思っていないオプションはありますか? また、これはNHibernateなどの他のORMの問題ですか?もしそうなら、彼らはEFよりも優れたソリューションを考え出しましたか?

14
ORMフレームワークをよく知っている場合、SQLは重要ですか?[閉まっている]
私はSQLに真剣な経験はなく、LINQの代わりにSQLを書くことさえ嫌いです。ORMには十分満足しています。 雇用主とセクターの観点から、SQLを知ることは重要ですか?習得する必要がありますか?ORMフレームワークよりも純粋なSQLを好む企業は、プログラミングの世界で「恐竜」ですか?

5
データベースに何かが存在するかどうかを確認し、高速で失敗するか、データベース例外を待つ必要がありますか
2つのクラスがある: public class Parent { public int Id { get; set; } public int ChildId { get; set; } } public class Child { ... } 割り当てるときChildIdにParent、それが例外をスローするDB用DBまたは待機中に存在する場合、私が最初に確認する必要がありますか? 例(Entity Framework Coreを使用): 注:これらの種類のチェックは、Microsoftの公式ドキュメントでもインターネット全体で行われます:https : //docs.microsoft.com/en-us/aspnet/mvc/overview/getting-started/getting-started-with-ef-using- mvc / handling-concurrency-with-the-entity-framework-in-an-asp-mvc-application#modify-the-department-controllerしかし、追加の例外処理がありますSaveChanges また、このチェックの主な目的は、APIのユーザーにわかりやすいメッセージと既知のHTTPステータスを返すことであり、データベースの例外を完全に無視することではないことに注意してください。そして、例外がスローされる唯一の場所は、内部にあるSaveChangesかSaveChangesAsyncを呼び出すときに例外がありません...コールFindAsyncまたはAny。そのため、子が存在するが以前に削除されていた場合SaveChangesAsync、同時実行例外がスローされます。 これは、foreign key violation「ID {parent.ChildId}の子が見つかりませんでした」と表示するために、例外の書式設定がはるかに困難になるという事実のために行いました。 public async Task<ActionResult<Parent>> CreateParent(Parent parent) { // is this …

5
Entity Frameworkを使用する必要がありますか?
現在、次のスタックがあります。 VS 2005 Webフォーム SQL Server 2005 IIS 6 これへの移行を計画しています: VS 2010 MVCとWebフォーム SQL Server 2008 IIS 7 私の質問は、VS 2010でMVCに移行するとき、Entity Framework(または別のORM)、micro ORM(Massiveなど)、または単なるSQLを使用する必要がありますか? VS 2010について読んだすべてのチュートリアルは、データトランザクションにEntity Frameworkを使用することを目的としていますが、それは近い将来(5年以上)続くでしょうか? 問題があれば、クライアントのアプリケーションには10〜1,000人のアクティブユーザーを含めることができます。

6
EntityFrameworkを使用していくつかの引数は何ですか?[閉まっている]
現在作成しているアプリケーションは、ストアドプロシージャと手作りのクラスモデルを使用してデータベースオブジェクトを表現しています。一部の人々はEntity Frameworkの使用を提案しており、私はプロジェクトにそれほど遠くないので、それに切り替えることを検討しています。私の問題は、EFを主張する人々が悪い面ではなく、良い面だけを教えてくれると感じていることです:) 私の主な懸念は次のとおりです。 DataAnnotationsを使用してクライアント側の検証が必要であり、とにかくクライアント側のモデルを作成する必要があるように思えるので、EFがそのようなコーディング時間を節約するかどうかはわかりません ネットワークを経由するときにクラスをできる限り小さくしたいのですが、EFを使用すると、多くの場合、不要な追加データが含まれることがあります 複数のデータベースにまたがる複雑なデータベースレイヤーがあり、EFがこれを処理できるかどうかはわかりません。ユーザー、ステータスコード、タイプなどを含む共通データベースと、アプリケーションの異なるインスタンス用のメインデータベースの複数のインスタンスがあります。SELECTクエリは、データベースのすべてのインスタンスに対してクエリを実行できますが、ユーザーは、現在作業しているデータベース内のオブジェクトのみを変更できます。アプリケーションをリロードせずにデータベースを切り替えることができます。 オブジェクトモードは非常に複雑で、多くの場合、多くの結合が関係します EFの引数は次のとおりです。 並行性。各保存の前にレコードが更新されたかどうかを確認するためにチェックをコーディングする必要はありません。 コード生成。EFは私のために部分クラスモデルとPOCOを生成できますが、検証といくつかのカスタム解析メソッドのためにクライアント側モデルを作成する必要があると思うので、これは本当に多くの時間を節約するだろうと確信しています。 すべてのデータベースオブジェクトに対してCRUDストアドプロシージャを作成する必要がないため、開発の速度 現在のアーキテクチャは、パラメーター化されたストアドプロシージャを介してデータベース呼び出しを処理するWPFサービス、WCFサービスとWPFクライアントとの間でやり取りされるPOCOオブジェクト、および検証のためにPOCOをクラスモデルに変換するWPFデスクトップクライアントで構成されますデータバインディング。 私の質問は、EFはこれに適していますか?EFについて私が知らない落とし穴はありますか?

3
Entity Framework Code Firstは、本番環境では少し意味がありません/役に立たないのですか?
私は最近Entity Framework 4.1 Code Firstでプログラミングをしており、開発にそれを愛していますが、最終計画と急速に変化する機能リストだけで、アプリケーションのニーズに合わせてクラス/データベースを常に変更しています。 開発では、ライブデータはなく、データベース全体を簡単に削除できるので、新しいスキーマで再作成されますが、ライブ時には明らかに、これは非常に悪いです! 私が見ることができる唯一の解決策は、メタデータテーブルを削除して手動でデータベースの同期を維持するか、基本的に削除して再シードすることです。 個人的には、データを再作成して移行するよりも列/テーブルを追加する方がはるかに簡単だと思うため、最初の方法を好みますが、何かを見逃していない限り、これはCode Firstから完全に離れています。 質問は本当に、最初の開発についてのCode Firstだけであり、実稼働環境でEFを管理するための優れた戦略は何ですか?

5
エンティティオブジェクトをデータ転送オブジェクトとして使用することをお勧めしますか?
エンティティフレームワークが、レイヤー間でデータを転送するために同じプロパティを持つ新しいオブジェクトを作成するロジックを提供しないのはなぜですか? エンティティフレームワークで生成したエンティティオブジェクトを使用します。

6
Generic Repositoryには本当に利点がありますか?
新しいアプリ用の汎用リポジトリを作成する利点に関するいくつかの記事を読んでいました(例)。同じリポジトリを使用して、複数の異なるエンティティタイプに対して複数の処理を一度に実行できるため、このアイデアは素晴らしいようです。 IRepository repo = new EfRepository(); // Would normally pass through IOC into constructor var c1 = new Country() { Name = "United States", CountryCode = "US" }; var c2 = new Country() { Name = "Canada", CountryCode = "CA" }; var c3 = new Country() { Name = "Mexico", …

3
IEnumerable <T>ではなくList <T>を使用する必要があるのはなぜですか?
ASP.net MVC4 Webアプリケーションでは、IEnumerablesを使用して、実装ではなくインターフェイスにプログラムするというマントラに従っています。 Return IEnumerable(Of Student) 対 Return New List(Of Student) リストはクエリを強制的に実行し、IEumerableは実行しないため、人々はIEnumerableではなくListを使用するように言っています。 これは本当にベストプラクティスですか?代替手段はありますか?インターフェイスを使用できる具体的なオブジェクトを使用すると、奇妙に感じます。私の奇妙な気持ちは正当化されますか?

2
ASP.NET MVCアプリケーションは、Entity Frameworkをモデルとして直接使用する必要がありますか?
私はVisual Studio 2013(MVC 5)で最初のMVCアプリケーションを構築していますが、モデルをセットアップする最適な方法については少しわかりません。 既存のデータベースからコードファーストを使用して、エンティティフレームワークモデルを生成しました。私の最初の本能は、ビューで使用されるモデルとなるいくつかの中間クラスを作成し、それらのクラスをエンティティフレームワーククラスと連携させることでした。 中間クラスを書いているとき、EFクラスがたまにプライベートセッターで行ったり、あるデータ型から別のデータ型にキャストしたりすることの多くを再実装していることに気付きました。それは無駄のように思えた。 エンティティフレームワーククラスをMVCアプリケーションのモデルとして直接使用するという一般的な規則はありますか?または、これらの中間クラスを構築するのに欠けている利点がありますか?

4
多対多(ジャンクション)テーブルに一意のID列が必要ですか?
EFでいくつかのプロジェクトを開始しましたが、結合テーブルやキーなどについて質問がありました。アプリケーションのテーブルと権限のテーブルがあるとします。アプリケーションには多くの権限があり、各権限は多くのアプリケーション(多対多)に属することができます。 これで、アプリケーションテーブルとアクセス許可テーブルが簡単になりました。 Applications -------------- PK ApplicationID Name Permissions -------------- PK PermissionID Name しかし、結合テーブルを実行する最良の方法は何ですか?次の2つのオプションがあります。 ApplicationPermissions ----------------------- PK ApplicationPermissionID CU ApplicationID CU PermissionID または ApplicationPermissions ----------------------- CPK ApplicationID CPK PermissionID PK = Primary Key CPK = Composite Primary Key CU = Composite Unique Index ある方法で他の方法よりもやけどをしたことがありますか?それは厳密に好みですか?リポジトリパターンによって多くの「違い」が抽象化されることがわかりました(たとえば、アクセス許可オブジェクト全体を作成してアプリケーションに追加することはほとんどありませんが、IDまたは一意の名前または何か)、しかし、私はホラーストーリーを探していると思います。

3
複雑なオブジェクトモデルのリポジトリパターンを実装するにはどうすればよいですか?
この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 7年前に移行され ました。 データモデルには、約12の機能領域に分離できるほぼ200のクラスがあります。ドメインを使用するのは良かったのですが、分離はそれほどきれいではなく、変更することはできません。 エンティティフレームワークを使用するようにDALを再設計しており、これまで見てきたほとんどの推奨事項は、リポジトリパターンの使用を推奨しています。ただし、実際に複雑なオブジェクトモデルを扱うサンプルはありません。私が見つけたいくつかの実装は、エンティティごとのリポジトリの使用を提案しています。これは、大規模で複雑なモデルにとってはばかげており、維持できないようです。 操作ごとにUnitOfWorkを作成し、エンティティごとにリポジトリを作成する必要は本当にありますか?数千のクラスになってしまう可能性があります。これが不合理であることは知っていますが、リポジトリ、作業単位、およびエンティティフレームワークを複雑なモデルや現実的なビジネスアプリケーションに実装するガイダンスはほとんど見つかりませんでした。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.