私は、ストアド プロシージャとパラメーター化されたクエリを組み合わせた独自の SQL アクセス コードと、ADO.NET グランジを最小限に抑えるために作成した小さなラッパー ライブラリを作成することに成功しました。これは過去に私にとって非常にうまく機能しており、かなり生産的でした.
私は新しいプロジェクトに向かっています.古い学校のものを私の後ろに置いて、ORMベースのソリューションを掘り下げる必要がありますか? (NHibernate と EF の間には、高度な概念の大きな違いがあることはわかっています。ここではそれについては触れたくありません。議論のために、LINQ を古い学校の代替手段とひとくくりにしましょう。)私が知っている（そしてかなりよく知っている）ものに対するORMタイプのものの実世界への適用に関するアドバイス。
古い学校の ADO.NET コードまたは ORM? 曲線があると確信しています。曲線には価値のある ROI がありますか? 私は不安で学びたいと思っていますが、締め切りがあります。
コードのプロトタイプを作成しているときは、LINQ to SQL の方がはるかに高速であることがわかりました。今何かが必要なときに、他の方法を吹き飛ばすだけです。
しかし、コストがあります。手巻きのストアド プロシージャと比較すると、LINQ は低速です。特に、一見些細な変更が突然 1+N クエリに変わる可能性があるため、あまり注意しない場合はなおさらです。
私のお勧め。最初に LINQ to SQL を使用し、必要なパフォーマンスが得られない場合は、procs に切り替えます。
良い質問ですが、非常に物議を醸すトピックです。
数年前のFrans Bouma によるこのブログ投稿は、ストアド プロシージャに対する動的 SQL (ORM を意味する) の利点を引用して、激しい炎上戦争を引き起こしました。
このトピックについては、モントリオールの DevTeach で素晴らしい議論がありました。この URL: http://www.dotnetrocks.com/default.aspx?showNum=240にアクセスすると、この分野の 2 人の専門家 (Ted Neward と Oren Eini) が各アプローチの長所と短所について話し合うのを聞くことができます。 . 本当の明確な答えがない主題について、おそらくあなたが見つける最良の答えです。