データアクセス層の推奨データ構造

Question

DBにDataAccess層を構築していますが、コレクションの受け渡しにどのようなデータ構造を使用することをお勧めしますか？

Answer 1

私は、dbテーブルにマップされたデータアクセスオブジェクトのリストを使用します。

Answer 2

私はどの言語を使用しているのかよく分かりませんが、一般的にシンプルさと拡張性のトレードオフがあります。

データセットを直接返すと、データベース固有のクラスに結合されました。これは拡張の余地がほとんどありません。ファイルや他の種類のデータソースへのアクセスを許可するとどうなりますか？しかし、それはまた非常に簡単です。これはレコードセットパターンであり、C＃/ VBではこれに対する組み込みサポートが多数提供されています。 GUIレイヤーはレコードセットにアクセスし、データを簡単に操作できます。これは簡単なアプリケーションでうまくいきます。

一方、データセットをカスタムオブジェクトにラップし、ゲートウェイメソッドを提供できます（ゲートウェイパターンhttp://martinfowler.com/eaaCatalog/gateway.htmlを参照）。この方法はより複雑ですが、より多くの拡張性を提供します。大規模なアプリケーションでは、ビジネスロジック、データロジック、およびGUIロジックを分離する必要がある場合、これはより堅牢な方法です。

大規模なエンタープライズアプリケーションの場合は、オブジェクトリレーショナルマッピングツール（ORM）を使用して調べることができます。 Javaオブジェクトを自動的にデータベーステーブルにマップするのに役立ちます。彼らは痛ましいSQLの詳細を隠しています。 Springなどのフレームワークは、ORMの優れたサポートを提供します。

Answer 3

私はビジネスロジックからDAOを切断できるように、オブジェクトの配列を使用する傾向があります。

たとえば、DAOにデータをデータセットとして保存し、更新を行う前にデータベースに簡単に追加できるため、情報を渡して変更操作を行うことができます。彼らが一度に行うことができる変更をコミットしたい。

私は、データベース内で何を変更する必要があるのか​​を判断するのが難しくなるため、ユーザーは構造自体を追加/変更できないことを好みます。

最初に配列を返すことで、データベース内の内容を表示できます。

次に、プレゼンテーションレイヤーが変更されると、コントローラによってDAOを更新できます。 DAOをデータセットから別のものに変更することができるので、システム全体がより柔軟になり、アプリケーションの残りの部分は気にしません。

Answer 4

最も一般的なのは2つの選択肢があります。

ResultSetを表示する最初の方法は、Mapのリストで、各MapはResultSetの行を表します。キーは、FROM句に列挙された列です。値はデータベース値です。

ResultSetを参照する2つ目の方法は、List of Mapのように、各ListはResultSetの列を表します。 Mapキーは、FROM句に列挙されている列です。値はデータベース値のリストです。

もしあなたが本格的なORMをしたくないのであれば、あなたは長い道のりを歩むことができます。