design-patterns - 削除クエリのロジックを配置する場所

Question

モデル ロジックを「エンティティ」、「マッパー」、「サービス」に分けました。データベースの削除クエリをマッパーに入れることから始めましたが、考えれば考えるほどサービスのように感じます。

よくわかりませんが、私が知らない他のレイヤーがもっと理にかなっているかもしれません。

Answer 1

データベースに対する物理的な変更のロジックを正確にどこに配置するかは、設計の詳細に完全に依存します。「マッパー」に UPDATE ステートメントと INSERT ステートメントがある場合、DELETE を持つことは完全に適切です。逆に、彼らがサービスに参加している場合は、そこにいることも完全に適切です。

重要なのは、あなたのソフトウェアが理にかなっているということであり、他の誰かが述べたモデルに準拠しているということではありません。

（ただし、「エンティティ」クラスは物理データベースを認識せず、「マッパー」クラスはdb結果セットをエンティティクラスとの間で変換し、「サービス」クラスはすべての実際のdbコードを含むことを期待していますが、 SELECT と UPDATE から INSERT と DELETE まで。)

Answer 2

はい、サービス層に削除ロジックを配置します。エンティティとマッパー オブジェクトには削除に関する責任はありませんが、サービス レイヤーは完全に適合します。

エンティティがデータベース (Ruby on Rails など) と対話する Active Record などのパターンがありますが、あなたの場合はサービス層に固執します。

Answer 3

私がWebサービスに取り組んだとき、挿入、編集、削除、および選択が可能なORMジェネリッククラスを作成しました。次に、このクラスをサブクラス化します。サブクラスには、データベースのテーブルのフィールドのような属性があります。

私が持っているオブジェクトを削除したい場合は、単に呼び出します（int PHP）：

$object->delete;

オブジェクトを作成してデータベースに追加したい場合は、次を呼び出します。

$object = new ObjectModel($pdo); /// subclass of ORM class (TableName: Object)
$object->name = "name";
$object->age = 15;
$object->save();

また、ORM クラスにはisLoadedキーがあり、save()呼び出すと、insert メソッドまたは update メソッドを呼び出すかどうかがわかります。この場合は挿入します。

このジェネリック クラスは、データベース関連のすべてのメソッドを呼び出す必要があります。