#EDA ‘Model-View-Broker’ Pattern: the new MVC
Virtually every software developer in the World has heard of the ‘Model-View-Controller’ (MVC) Design Pattern, which is not entirely surprising given that it was “first introduced by Trygve Reenskaug, a Smalltalk developer at the Xerox Palo Alto Research Center in 1979”. Today, Oracle provides us with a nice representation of a “Common MVC Implementation” :
Now, more than forty years later, and in the context of an emerging star in software integration — ‘Event-Driven Architecture’ — it seems high time for the next generation of MVC to be announced : the ‘Model-View-Broker’ (MVB) Pattern. Here is a reworked version of the earlier MVC Diagram, with key changes marked in yellow :
The first yellow ellipse — ‘State Change’ — signals the fact that all communication between the Broker and the Model must now be Event-Driven, which leads us directly to the second change: the Controller has been replaced by an Event (/Message) Broker. Finally, any ‘State Query’ by the View must also be Event-Driven, so must now instead be between the View and the Broker (see ‘Requested’ Event Pattern).
Rather than writing a long essay on the benefits of this new Pattern — as there are a great many — bullet-points seem more appropriate:
- Business Logic is entirely abstracted from the Model and View — we have no idea where the Logic even resides (as is typical in ‘Event-Oriented Architecture’)
- Business Logic can be supplied by numerous, distinct (EDA) ‘Software Components’ via Event-Payload filtering (e.g. Region)
- Software Components providing the necessary Logic can be written in any Language, can use any DB of their choice for persistence, can run locally or in the Cloud, and can be entirely ‘swapped-out’ without any impact whatsoever upon the Model or the View — the ‘User Experience’
- Any updates to persisted data, regardless of where it resides or who/what requested those updates, are automatically and immediately pushed to each-and-every View-Model (client) that is currently displaying/editing the same Entity/Entities — delivering us to a brave new world of real-time (transactional) data display!
- Unlike the situation today, DB ‘Record-locking’ becomes completely unnecessary — Field-level updates are only performed if, and when, the user requests a save, only on those fields that were actually changed, and each user will in any case always be working with the latest (committed) version of all data!
- As all communication is Event-based — Asynchronous — it is entirely non-blocking, thereby providing much better performance, as well as optimal resource utilisation
- The MVB Pattern natively provides full and immediate support for Offline applications — including those running in Web Browsers (where both the View and the Model typically reside today)
- etc.
LINKS
https://www.oracle.com/technical-resources/articles/javase/application-design-with-mvc.html
