3

I have to implement a repository pattern-like object that will maintain a list of items. The repo would look something like this:

var repository = {

    data: [],

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

    update: function() { ... }
}

The end consumer of the repo's data would be some component. I am thinking to exploit the reference to the repo's data array in order to update the DOM whenever it changes:

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

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

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

While it feels neat and supposedly uses a legit functionality, is it really a good idea? Should I use observer/notifications in the repository instead?

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

An example (using Angular) you can find here: http://jsfiddle.net/xen8m148/

Ivan Ivanov
  • 33
  • 4

2 Answers2

3

depends on how you implement that absolute not-built-in "is changed" =) Generally if you want to keep spurious processing down, a publish/subscribe model is better. If you don't care about wasted cpu cycles, then you can use Object.observe to look at object changes.

From a software engineering point of view, though, it looks like you're sharing your data between two owners, and that -rather than how you're listening for changes- is a potentially much bigger problem in the future.

Mike 'Pomax' Kamermans
  • 49,297
  • 16
  • 112
  • 153
  • I suspect OP was trying to use `repository` like a datastore. In that case, there's no real data coupling issue, since the repository does not actually operate on the data, nor depend on the data. – light Jul 03 '15 at 16:28
  • I never trust things to be what their name says they are, so: even if it's called "repository", I won't for a second believe no one's going to end up not making it manipulate the data itself as well at some point in time. Better to be clear these things up front (note that OP calls it a repository pattern-*like* object, not a repository. That's always worrying) – Mike 'Pomax' Kamermans Jul 03 '15 at 16:34
  • You have a point, but I think this is an architectural concern. If the application was modeled with an architecture whereby "repository" is one of the layers meant to store data (perhaps persistent to disk?) and nothing else, we'd expect it to not be manipulating the data. – light Jul 03 '15 at 16:43
  • I'd agree if that "like" wasn't in the problem statement =) – Mike 'Pomax' Kamermans Jul 03 '15 at 20:42
  • Imagine it's not called repository. :) – Ivan Ivanov Jul 04 '15 at 11:44
  • I have two components that have references to a common object. Having in mind that my particular situation, that someone else could break something, I should better use some observer mechanism. Thanks! – Ivan Ivanov Jul 04 '15 at 11:50
0

I generally think a pub/sub pattern would be unnecessary if you are communicating with a repository. Assuming your application is using a repository to abstract CRUDs to an underlying persistent mechanism for all data in the system, then this repository is actually an important piece of the architecture.

The pub/sub pattern is useful if the communicating modules do not know about one another's existence. If a module/object is trying to communicate with an architectural object like a repository, it already knows about repository by convention. If the repository already serves as an interface, an abstraction of an underlying complexity, why would you want your modules to not know about this interface?

However, if you are unsure about a repository being part of your architecture, or if you simply want the data and repository to be totally decoupled to the maximum degree, then yes a pub/sub would work.

That said, I believe for a front-end interpreted language like JS, the more straightforward approach is usually the better approach. I use pub/sub for component communication all the time, but I just don't see the need for them for communication between architectural layers, where interfaces would suffice. In fact, if you take the pub/sub pattern too far, you may end up with a namespace problem in your pub-sub messages.

light
  • 4,157
  • 3
  • 25
  • 38