这可能是在"讨论"方面，但我真的很想听听我们对此的看法。

以前，我经常编写处理读取和写入的数据访问类，这常常导致命名不佳，例如FooIoHandler等。根据经验法则，很难命名的类可能设计不良，这表明这不是一个好的解决方案。

因此，我最近开始将数据访问权限划分为FooWriter和FooReader，这将导致名称更好，并提供了一些额外的灵活性，但同时，如果类不是很大的话，我有点喜欢将它们保持在一起。

读者/作家分开是更好的设计，还是应该将它们结合起来？如果我应该将它们结合起来，我该给班级命名什么呢？

谢谢/ Erik

解决方案

回答

ORM可能是我们最好的解决方案。
或者使用存储库类型模式，以及负责状态持久性的" thingContext"对象。

就个人而言，我使用activeRecord模式，将保存逻辑烘焙到基类中，但我将其保留为nHibernate样式存储库模式。在框架类型的情况下，允许DDD和在没有数据库的情况下进行测试非常好，在这种情况下，我的业务逻辑现在正吸引着新UI的注意。

回答

我现在正在使用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(不是因为我支持或者反对它)，我会将它们放在同一个类中。它们都是单一职责的各个方面，将它们分开会使我们在两个我无法真正想到要这样做的理由的地方查看。

回答

当给出选择时，我通常将读者归类为创作者。