Webページにデータが必要な場合は、SQLDataSourceにストアドプロシージャを呼び出させてみませんか？ObjectDataSourceを使用してビジネスオブジェクトを呼び出し、次にストアドプロシージャを呼び出すのはなぜですか？.netフレームワーク上に構築された他のアプリ（デスクトップアプリなど）がビジネスオブジェクトにアクセスできることを理解していますが、アプリケーションが常にWebアプリのみである場合はどうなりますか？
より明確にするために：
いつまたはを使用する必要がありますSqlDataSourceかObjectDataSource？
どのように選択を動機付けるのですか？
それが単なるデモ、プロトタイプ、または簡単なハックである場合、SQLDataSource だけを持つことは完全に有効です。それは速く、簡単で、ただ機能し、必要な結果をもたらします。
ただし、アプリが長期的に設計および構築されており、物事 (要件、顧客の要望、最終的にはデータベース スキーマ) が変化する可能性があると予想される場合は、適切な「ビジネス」レイヤーを導入する方がはるかに理にかなっている可能性があります。ビジネス オブジェクトをオブジェクトとしてモデル化し、基礎となるデータベースからそれらのビジネス オブジェクトへのマッピングを提供します。
ことわざにあるように、コンピュータ サイエンスのほとんどのことは、もう 1 層の間接化 (または抽象化) することで解決できますが、ここでも同じことが言えます。
確かに: データベースに直接アクセスできます。確かに、最初と最初の反復では、それがおそらく (またはおそらく) 最も速い方法です。しかし、長い目で見れば、アプリが長持ちするように構築されている場合、それは通常、迅速で汚い方法です。維持費、メンテナンス費、あなたとあなたの顧客のニーズに合わせて変更するために必要なコストと労力は増大します。そしてすぐに、その簡単な解決策は、労力の点で、もはやそれほど素晴らしいものではありません.
つまり、私のポイントを要約すると、はい、最初は、直接 SQL データ ソースを使用する方が速くて簡単かもしれません。そのため、それが重要なポイントである場合に使用してください。簡単なデモ、概念実証スタイルのアプリで物事を成し遂げるためです。しかし、長い目で見れば、アプリの寿命を考えると、Web ページがアプリケーションの詳細に直接依存しないように、この抽象化レイヤーを追加する (設計とコーディング) 労力をもう少し投資する価値があります。その下のデータベース。
マルク
プロジェクトで使用しているビジネスレイヤーがある場合は、ObjectDataSourceが自然な選択です。これは多くのORMによく適合し、それらの多くは追加の利点（検証、元に戻すなど）を提供します。また、直接SQLフィールドだけでなく、ビジネスオブジェクトにある他のプロパティやメソッドにもアクセスできます。これは、バインドするときに非常に便利です。これにより、多くのコードを背後に記述する代わりに、マークアップのプロパティにバインドすることができます。
このルートを使用する場合、SQLDataSourceとObjectDataSourceを混在させると、次の開発者がプロジェクトを選択する際に混乱を招く可能性があります。この場合、コードの一貫性を保つためにObjectDataSourceを使用します。
ビジネスレイヤーがなく、SQLに直接アクセスしている場合は、SQLDataSourceを使用します。私の個人的な好みは、すべてのSQLコードをビジネス層またはデータ層に配置することです。そのため、SQLDataSourceを使用することはほとんどありません。
ストアド プロシージャでビジネス レイヤー コードを適用できる場合は、SQLDataSource を使用することをお勧めします。