SqlDataSource と ObjectDataSource の比較

Question

Web ページにデータが必要な場合、SQLDataSource でストアド プロシージャを呼び出すだけではどうでしょうか?ObjectDataSource を使用してビジネス オブジェクトを呼び出し、その後ストアド プロシージャを呼び出すのはなぜでしょうか?.net Framework 上に構築された他のアプリ (デスクトップ アプリとします) がビジネス オブジェクトにアクセスできることは理解していますが、アプリケーションが常に Web アプリのみである場合はどうすればよいでしょうか?

より明確に言うと:

いつ使用すべきか SqlDataSource または ObjectDataSource?

選択の動機はどのように与えられるのでしょうか?

Answer 1

SQLDataSourceのみを持つことは、デモ、プロトタイプ、または簡単なハックであれば、完全に有効です。速く、簡単で、機能し、必要な結果が得られます。

ただし、アプリが長期的に設計および構築され、物事（要件、顧客の要望、最終的にはデータベーススキーマ）が変更される可能性があると予想される場合は、適切な＆quot;ビジネス＆quot;レイヤー-ビジネスオブジェクトをオブジェクトとしてモデル化し、基礎となるデータベースからそれらのビジネスオブジェクトへのマッピングを提供します。

ことわざにもあるように、もう1つのインダイレクション（または抽象化）レイヤーにより、コンピューターサイエンスのほとんどすべてを解決できます-ここでも同じことが言えます。

確かに、データベースに直接アクセスできます。最初と最初の反復では、おそらく（またはおそらく）最も速い方法です。しかし、長い目で見れば、アプリが長持ちするように構築されている場合、それは通常、迅速な汚い方法です-維持のコスト、メンテナンスのコスト、変更に必要なコストと労力あなたとあなたの顧客のニーズは急速に成長し、そのquick'n'dirtyソリューションは努力の面ではあまり見栄えがしません。

それで、私のポイントを要約すると：はい、最初は、直接SQLデータソースを使用する方が迅速かつ簡単かもしれません。それが重要なポイントである場合に使用してください。スタイルアプリ。しかし、長い目で見れば、アプリの寿命を見ると、通常、この抽象化レイヤーを追加するためにもう少し（設計とコーディング）の努力を払う価値があります。下のデータベース。

マーク

Answer 2

プロジェクトで使用しているビジネス レイヤーがある場合は、ObjectDataSource を選択するのが自然です。これは多くの ORM に適合し、その多くは追加の利点 (検証、元に戻すなど) を提供します。また、直接 SQL フィールドだけでなく、ビジネス オブジェクトにある他のプロパティやメソッドにもアクセスできます。これは、バインドするときに非常に便利です。これにより、背後に多くのコードを記述する代わりに、マークアップ内のプロパティにバインドするだけで済みます。

この方法を採用する場合、SQLDataSource と ObjectDataSource を混在させると、次にプロジェクトを採用する開発者が混乱する可能性があります。この場合、コードの一貫性を保つために ObjectDataSource を使用します。

ビジネス層がなく、SQL を直接実行している場合は、SQLDataSource を使用してください。私の個人的な好みは、すべての SQL コードがビジネス レイヤーまたはデータ レイヤーにあるべきであり、SQLDataSource をほとんど使用しないためです。

Answer 3

ストアドプロシージャでビジネスレイヤーコードを適用できる場合 SQLDataSourceを使用する方が良い

Answer 4

理論的には、objectdatasourceの方が優れています。しかし、それはすべて、オブジェクトモデルの作成と文書化の程度に依存します。カスタムコードジェネレーター（提供されない）を使用して、すべてのレイヤーを生成する会社を外部委託しました。プロパティの追加やフィールドタイプの変更など、小さな変更を加えることも悪夢であることが判明しました。私は今、彼らがした事実上すべてを廃棄し、彼らが書いたストアドプロシージャを使用しています。

長期的な目標は、市販のモデリングツールを使用してアプリケーションを一から書き直すことです。コードジェネレーター。 objectdatasourceを使用する場合は、柔軟なコードジェネレーターを含む優れたモデリングツールを見つけることを強くお勧めします。