architecture - 将数据访问类拆分为读取器和写入器或将它们组合起来？

Question

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

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

因此，我最近开始将数据访问拆分为 FooWriter 和 FooReader，这会产生更好的名称并提供一些额外的灵活性，但同时我喜欢将它们放在一起，如果类不是很大的话。

读者/作者分离是更好的设计，还是应该将它们结合起来？如果我应该将它们结合起来，我到底应该给这个类起什么名字？

谢谢/埃里克

Answer 1

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

就个人而言，我使用 activeRecord 模式，其中保存逻辑被烘焙到基类中，但我将其保留为支持 nHibernate 样式存储库模式。在框架类型的情况下，允许 DDD 和在没有 db 的情况下进行测试非常好，我的业务逻辑现在正在为新的 UI 获得牵引力。

Answer 2

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

这对于需要作为同一事务的一部分执行读取和写入的数据访问也是有意义的。如果你把班级分开，那会去哪里？

Answer 3

忽略 ORM（不是因为我支持或反对它）我会让他们留在同一个班级。它们都是单一责任的两个方面，将它们分开只会让你看到两个地方，我真的想不出你想要这样做的充分理由。

Answer 4

读取和写入后端存储的东西可以称为数据访问器、ReaderWriter、IO 或 Store。

那么其中之一如何：

• FooDataAccessor
• FooAccessor
• FooReaderWriter
• FooRW
• FooIO
• FooStore
• FooStorage

Answer 5

当给出选择时，我通常将读者子类化以创建作者。