私はDAOの数百万の例を見てきました。ほとんどの場合、リストを返すいくつかのメソッド（例：List getCustomers（））を使用して、単一エンティティの基本CRUD操作を実装しています。複数のエンティティを更新するメソッドは、通常DAOの一部ではありませんか？
しかし、void update（List）のように複数のエンティティを更新、削除、または作成するメソッドがある例は見たことがありません。
複数のエンティティを更新するメソッドは、通常はDAOの一部ではないか、あまり例ではあまり使用されませんか？私はいくつかのバッチを挿入する必要があり、myDAO.create（）を100回呼び出すことは非常に効率的ではないという要件を持っています。
私は先に進む前に何かを見逃していないことを確認したいと思います。
例では頻繁に使用しないと思います。私のDAOには、単一のエンティティとレコードのコレクションの両方にアクセスし、作成し、更新するメソッドがあります。
バッチ更新は、通常、データベースベンダーが提供するツールを使用して行われます。
私が見たDAOには、通常、作成/更新/削除のためのメソッドがありませんので、リストを取得することに同意しますが、理由がありません。
私を短くするひとつの考えは、DAOは私がそれらを書くときにトランザクションを所有していないということです。彼らは、彼らがより大きな作業単位のどこにいるのかを決して知ることはできません。それがサービスの役割です。
私のアドバイスは、DAOを単独のままにして、別のサービスレイヤにバッチ操作を所有させることです。サービスはトランザクションロジックを所有しています。また、大規模な更新プログラムを「チャンク」するロジックを組み込むのにも適しています。これにより、バッチをチェックポイントし、ロールバックログのサイズを管理しやすくします。
void update(List)は、void update(Item)と同じになります。Listは、複数のアイテムを更新します。そうでない場合は、非常に具体的な理由がない限りそうでなければなりません。メソッドを呼び出すオーバーヘッドは、同じことをしても問題ではありません。
例えば、update(Item)を1000回と呼び出すことと対してupdate(List)を呼び出すことは、update(Item)と同じことを1000回だけ行うと、パフォーマンスの差はほとんどありません。
更新（リスト）メソッドを実装する場合、リスト内の各アイテムに対して更新（アイテム）を実行する必要はありません。私は私のデータベース層が提供するバッチ更新メソッドを使用します。 1000回の別々の更新のオーバーヘッドは、そのレベルでの1回のバッチ更新よりもはるかに高い可能性があります。 – Boden
ええと、それは私のDAOには、適切なバッチ更新を実装できるようにリストを取ることができるメソッドを持っている必要があるようです。私はまだ私のサービス方法でバッチを分割して、それをすべて同じトランザクションの下で実行させることができますか？ – Boden
いいえ、私はDAOがまだ単一のオブジェクトインスタンスを取ることを提案しており、サービスはループ内でDAOを呼び出します（または、あなたが "チャンク"している場合はループします）。サービス方法は、トランザクションを所有する単一の作業単位になります。サービスはまた、トランザクションをバッチしてネットワークトラフィックを削減することもあります。 – duffymo
どうしたらうまくいくのですか？たとえば、Jdbcを使用していた場合、サービスではexecuteBatchを使用できなくなります...基本的には定期的に更新が行われます。 – Boden