昔ながらの SQL DB アクセスと ORM (NHibernate、EF など) の比較。誰が勝ちますか？

Question

私はストアド プロシージャとパラメータ化されたクエリを組み合わせた独自の SQL アクセス コードと、ADO.NET のグランジを最小限に抑えるために作成した小さなラッパー ライブラリを作成することに成功しました。これまで私にとってこれはすべて非常にうまく機能しており、非常に生産的でした。

新しいプロジェクトに着手しています。昔ながらのことは忘れて、ORM ベースのソリューションを検討する必要がありますか?(NHibernate と EF の間には大まかな概念の違いがあることは承知していますが、ここではそれについては触れたくありません。議論のために、LINQ を昔ながらの代替手段と一括りにしてみましょう。) 私は、私が知っている (そしてかなりよく知っている) ものに対する ORM タイプのものの実世界への応用に関するアドバイスを探しています。

昔ながらの ADO.NET コードまたは ORM ですか?曲線があると確信しています。その曲線には、物事を価値のあるものにする ROI がありますか?不安があり、学ぶ意欲はありますが、期限があります。

Answer 1

良い質問ですが、非常に物議を醸すトピックです。

Frans Bouma のブログ投稿 数年前から、ストアド プロシージャよりも動的 SQL (ORM を暗示する) の長所を引用して、激しい炎上戦争が巻き起こりました。

Answer 2

コードのプロトタイプを作成するときは、LINQ to SQL の方がはるかに高速であることがわかりました。今何かが必要なときに、他の方法は吹き飛ばされます。

しかし、コストがかかります。手動で展開されたストアド プロシージャと比較すると、LINQ は遅いです。特に、一見小さな変更が突然 1+N クエリに変わってしまう可能性があるため、十分に注意していない場合はそうです。

私のおすすめ。最初は LINQ to SQL を使用し、必要なパフォーマンスが得られない場合は procs に切り替えます。

Answer 3

モントリオールの DevTeach では、このトピックについて素晴らしい議論が行われました。この URL にアクセスすると、次のようになります。 http://www.dotnetrocks.com/default.aspx?showNum=240 この分野の 2 人の専門家 (Ted Neward と Oren Eini) が各アプローチの長所と短所について議論するのを聞くことができます。おそらく、明確な答えがない主題に関して、あなたが見つける最良の答えでしょう。