代码之家  ›  专栏  ›  技术社区  ›  Patrick

类应该支持接口,但这需要以一种侵入式的方式向类添加逻辑。我们能阻止吗?

  •  2
  • Patrick  · 技术社区  · 14 年前

    我有一个C++应用程序,它从数据库中加载大量数据,然后执行对该数据的算法(这些算法是CPU和数据密集型的,这是我将所有数据加载到手之前的方法),然后将所有已被更改的数据保存回数据库。

    数据库部分与应用程序的其余部分很好地分离。实际上,应用程序不需要知道数据从何而来。应用程序甚至可以在文件上启动(在这种情况下,单独的文件模块将文件加载到应用程序中,最后将所有数据保存回文件)。

    • 数据库层只想将更改的实例保存回数据库(而不是完整的数据),因此它需要知道应用程序更改了什么。
    • 另一方面,应用程序不需要知道数据来自何处,因此它不希望感觉被迫为其数据的每个实例保持更改状态。

    为了使我的应用程序及其数据结构尽可能地与加载和保存数据的层(可以是数据库,也可以是文件)分离,我不想用启动后是否更改实例的信息污染应用程序数据结构。

    但要使数据库层尽可能高效,需要一种方法来确定应用程序更改了哪些数据。

    向应用程序数据结构中添加观察者也不是一个选项,因为应用程序算法中的性能非常重要(在所有观察者上循环和调用虚拟函数可能会导致算法中的一个重要性能瓶颈)。

    还有别的办法吗?或者,如果我不想以一种侵入性的方式向应用程序类添加逻辑,我是不是太“模块化”了?在这些情况下,务实是不是更好?

    ORM工具如何解决这个问题?它们是强制应用程序类保持某种更改状态,还是强制类具有更改观察者?

    1 回复  |  直到 14 年前
        1
  •  1
  •   Steve Jessop    14 年前

    如果你不能复制数据并进行比较,那么很明显,你需要在某个地方记录下发生的变化。那么,问题是如何更新这些记录。

    ORM工具可以(如果他们愿意)通过在对象中保留标志来解决这个问题,比如说数据是否已经更改,如果更改了又是什么。听起来好像是在为应用程序提供原始数据结构,而不是使用封装得很好的变体来更新标志的对象。

    所以ORM通常不需要应用程序跟踪任何细节的变化。应用程序通常必须说明要保存哪些对象,但是ORM然后计算出为了保存哪些对象需要持久化到DB,并可能在那里应用优化。

    我想这意味着,用你的话说,ORM在某种松散的意义上给数据结构添加了观察者。它不是一个外部观察者,而是一个知道如何改变自身的对象,但是当然,记录改变的东西会有一些开销。

    然后你会有两种基本情况:

    • 我在一个非常大的对象集合上循环,有条件地对其中的一些对象进行单个更改。使用“慢速”变异器,以简化应用程序。
    • 我对同一个对象做了很多不同的更改,我非常关心访问器的性能。使用“快速”变异器,它可能直接在数据中公开一些数组。您可以通过了解更多关于持久性模型的信息来获得性能。

    菲尔卡尔顿