Разделить класс доступа к данным на читателя и писателя или объединить их?

Question

Это может быть на "дискуссионной" стороне, но мне бы очень хотелось услышать ваше мнение об этом.

Ранее я часто писал классы доступа к данным, которые обрабатывали как чтение, так и запись, что часто приводило к плохому именованию, например, FooIoHandler и т. Д. Эмпирическое правило о том, что трудно назвать классы, вероятно, плохо разработаны, предполагает, что это не хорошее решение.

Итак, я недавно начал разделять доступ к данным на FooWriter и FooReader, что приводит к более привлекательным именам и дает некоторую дополнительную гибкость, но в то же время мне нравится сохранять их вместе, если классы не слишком большие.

Является ли разделение читатель / писатель лучшим дизайном, или я должен их объединить? Если я должен объединить их, какого черта я должен назвать класс?

Спасибо / Эрик

Answer 1

Я сейчас использую Linq to Sql. Это полностью решает проблему.

Однако, если у вас нет этой опции (или какого-либо подобного инструмента ORM), я не вижу причин для разделения методов чтения / записи. Это просто добавляет больше классов и усложняет доступ к данным. Я всегда проектировал это следующим образом:

1. Компонент / Бизнес-объект: Автомобиль
2. Доступ к данным, содержащий статические методы чтения и записи: CarDB

Пример использования:

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

Это также имеет смысл для доступа к данным, когда чтение и запись должны выполняться как часть одной и той же транзакции. Если вы разделите классы, куда это пойдет?

Answer 2

Игнорируя ORM (не потому, что я за или против), я бы держал их в одном классе. Они оба являются аспектами единой ответственности, и разделение их просто заставляет вас смотреть в двух местах, где я не могу придумать вескую причину, по которой вы захотите это сделать.

Answer 3

ORM может быть вашим лучшим решением.
Или используйте шаблон типа репозитория с объектом thingContext, который отвечает за сохранение состояния.

Лично я использую шаблон activeRecord, где логика сохранения запекается в базовом классе, но я оставляю его в пользу шаблона хранилища в стиле nHibernate. Разрешение на DDD и тестирование без БД очень приятно иметь в ситуации с типом фреймворка, где моя бизнес-логика набирает обороты для нового пользовательского интерфейса.

Answer 4

То, что читает и пишет в бэкэнд-хранилище, может называться средством доступа к данным, или ReaderWriter, или IO, или Store.

Так как насчет одного из:

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

Answer 5

Когда мне предоставляется выбор, я обычно делю подкласс читателя на создание писателя.