Eri*_*ebo 5 architecture oop data-access
这可能是在“讨论”方面，但我真的很想听听您对此的看法。
以前我经常编写处理读取和写入的数据访问类，这经常导致糟糕的命名，如 FooIoHandler 等。 难以命名的类可能设计不佳的经验表明这不是一个好的解决方案。
所以，我最近开始将数据访问拆分为 FooWriter 和 FooReader，这会导致更好的名称并提供一些额外的灵活性，但同时我有点喜欢将它们放在一起，如果类不是很大的话。
读写器分离是更好的设计，还是应该将它们结合起来？如果我应该将它们组合起来，我到底应该给这个类命名什么？
谢谢/埃里克
ORM 可能是您最好的解决方案。
或者使用存储库类型模式，以及负责状态持久性的“thingContext”对象。
就我个人而言，我使用 activeRecord 模式，其中保存逻辑被烘焙到基类中，但我保留它以支持 nHibernate 样式存储库模式。在框架类型的情况下，允许 DDD 和在没有数据库的情况下进行测试是非常好的，在这种情况下，我的业务逻辑现在正在获得新 UI 的吸引力。