単一のストアドセレクトを呼び出すときにEntity Frameworkを実装する価値はありますか？
現在、エンタープライズレベルのビジネスインターンシップ用のWebアプリケーションを構築しています。このWebアプリケーションは、DB2データベース、SQL動的データベース、および既存のAPIの3つの異なるソースからのデータを追跡し、それらを結合します。
私は現在SQL動的側で作業しており、Entity Frameworkを使用してこのプロセスを合理化するようにアドバイスされました。私が理解していることから、EFは、ローカルデータベースコンテキストを作成してクエリを実行したり、SQLコードを生成したり、レコードを更新/挿入してセキュリティとパフォーマンスを向上させる場合に役立ちます。ただし、結合する必要があるSQLデータはSELECTによってのみ提供され、必要なデータを返す単一のストアドプロシージャを実装します。
私はすでにC＃でSQLストアドプロシージャにアクセスするためのAPIを開発しています（DBインフラストラクチャにより、これは彼らと私自身に大いに役立つだろうと助言されました）。個人的には、このソリューションにEntity Frameworkを追加する利点はわかりません。私の見解では（私のインターンポジションの結果として塩味を帯びています）、このソリューションにEFを追加しても、非内部パッケージへの依存度が高まり、将来のメンテナンスの複雑さが増すだけです。 SQLコードを生成したり、レコードを挿入したりする必要はありません。パラメータを渡すだけです。
このようなシナリオで、アクセスしているSQL DBに既に格納されている単一のストアドプロシージャにパラメーターを渡していますが、Entity Frameworkはどこで役立ちますか？そうでない場合は、この依存関係を削除するために私より上に提供できる説得力のある理由がありますか？
いいえ。必要に応じてSqlClientに慣れている場合は、EFを追加する価値はありません。
Sprocsを呼び出してEF経由で独自のSQL文字列を簡単に実行できますが、その機能を活用しておらず、アンウェアをトラップするためのいくつかの癖があり、それが原因でトリップする可能性があります。
実際には、EFを追加する価値はないということは間違いありません。しかし、それを別の日に任せましょう。
EFは確かに時々少し重いと感じることができます。 SQLの作成に慣れているので、DapperのようなマイクロORMがニーズに適しています。