在 JavaScript 中，依赖对象引用来“监听”更改是一种好习惯吗？答案

【问题标题】：In JavaScript, is it a good practice to depend on object references to "listen" for changes?在 JavaScript 中，依赖对象引用来“监听”更改是一种好习惯吗？
【发布时间】：2015-09-21 12:51:56
【问题描述】：

我必须实现一个类似于存储库模式的对象，该对象将维护一个项目列表。仓库看起来像这样：

var repository = {

    data: [],

    getAll: function() {
        return this.data;
    },

    update: function() { ... }
}

回购数据的最终消费者将是某个组件。我正在考虑利用对 repo 数据数组的引用，以便在 DOM 发生变化时更新它：

function ItemList() {
    this.data = repository.getData();

    when (this.data is changed) {
        update the view
    }

    this.userInput = function() {
        repository.update();
    }
}

虽然它感觉很整洁并且据说使用了合法的功能，但这真的是个好主意吗？我应该在存储库中使用观察者/通知吗？

var repository = {
    ...
    onDataChange: function(callback) { ... }
}

您可以在此处找到一个示例（使用 Angular）：http://jsfiddle.net/xen8m148/

【问题讨论】：

标签： javascript design-patterns pass-by-reference anti-patterns

【解决方案1】：

取决于您如何实现绝对非内置的“已更改”=) 通常，如果您想减少虚假处理，发布/订阅模型会更好。如果您不关心浪费的 cpu 周期，那么您可以使用 Object.observe 查看对象更改。

不过，从软件工程的角度来看，您似乎在两个所有者之间共享您的数据，而这 - 而不是您如何监听变化 - 是未来可能更大的问题。

【讨论】：

我怀疑 OP 试图像使用数据存储一样使用 repository。在这种情况下，不存在真正的数据耦合问题，因为存储库实际上并不对数据进行操作，也不依赖于数据。
我从不相信事物就像他们的名字所说的那样，所以：即使它被称为“存储库”，我也不会相信没有人会最终不让它操纵数据本身也在某个时间点。最好事先清楚这些事情（请注意，OP 将其称为存储库模式-like 对象，而不是存储库。这总是令人担忧）
你说得有道理，但我认为这是一个架构问题。如果应用程序是用一个架构建模的，其中“存储库”是用于存储数据的层之一（可能是持久性到磁盘？）而不是其他任何东西，我们希望它不会操纵数据。
如果问题陈述中没有“喜欢”，我同意 =)
想象一下它不称为存储库。 :)

【解决方案2】：

我通常认为，如果您与存储库通信，则不需要发布/订阅模式。假设您的应用程序使用存储库将 CRUD 抽象为系统中所有数据的底层持久机制，那么此存储库实际上是架构的重要组成部分。

如果通信模块不知道彼此的存在，则发布/订阅模式很有用。如果一个模块/对象试图与像repository 这样的架构对象进行通信，它已经按照惯例知道repository。如果存储库已经作为一个接口，一个底层复杂性的抽象，你为什么希望你的模块不知道这个接口？

但是，如果您不确定存储库是否是您架构的一部分，或者您只是希望数据和存储库在最大程度上完全解耦，那么可以使用 pub/sub。

也就是说，我相信对于像 JS 这样的前端解释语言，更直接的方法通常是更好的方法。我一直使用 pub/sub 进行组件通信，但我只是不认为它们需要在架构层之间进行通信，接口就足够了。事实上，如果您将 pub/sub 模式走得太远，您最终可能会在您的 pub-sub 消息中遇到命名空间问题。

【讨论】：