Aufteilung der Datenzugriffsklasse in Leser und Schreiber oder Kombination beider?

Question

Das ist vielleicht etwas "diskussionsbedürftig", aber ich würde wirklich gerne Ihre Meinung dazu hören.

Früher habe ich oft Datenzugriffsklassen geschrieben, die sowohl lesen als auch schreiben konnten, was oft zu einer schlechten Namensgebung führte, wie FooIoHandler usw. Die Faustregel, dass Klassen, die schwer zu benennen sind, wahrscheinlich schlecht konzipiert sind, legt nahe, dass dies keine gute Lösung ist.

Daher habe ich vor kurzem damit begonnen, den Datenzugriff in FooWriter und FooReader aufzuteilen, was zu schöneren Namen führt und zusätzliche Flexibilität bietet, aber gleichzeitig mag ich es irgendwie, wenn die Klassen nicht zu groß sind.

Ist eine Trennung von Lese- und Schreibfunktion besser, oder sollte ich beides kombinieren? Wenn ich sie kombinieren sollte, wie zum Teufel sollte ich die Klasse nennen?

Danke /Erik

Answer 1

ORM könnte die beste Lösung für Sie sein.
Oder Sie verwenden ein Repository-Muster mit einem "thingContext"-Objekt, das für die Persistenz des Zustands verantwortlich ist.

Ich persönlich verwende das activeRecord-Muster, bei dem die Speicherlogik in eine Basisklasse eingebettet ist, aber ich verlasse es zugunsten eines Repository-Musters im Stil von nHibernate. Die Erlaubnis für DDD und das Testen von Dingen ohne eine Datenbank ist sehr schön, in einem Rahmen-Typ-Situation zu haben, wo meine Business-Logik jetzt gewinnt Traktion für eine neue UI.

Answer 2

Ich verwende jetzt Linq to Sql. Damit ist das Problem vollständig gelöst.

Wenn Sie jedoch nicht über diese Option (oder ein ähnliches ORM-Tool) verfügen, sehe ich keinen Grund für die Trennung von Lese- und Schreibmethoden. Dadurch werden nur weitere Klassen hinzugefügt und der Datenzugriff verkompliziert. Ich habe es immer wie folgt gestaltet:

1. Komponente/Business-Objekt: Auto
2. Datenzugriff, der statische Lese- und Schreibmethoden enthält: CarDB

Beispiel für die Verwendung:

Car car = new Car();
car.Manufacturer = "Toyota"
car.Model = "Camry"
car.Year = 2006;
car.CarID = CarDB.InsertCar(car)
car.OwnerID = 2;
CarDB.UpdateCar(car);

Dies ist auch für den Datenzugriff sinnvoll, bei dem sowohl das Lesen als auch das Schreiben als Teil derselben Transaktion durchgeführt werden müssen. Wenn Sie die Klassen aufteilen, wohin würde das führen?

Answer 3

Abgesehen von ORM (nicht weil ich dafür oder dagegen bin) würde ich sie in der gleichen Klasse belassen. Sie sind beide Facetten einer einzigen Verantwortung, und wenn man sie trennt, sieht man an zwei Stellen nach, und ich kann mir nicht wirklich einen guten Grund vorstellen, warum man das tun sollte.

Answer 4

Etwas, das in einem Backend-Speicher liest und schreibt, könnte als Datenzugriff oder ReaderWriter oder IO oder Speicher bezeichnet werden.

Wie wäre es also mit einem von:

• FooDataAccessor
• FooAccessor
• FooReaderWriter
• FooRW
• FooIO
• FooStore
• FooStorage

Answer 5

Wenn ich die Wahl habe, unterstelle ich in der Regel den Leser, um den Schreiber zu erstellen.