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

Question

Возможно, это из области «обсуждений», но мне бы очень хотелось услышать ваше мнение по этому поводу.

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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 3

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

Answer 4

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

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

• Фудатаакцессор
• Фуаксессор
• FooReaderПисатель
• ФуРВ
• ФуИО
• FooStore
• FooStorage

Answer 5

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