Diviser la classe d'accès aux données en lecteur et écrivain ou les combiner ?

Question

C'est peut-être du côté « discussion », mais j'aimerais vraiment connaître votre point de vue à ce sujet.

Auparavant, j'avais souvent écrit des classes d'accès aux données qui géraient à la fois la lecture et l'écriture, ce qui conduisait souvent à une mauvaise dénomination, comme FooIoHandler, etc.La règle générale selon laquelle les classes difficiles à nommer sont probablement mal conçues suggère que ce n'est pas une bonne solution.

Ainsi, j'ai récemment commencé à diviser l'accès aux données entre FooWriter et FooReader, ce qui conduit à des noms plus jolis et donne une flexibilité supplémentaire, mais en même temps, j'aime bien le garder ensemble, si les classes ne sont pas trop grandes.

Une séparation lecteur/écrivain est-elle une meilleure conception, ou dois-je les combiner ?Si je devais les combiner, comment devrais-je nommer la classe ?

Merci /Erik

Answer 1

ORM pourrait être votre meilleure solution.
Ou utilisez un modèle de type de référentiel, avec un objet "thingContext" responsable de la persistance de l'état.

Personnellement, j'utilise le modèle activeRecord, où la logique de sauvegarde est intégrée dans une classe de base, mais je le laisse au profit d'un modèle de référentiel de style nHibernate.L'allocation pour DDD et tester des choses sans base de données est très agréable dans une situation de type framework, où ma logique métier gagne maintenant du terrain pour une nouvelle interface utilisateur.

Answer 2

J'utilise maintenant Linq to Sql.Cela résout entièrement le problème.

Cependant, si vous ne disposez pas de cette option (ou d'un outil ORM similaire), je ne vois aucune raison de séparer les méthodes Lecture/Ecriture.Cela ajoute simplement plus de classes et complique l'accès aux données.Je l'ai toujours conçu comme suit :

1. Composant/Objet métier :Voiture
2. Accès aux données, contenant des méthodes statiques de lecture et d'écriture :CarDB

Exemple d'utilisation :

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

Cela est également logique pour l'accès aux données où les lectures et les écritures doivent être effectuées dans le cadre de la même transaction.Si vous scindiez les cours, où cela irait-il ?

Answer 3

En ignorant ORM (pas parce que je suis pour ou contre), je les garderais dans la même classe.Ce sont deux facettes d’une même responsabilité et les séparer vous amène à regarder à deux endroits où je ne vois pas vraiment de bonne raison pour laquelle vous voudriez faire cela.

Answer 4

Quelque chose qui lit et écrit dans un magasin principal peut être appelé un accesseur de données, ou ReaderWriter, ou IO, ou Store.

Alors que diriez-vous de l'un des :

• FooDataAccessor
• FooAccesseur
• FooReaderWriter
• FooRW
• FooIO
• FooStore
• FooStorage

Answer 5

Lorsqu'on me donne le choix, je sous-classe généralement le lecteur pour créer l'écrivain.