3

I recently (about two months ago) read an article that explained some user interface paradigm that I can't remember the name of and I also can't find the article anymore.

The paradigm allows for decoupling the user interface and backend through message passing (via some queueing implementation). So each user action results in a message being pased to the backend. The user interface is then updated to inform the user that his request is being processed.

The assumption is that a user interface is stale by definition. When you read data from some store into memory, it is stale because another transaction may be updating the same data already. If you assume this, it makes no sense to try to represent the 'current' database state in the user interface (so the delay introduced by passing messages to a backend doesn't matter).

If I remember correctly, the article also mentioned a read-optimized data store for rendering the user interface.

The article assumed a high-traffic web application. A primary reason for using a message queue communicating with the backend is performance: returning control to the user as soon as possible. Updating backend stores is handled by another process and eventually these changes also become visible to the user.

I hope I have explained accurately enough what I'm looking for. If someone can provide some pointers to what I'm looking for, thanks very much in advance.

Ronald Wildenberg
  • 215
  • 1
  • 6

1 Answers1

3

Sounds like CQRS - Command Query Responsibility Segregation

Here's Martin Fowler on the subject: http://martinfowler.com/bliki/CQRS.html

Murph
  • 7,813
  • 1
  • 28
  • 41
  • I also thought of CQRS, but the question was about UI paradigm, and CQRS is general. So I wonder if this was the sought answer of there is something else there. – herby Jul 03 '12 at 11:37
  • 1
    That's it :) The article I read described it in terms of a web application so that's where the 'UI paradigm' came from. Sorry if this was confusing. – Ronald Wildenberg Jul 03 '12 at 12:14