これは「議論」の側にあるかもしれませんが、これについてのあなたの意見を本当に聞きたいです.
以前は、読み込みと書き込みの両方を処理するデータ アクセス クラスを作成することがよくありましたが、これはしばしば FooIoHandler などの不適切な名前付けにつながりました。
それで、私は最近、データアクセスを FooWriter と FooReader に分割し始めました。これにより、より適切な名前が付けられ、柔軟性が追加されますが、同時に、クラスがそれほど大きくない場合は、それらをまとめておくのが好きです。
リーダー/ライターの分離はより良い設計ですか、それともそれらを組み合わせる必要がありますか? それらを組み合わせる必要がある場合、クラスに名前を付ける必要がありますか？
ありがとう/エリック
ORM が最適なソリューションかもしれません。
または、状態の永続性を担当する「thingContext」オブジェクトを使用して、リポジトリ タイプのパターンを使用します。
個人的には、保存ロジックが基本クラスに組み込まれている activeRecord パターンを使用していますが、nHibernate スタイルのリポジトリ パターンを優先して残しています。私のビジネスロジックが新しいUIの牽引力を獲得しているフレームワークタイプの状況では、DBなしでDDDとテストを行うことができるのは非常に良いことです。
現在、Linq to Sql を使用しています。これで問題は完全に解決します。
ただし、そのオプション (または同様の ORM ツール) がない場合は、読み取り/書き込みメソッドを分離する理由がわかりません。クラスが追加され、データ アクセスが複雑になるだけです。私は常に次のように設計しています。
使用例:
Car car = new Car();
car.Manufacturer = "Toyota"
car.Model = "Camry"
car.Year = 2006;
car.CarID = CarDB.InsertCar(car)
car.OwnerID = 2;
CarDB.UpdateCar(car);
これは、同じトランザクションの一部として読み取りと書き込みの両方を実行する必要があるデータ アクセスにも意味があります。クラスを分割すると、それはどこに行きますか?
ORM を無視する (私がそれに賛成か反対かという理由ではありません) 私はそれらを同じクラスに保ちます。それらは両方とも 1 つの責任の側面であり、それらを分離すると、2 つの場所に目を向けることになり、それを行う正当な理由が思いつきません。
バックエンド ストアに対して読み取りと書き込みを行うものは、データ アクセサー、ReaderWriter、IO、または Store と呼ばれることがあります。
では、次のいずれかはどうでしょうか。
選択肢が与えられた場合、私は通常、リーダーをサブクラス化してライターを作成します。