Linq を使用すると、後の段階でプロジェクトを維持/アップグレードするのに費用がかかりますか?
以前は、コードが本番環境に移行した後に簡単に変更できるストアド プロシージャを使用していたでしょう。
私は、多くのインライン SQL を使用するレガシー アプリケーションを使用している顧客のために働いています。彼らは、高速な応答時間を必要とするアプリケーションのストアド プロシージャにこれらを入れるためにお金を払ってきました。また、Linq がインライン SQL のように見えるため、Linq を使用する可能性に興奮していません。
Linq はインライン SQL と同等ですか? Linq によって私の生活が楽になることはわかっていますが、1 年か 2 年後はどうでしょうか?
Entity Framework を使用することの唯一の欠点は、緊急の変更 (たとえば) が必要な場合、ストアド プロシージャを変更するだけでなく、コードの変更を検討していることです。私たちの環境では、データベースにスクリプトを変更することは、新しいコードをプッシュするよりもはるかに簡単です。そのため、環境内で新しい .dll をプッシュするか、ストアド プロシージャの変更をプッシュするかのどちらを好むかということになります。
保守性に関しては、かなり長い間 Entity Framework を使用しており、アップグレードや保守性の問題はまったくありませんでした。書くのも維持するのも簡単で、Linq を正しく書いていれば、更新や変更も簡単です。
式がより明確で理解しやすくなっている限り、将来的には維持しやすくなると確信しています。
すべてがストアド プロシージャ ベースであるアプリケーションでは、新しい機能をコード化してスクリプト化する必要があり、展開するのが面倒な場合があります。新しい方法では、別の linq 式を使用して新しい関数を公開する場合がよくあります。新しいストアド プロシージャとアップグレード スクリプトを作成する手間がなくなります。(もちろん、コードはまだロールアウトする必要があります..)
私の意見では、速度はごくわずかです-ストアドプロシージャは確かに高速であり、EFは常に最適なSQLを思い付くとは限りませんが、それから人生をシンプルにすることができます:顧客を返すための中間/データ層がある場合IDで、名前で顧客を取得したい。新しいメソッド、新しいストアド プロシージャ、これをロールアウトするためのスクリプトなどが必要です。一方、EF を使用する場合は、新しいメソッドを追加するだけです。