直接テーブルアクセスのないエンティティフレームワーク
私がここで見つけたいくつかの同様の質問がありますが、それらのどれも私が求めている質問に完全に答えるものではありません。同様の質問： ここ および ここ
私の会社ではC＃.NETアプリケーションを開発していますが、ITのサーバー管理者はテーブルへの直接アクセスを許可していないため、テーブルの挿入、更新、削除にはストアドプロシージャを使用する必要があります。以前はDataSetsとTableAdaptersを使用してデータベースのテーブルにアクセスしてきましたが、すべてがEntity Frameworkを使用し始めていることに気付き始めています。
ここに私の問題があります。 Entity Frameworkを使用する別の開発者がいますが、実際にはエンティティを使用していません。彼はテーブルやビューを持たないエンティティモデルを使用し、ストアドプロシージャのみを使用しています。これはEntityフレームワークの目的を無効にしませんか、それとも私は狂っていますか？
また、挿入、更新、および削除の機能をストアドプロシージャにマップできることを理解しています。 this の記事では、それを実装する興味深い方法がいくつか言及されていますが、すべてのテーブルのビューを作成するのは非常に面倒です。より実用的または簡単に実装できる代替手段はありますか？
それはものの背景と好みに依存します。
一部の人々は、ストアドプロシージャを使い始めて、それらに非常に慣れています。彼らはT-SQLを愛しており、T-SQLで多くのことができます。最初にSPを記述し、次に最小限のラッパーを使用してSPを使用する傾向があります。一部の人々は、検証、ビジネスルール、データ変換などのロジックの多くをSPに好むことに注意してください。
他の人々は、オブジェクト指向プログラミングに慣れており、クラスを作成してから、それらのクラスをデータベースとの間でシリアル化することを好みます。これらの場合、ロジックはクラスに含まれる傾向があります。
エンティティフレームワークは、両方のタイプの開発をサポートします。ほとんどの場合、開発スタイルにとらわれず、過度に意見を述べているわけではありません。
しかし、あなたの状況では、あなたとあなたのチームは標準が何であるかを考案する必要があります。使用するEF機能の数とデータベース開発のスタイルについて決定する必要があります。
私は個人的にEFが提供できるすべてのものを使用することに傾倒しているので、すべてのエンティティを生成させます。次に、Linq to Objectsを使用してエンティティとの間でデータを移動し、EFにデータベースI/Oを処理させます。これを行うと、再利用およびテストが可能で、最も重要なのは理解できる、ナイスタイトコードを作成できることがわかりました。