Linq to Sql やその他の ORM マッパーについて私が考えたことについて、コミュニティに意見を求めたいと思います。
Linq to Sql と、C# と SQL の間の「インピーダンスの不一致」に対処するよりも、ネイティブの開発言語でデータ アクセス ロジック (または一般的な CRUD 操作) を表現するというアイデアが好きです。たとえば、ビジネス レイヤーの Event インスタンスの ObjectDataSource 互換リストを返すには、以下を使用します。
return db.Events.Select(c => new EventData() { EventID = c.EventID, Title = c.Title })
古い SQL-to-C# コンストラクトを使用してこれを実装する場合、Command クラスを作成し、EventID パラメーターを追加して ("@EventID" 引数を記述する文字列を使用)、SQL クエリ文字列をコマンドクラス、コマンドを実行し、(cast-type)nwReader["FieldName"] を使用して、返された各フィールド値を取得し、EventData クラス (yuck) の新しく作成されたインスタンスのメンバーに割り当てます。
だから、人々は Linq/SubSonic/etc を好むのです。そして私は同意します。
しかし、全体像を見ると、間違っていることがたくさんあります。私の感覚では、Microsoft も何か問題を認識しているため、Linq to SQLを廃止し、人々を Linq to Entities に移行させようとしているのです。ただ、マイクロソフトは悪い賭けに賭けていると思います。
それで、何が悪いのですか？
問題は、Linq to Sql を見て、それが真のデータ管理ツールではないことに気付く、特に Microsoft のアーキテクチャ宇宙飛行士がいることです。 . これは、Linq to Entities の背後にある野心、Linq の革新的な性質 に関するブログ投稿、さらにはLinqPad の挑戦に表れています。
そして、それに関する問題は、SQL が問題であると想定していることです。つまり、軽度の不快感 (SQL と C# の間のインピーダンスの不一致) を軽減するために、Microsoft は、バンドエイド (Linq to SQL など) がうまく機能する場合に、宇宙服 (完全な分離) に相当するものを提案しました。
私が見る限り、開発者はリレーショナル モデルを習得し、それを開発作業に賢く適用するのに十分なほど賢いです。実際、Linq to SQL、SubSonic などはすでに複雑すぎます。学習曲線は、SQL 自体を習得することとそれほど違いはありません。近い将来、開発者はSQL とリレーショナル モデルを習得する必要があるため、現在、 2 つのクエリ/CRUD 言語の学習に直面しています。さらに悪いことに、Linq は多くの場合テストが難しく (クエリ ウィンドウがありません)、実行している実際の作業から 1 つのレイヤーを削除し (SQL を生成します)、次のような SQL 構造のサポートが (せいぜい) 非常に不器用です。日付処理 (DateDiff など)、「Having」、さらには「Group By」。
代替手段は何ですか？個人的には、Linq to Entities のようなデータ アクセス用の別のモデルは必要ありません。Visual Studio で単純にウィンドウをポップアップし、SQL を入力して検証し、ボタンを押して C# クラスを生成または補足し、呼び出しをカプセル化することをお勧めします。あなたはすでに SQL を知っているので、次のように入力することを好まないでしょうか。
Select EventID, Title From Events Where Location=@Location
最終的に、A) プロパティとして EventID および Title フィールドが含まれ、B) 'Location' 文字列を引数として受け取り、List<EventData>? オブジェクト モデルについては慎重に検討する必要がありますが (上記の例は明らかにそれを扱っていません)、インピーダンスの不一致を排除しながら SQL を使用するという基本的なアプローチは、私にとって非常に魅力的です。
問題は次のとおりです。私は間違っていますか? Microsoft は SQL インフラストラクチャを書き直して、SQL やリレーショナル データ管理をこれ以上学ぶ必要がないようにする必要がありますか? この方法で SQL インフラストラクチャを書き直すことはできますか? それとも、パラメーターを設定してデータ フィールドにアクセスする手間を省くために、SQL の上に非常に薄いレイヤーを配置するだけで十分だと思いますか?
更新2 つのリンクをトップに宣伝したかったのは、それらが私が求めているものの重要な側面を捉えていると思うからです。まず、CodeMonkey は「The Vietnam of Computer Science」というタイトルの記事を指摘しています。 読み始めるのに少し時間がかかりますが、非常に興味深い読み物です。次に、AnSGri は Joel Spolsky の著名な作品の 1 つであるThe Law of Leaky Abstractions を指摘しています。トピックとは正確には一致しませんが、近く、素晴らしい読み物です。
更新 2: ここには多くの優れた回答があり、「正しい」回答の選択は純粋に主観的ですが、ocdecio に「回答」を与えました。この場合、彼の答えは、現在のテクノロジーの状態を考えると、本当にベスト プラクティスであると私が考えるものと一致しています。ただし、これは進化することを完全に期待している領域であるため、状況が変わる可能性があります. 貢献してくれたすべての人に感謝したいと思います。思慮深い回答をしてくれたと思うすべての人に賛成票を投じました。