【问题标题】:Split data access class into reader and writer or combine them?将数据访问类拆分为读取器和写入器或将它们组合起来?
【发布时间】:2010-09-06 23:19:14
【问题描述】:

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

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

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

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

谢谢/埃里克

【问题讨论】:

    标签: architecture oop data-access


    【解决方案1】:

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

    那么以下之一如何:

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

    【讨论】:

    • 感谢其他一些有用的名字。 “数据访问类”不是“数据库”的同义词。 :)
    • 为什么没有 FooRepository ?
    【解决方案2】:

    当有选择时,我通常将读取器子类化以创建写入器。

    【讨论】:

      【解决方案3】:

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

      【讨论】:

        【解决方案4】:

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

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

        【讨论】:

          【解决方案5】:

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

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

          【讨论】:

            猜你喜欢
            • 1970-01-01
            • 2019-01-14
            • 2021-07-06
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 2023-01-17
            • 2017-09-01
            • 1970-01-01
            相关资源
            最近更新 更多