将数据访问类拆分为读取器和写入器还是将它们合并？
这可能属于“讨论”方面，但我真的很想听听您对此的看法。
以前，我经常编写处理读取和写入的数据访问类，这通常会导致命名不当，例如 FooIoHandler 等。根据经验，难以命名的类可能设计得很糟糕，这表明这不是一个好的解决方案。
因此，我最近开始将数据访问拆分为 FooWriter 和 FooReader，这会产生更好的名称并提供一些额外的灵活性，但同时，如果类不太大，我有点喜欢将它们保留在一起。
读写器分离是更好的设计，还是应该将它们结合起来？ 如果我要把它们结合起来，我到底应该给这个类起什么名字呢？
谢谢/埃里克
This might be on the "discussy" side, but I would really like to hear your view on this.
Previously I have often written data access classes that handled both reading and writing, which often led to poor naming, like FooIoHandler etc. The rule of thumb that classes that are hard to name probably are poorly designed suggests that this is not a good solution.
So, I have recently started splitting the data access into FooWriter and FooReader, which leads to nicer names and gives some additional flexibility, but at the same time I kind of like keeping it together, if the classes are not to big.
Is a reader/writer separation a better design, or should I combine them? If I should combine them, what the heck should I name the class?
Thanks /Erik
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
当有选择时，我通常会子类化 reader 来创建 writer。
When given the choice I generally subclass the reader to create the writer.
读取和写入后端存储的东西可以称为数据访问器、ReaderWriter、IO 或 Store。
那么以下之一怎么样：
Something that reads and writes to a backend store could be called a data accessor, or ReaderWriter, or IO, or Store.
So how about one of:
忽略 ORM（不是因为我支持或反对它）我会将它们保留在同一类中。 它们都是单一责任的两个方面，将它们分开只会让你看两个地方，我真的想不出你想要这样做的好理由。
Ignoring ORM (not because I'm either for or against it) I would keep them in the same class. They are both facets of a single responsibility and separating them just makes you look in two places where I can't really think of a good reason you would want to do that.
我现在正在使用 Linq to Sql。 这完全解决了问题。
但是，如果您没有该选项（或某些类似的 ORM 工具），我认为没有任何理由将读/写方法分开。 它只是添加了更多的类并使数据访问变得复杂。 我总是将其设计如下：
示例用法：
这对于需要将读取和写入作为同一事务的一部分执行的数据访问也很有意义。 如果你把班级分开，那会去哪里？
I am now using Linq to Sql. This solves the problem entirely.
However if you do not have that option (or some similar ORM tool), I don't see any reason to separate Read/Write methods. It just adds more classes and complicates data access. I have always designed it as follows:
Example Usage:
This also makes sense for data access where both Reads and Write need to be performed as part of the same transaction. If you split up the classes, where would that go?
ORM 可能是您最好的解决方案。
或者使用存储库类型模式，以及负责状态持久性的“thingContext”对象。
就我个人而言，我使用 activeRecord 模式，其中保存逻辑被烘焙到基类中，但我保留它以支持 nHibernate 样式存储库模式。 在框架类型的情况下，允许 DDD 和在没有数据库的情况下进行测试是非常好的，在这种情况下，我的业务逻辑现在正在获得新 UI 的吸引力。
ORM might be your best solution.
Or use a repository type pattern, with a "thingContext" object that is responsible for state persistence.
Personally, I use the activeRecord pattern, where save logic is baked into a base class, but I'm leaving it in favor of an nHibernate style repository pattern. The allowance for DDD and testing things without a db is very nice to have in a framework type situation, where my business logic is now gaining traction for a new UI.