私は、ASP.NETアプリケーションのデータアクセスを考えています。クライアントデータセットで多くのWindowsアプリケーションを使用する企業から来て、データを処理するためのデータセットアプローチには自然な傾向があります。ASP.NETデータセットとビジネスオブジェクト/ ORM
私はビジネスオブジェクトのアプローチにもっと関心があり、セッションでデータセットをキャッシュしてから更新を適用するという考えは嫌いです。
誰にも、両方のアプローチの長所と短所を伝えるための経験や助けがありますか？
あなたのアプリでデータレイヤーを設計することは賢明です。 ASP.NETアプリケーションでは、これは標準化し、データアクセスを大幅に簡素化するのに役立ちます。 は、ObjectDataSourcesの作成方法と使い方を学ぶ必要がありますが、これは非常に簡単です。
データアクセス層（別のプロジェクト/ DLLを使用して構築）のもう1つの利点は、ユニットテストをはるかに簡単にすることです。また、ビジネスレイヤーを構築して、データの処理の多くを行うことをお勧めします（ビジネスレイヤーは、ObjectDataSourceをDALからUIコードに引き渡す責任があります）。これにより、ビジネスロジックをカプセル化できるだけでなく、コードのテスト容易性も向上します。
あなたはではありませんセッションでDataSets（またはDALオブジェクト）をキャッシングしたいと考えています！一意のID（またはその他の主キー仕様）を介してレコードの変更が行われ、変更がDALに直接送られるようにWebアプリケーションを構築します。 を徹底的にキャッシュする場合は、は、アプリケーションのスケーラビリティを低下させます。
更新：このスレッドの他のユーザーは、ORMの使用を促進しています。私は以前にhereとhereの輪郭を描いてきた理由で、本格的なORMを採用することに注意します。 I doは、DataSetsを避けることが賢明であることに同意します。私自身の仕事では、私のObjectDataSources（私のDALの設計のために些細なことです）を埋めるためにDataReadersを広範囲に使用し、非常に効率的であることがわかります。
Microsoftの指示に従うなら、間違いなくLINQ（ORM）対DataSetsの傾向です。 DataSetが（ASP.NET 1.0）になったとき、LINQは可能でもありませんでした。 LINQを使用すると、型の安全性と組み込み関数をデータベースから作成/更新/削除することができます。
マイクロソフトでは、LINQ to DataSetによって移行を簡単にしようとしました。
DataSetsは、DataReadersなどの他のADO.NETオブジェクトに比べても非常に非効率的です。私はあなたが言っていることに基づいてBO/ORMルートに向かって行くことをお勧めします。
DataSetオブジェクトを大量に使用していた既存のASPアプリケーションを大きく更新しようとしています。私は痛みを楽しみにしていませんが、私はBOルートを下ることを主張しようとしています。データセットを今作ろうと思っただけで、私は汗を流してしまいました。
私はLINQルートを下り、軽量のエンティティオブジェクトを使用するつもりだと思います。
私が働く会社でも、ビジネス層がある間にもDataSetsを大量に使用しています。 BLは主にDBからデータセットをロードします。
私は個人的にこのアプローチを嫌います。ロード後/セーブする前にデータセットを直接変更して、ここやそこで必要なものをすぐに満たすこともできます。私にとってはビジネスオブジェクトというアイデアには本当に違反していますが、それはどのように行われているのでしょうか。
ORMフレームワークは、特に、類似のボタンや操作を持つ多くのビューを持つエンタープライズアプリケーションでは、かなりの時間を節約できます。
しかし、コントロールを失うことも簡単です。その時点からゆっくりと混乱に陥るでしょう。
どちらのオプションも適切なケースで使用すると効果的です。それらを混ぜ合わせないでください。それを一方的に行い、それに従ってください。
Mark Brittinghamの答えは、2段階アプリケーションでは正確です。しかし、もし私がサービス層を使いたいのであれば。 DataSetsはシリアライズ可能です。型付きデータセットは、独自のオブジェクトを手作業でコーディングする時間を節約します。型付きデータセットは拡張可能です。エンティティへのLinqはパフォーマンスの問題を抱えており、SQLへのLinqは現在死んでいる。 Linq to DataSetは常にオプションです。
私は型付きデータセットと多層アーキテクチャを使用して時間を節約し、コードを整理します。私は手でコード化されたBOを試しました。余分な時間とメンテナンス時間はそれに値するものではありません。
DataSetはプラットフォーム固有です。 SOAが非常に未成熟であった.NET 1.0日でDataSetsが作成されました。 SOAのコンテキストではアンチパターンになっています。コード臭よりもコード臭の方が多いそれらを使用しないでください。 –
Rik - 私のポストのリンクをたどって、LINQの反対意見を得ることができます。あなたがそれを採用しても、発生する可能性のある問題を認識する必要があります。 –