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

Question

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

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

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

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

谢谢/埃里克

Answer 1

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

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