将数据访问类拆分为读写器还是将它们组合在一起?

ORM可能是您最好的解决方案。
或者使用存储库类型模式,使用负责状态持久性的“thingContext”对象。

就我个人而言,我使用ActiveRecord模式,其中保存逻辑被烘焙到一个基类中,但我将其留给一个NHibernate风格的存储库模式。在框架类型的情况下,允许DDD和测试没有DB的东西是非常好的,在这种情况下,我的业务逻辑现在正获得新UI的吸引力。

我现在使用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);

这对于需要作为同一事务的一部分执行读和写操作的数据访问也是有意义的。如果你把课分开,那会去哪里?

忽略ORM(不是因为我支持或反对它),我会把它们放在同一个类中。它们都是单一责任的一个方面,分开它们只会让你看到两个地方,我真的想不出一个好的理由让你想这样做。

读写到后端存储的内容可以称为数据访问器、读写器、IO或存储。

那么,以下哪一个呢:

• FooDATAccess
• 访问器
• 女作家
• 福罗
• 福伊奥
• 鞋店
• 存储库

当给出选择时,我通常将阅读器子类化以创建编写器。