Question

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

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/

Answer 1

取决于你如何实现绝对的非内置“被更改”=）通常，如果你想保持虚假处理，发布/订阅模型更好。如果您不关心浪费的cpu周期，那么您可以使用{{1}}来查看对象更改。

从软件工程的角度来看，看起来你是在两个所有者之间共享数据，而不是你正在倾听变化 - 这是未来可能存在的更大问题。 / p>

Answer 2

我通常认为如果您正在与存储库进行通信，则不需要发布/子模式。假设您的应用程序使用存储库将CRUD抽象为系统中所有数据的基础持久机制，那么此存储库实际上是架构中的一个重要部分。

如果沟通模块不了解彼此的存在，则发布/子模式非常有用。如果模块/对象尝试与repository之类的架构对象进行通信，则它已按惯例了解repository。如果存储库已经作为一个接口，一个底层复杂性的抽象，为什么你希望你的模块不知道这个接口？

但是，如果您不确定某个存储库是否是您的体系结构的一部分，或者您只是希望数据和存储库完全脱离到最大程度，则可以使用pub / sub。

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

在JavaScript中，将对象引用依赖于＆＃34; listen＆＃34;是一种很好的做法。变化？

2 个答案: