Разделить класс доступа к данным на читателя и писателя или объединить их?
Это может быть "дискуссионная" сторона, но мне бы очень хотелось услышать ваше мнение по этому поводу.
Раньше я часто писал классы доступа к данным, которые обрабатывали и чтение, и запись, что часто приводило к плохому именованию, например FooIoHandler и т. д. Эмпирическое правило, что классы, которые трудно назвать, вероятно, плохо спроектированы, предполагает, что это не очень хорошее решение.
Итак, я недавно начал разделять доступ к данным на FooWriter и FooReader, что приводит к более приятным именам и дает некоторую дополнительную гибкость, но в то же время мне нравится держать их вместе, если классы не слишком большие.
Лучше ли разделить читателя и писателя, или я должен их объединить? Если я должен объединить их, как, черт возьми, я должен назвать класс?
Спасибо / Эрик
Ответы 5
ORM может быть вашим лучшим решением. Или используйте шаблон типа репозиторий с объектом «thingContext», который отвечает за сохранение состояния.
Лично я использую шаблон activeRecord, в котором логика сохранения встроена в базовый класс, но я оставляю его в пользу шаблона репозитория в стиле nHibernate. Допуск на DDD и тестирование без базы данных очень хорошо иметь в ситуации типа фреймворка, когда моя бизнес-логика теперь набирает обороты для нового пользовательского интерфейса.
Теперь я использую Linq to Sql. Это полностью решает проблему.
Однако, если у вас нет этой опции (или какого-либо подобного инструмента ORM), я не вижу причин для разделения методов чтения / записи. Он просто добавляет больше классов и усложняет доступ к данным. Я всегда проектировал его следующим образом:
- Компонент / Бизнес-объект: Автомобиль
- Доступ к данным, содержащий статические методы чтения и записи: 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);
Это также имеет смысл для доступа к данным, когда и чтение, и запись должны выполняться как часть одной транзакции. Если вы разделите классы, куда это денется?
Игнорируя ORM (не потому, что я либо за, либо против), я бы оставил их в одном классе. Они оба являются гранями единой ответственности, и разделение их просто заставляет вас смотреть в двух местах, где я не могу придумать вескую причину, по которой вы бы захотели это сделать.
Когда мне предоставляется выбор, я обычно подклассифицирую читателя для создания писателя.
То, что читает и записывает в внутреннее хранилище, можно назвать средством доступа к данным, или ReaderWriter, или IO, или Store.
Итак, как насчет одного из:
- FooDataAccessor
- FooAccessor
- FooReaderWriter
- FooRW
- FooIO
- FooStore
- FooStorage
Спасибо за другие полезные имена. «Классы доступа к данным» не являются синонимами «База данных». :)