My<cod/>.net
Разделить класс доступа к данным на читателя и писателя или объединить их?
Это может быть на стороне "discussy", но я действительно хотел бы услышать Ваше мнение об этом.
Ранее я часто писал классы доступа к данным, которые обрабатывали как чтение, так и запись, что часто приводило к плохому именованию, например FooIoHandler и т. д. Эмпирическое правило, что классы, которые трудно назвать, вероятно, плохо разработаны, предполагает, что это не очень хорошее решение.
Итак, я недавно начал разделять доступ к данным на FooWriter и FooReader, что приводит к более приятным именам и дает некоторую дополнительную гибкость, но в то же время мне нравится держать его вместе, если классы не большие.
Является ли разделение читателя / писателя лучшим дизайном, или я должен их объединить? Если я должен объединить их, Какого черта я должен назвать класс?
Спасибо /Erik
Теперь я использую Linq для 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 может быть вашим лучшим решением.
Или используйте шаблон типа репозитория с объектом "thingContext", который отвечает за сохранение состояния.
Лично я использую шаблон activeRecord, где логика сохранения запекается в базовый класс, но я оставляю его в пользу шаблона репозитория стиля nHibernate. Допуск на DDD и тестирование вещей без БД очень приятно иметь в ситуации типа фреймворка, где моя бизнес-логика теперь набирает обороты для нового UI.