それが単なるデモ、プロトタイプ、または簡単なハックである場合、SQLDataSource だけを持つことは完全に有効です。それは速く、簡単で、ただ機能し、必要な結果をもたらします。
ただし、アプリが長期的に設計および構築されており、物事 (要件、顧客の要望、最終的にはデータベース スキーマ) が変化する可能性があると予想される場合は、適切な「ビジネス」レイヤーを導入する方がはるかに理にかなっている可能性があります。ビジネス オブジェクトをオブジェクトとしてモデル化し、基礎となるデータベースからそれらのビジネス オブジェクトへのマッピングを提供します。
ことわざにあるように、コンピュータ サイエンスのほとんどのことは、もう 1 層の間接化 (または抽象化) することで解決できますが、ここでも同じことが言えます。
確かに: データベースに直接アクセスできます。確かに、最初と最初の反復では、それがおそらく (またはおそらく) 最も速い方法です。しかし、長い目で見れば、アプリが長持ちするように構築されている場合、それは通常、迅速で汚い方法です。維持費、メンテナンス費、あなたとあなたの顧客のニーズに合わせて変更するために必要なコストと労力は増大します。そしてすぐに、その簡単な解決策は、労力の点で、もはやそれほど素晴らしいものではありません.
つまり、私のポイントを要約すると、はい、最初は、直接 SQL データ ソースを使用する方が速くて簡単かもしれません。そのため、それが重要なポイントである場合に使用してください。簡単なデモ、概念実証スタイルのアプリで物事を成し遂げるためです。しかし、長い目で見れば、アプリの寿命を考えると、Web ページがアプリケーションの詳細に直接依存しないように、この抽象化レイヤーを追加する (設計とコーディング) 労力をもう少し投資する価値があります。その下のデータベース。
マルク