Decoupling SAPUI5 Controllers
Building web applications using the MVC architecture helps with separating concerns and keeping the application modular. In an ideal application every module has only a single responsibility. Model View Controller architecture advocates breaking an application up into three groups that are logically separated.
Models are responsible for managing the data that the application needs. This includes any operations that are to be performed against the database or web service. All logic related to the manipulation of data is to be done in the model.
Views are the face of the application and they include all the logic related to the presentation. This is where all the code describing the look and feel of the application is defined. It is a best practice to keep the view free of any business logic.
Controllers contain all the business logic of the application. Think of the controller as the quarter-back calling the shots and making the decisions. Controllers should be free of presentation logic.
This approach seems simple enough and has been used successfully by frameworks such as Ruby on Rails. SAPUI5 also follows the MVC pattern and for the most part it is quite simple to keep to the single responsibility principle. However, problems arise when one has to link an action happening in one view to the controller of a different view. If one controller operates on another then those controllers become coupled together and if you are not careful you could end up with a tightly-coupled spaghetti mess.
The solution to this problem comes in the form of the Publish-Subscribe design pattern. The basic premise of this design pattern is that instead of having two objects operating on each other directly we could rather have an event-system where methods could subscribe to an event and another method can then fire that event and publish data to all the subscribed methods. This pattern can be visualized in the following diagram:
The event system in SAPUI5 is called the Event Bus. Each SAPUI5 Component has its own Event Bus. From inside of a controller, one can use the following code to publish an event:
var oEventBus = sap.ui.core.Component.getOwnerComponentFor(this.getView()).getEventBus();
oEventBus.publish(
"MyEvent",
{
dataKey1: "Data object that you want to pass to the subscribed method",
dataKey2: "Some more data"
}
);
Then we can subscribe to this event from within another controller's onInit
method:
onInit: function() {
var oEventBus = sap.ui.core.Component.getOwnerComponentFor(this.getView()).getEventBus();
oEventBus.subscribe(
"MyEvent",
this.onMyEvent,
this
);
},
onMyEvent: function(sChannelId, sEventId, oData){
console.log(oData.dataKey1);
}
By using the publish-subscribe pattern the controllers are now decoupled and interacting via the event bus. This means that a change in one controller will not cause code in another controller to break. This makes the code more maintainable and helps manage complexity.
By implementing these techniques your business applications can grow in size while remaining modular and maintainable. Please feel free to request a demo of the benefits of using SAPUI5/Fiori as the front-end for your SAP business workflows.