Graphical User Interfaces (GUIs) tend to be event driven. A user performs an action and the GUI sends that event to any interested components through a Model-View-Controller mechanism. When the events being sent represent fine grained actions (for example a single field on a form changed, as opposed to coarse grained events like the form being submitted), the performance of the GUI can become an issue. Other examples of when performance of the GUI might become an issue are: when the model in the GUI is large, when the GUI needs to process the data a lot in preparation for displaying it (either client or server side), when the GUI is poorly implemented and duplicate listeners exist meaning that components are refreshed multiple times, unnecessarily. The following strategy has been used to help improve GUI performance. This list is ordered with the easiest / most important tasks (least effort, best improvement) at the top: ensure a clean MVC implementation, without duplicate listeners, add data caches, optimise caches (e.g. they hold more than one object graph), optimise refreshing of non-active elements. 1) Clean MVC Implementation First of all, read the MVC article on this blog. Then, using a profiler or debugger follow your controller as it fires model change events. Are any model listeners fired more than once for any reason? If they are, it is less than optimal and you need to first look for mistakes in the programming logic. If there really is a good reason that the event…
Tag: Design
Model – View – Controller (MVC) Design Pattern
Here is a quick challenge: Go to Google and search for "MVC". Check each of the first ten search results. What do you notice? Each description of MVC is different. Perhaps not in terms of the Model, the View and the Controller, but in terms of the details of how they interact with each other. In some descriptions the controller sits between the View and the Model. In others they all talk to each other. I have even seen implementations where an update in the GUI sends an event to the Controller which updates the Model which sends an event back to the Controller which updates the View, with the same data which it just changed, resulting in a very active user interface! Now it starts to makes a lot more sense, that both Java Swing and Eclipse SWT / JFace do not implement true MCV but rather a light weight version referred to often as separable model architecture. Here, the Model is seperate from a "delegate" which is a combination of the Controller and View. It makes a lot of sense and reduces complexity and confusion a great deal. One case where I would advocate a separate Controller is where the View is very complex and there are also a lot of business rules dictating how the data is validated before being set in the model. Then it is useful to implement a Controller. In such cases I suggest the following rules for your three MVC components: The View…
SAP, SOA and a GUI
When I first learned about SAP, I was led to believe it was insular. Sharing its data or uploading data to it was possible, but expensive and discouraged. If you have SAP, stick with it. Then came XI, the SAP eXchange Infrastructure which is the SAP offering for Enterprise Application Integration (EAI), or now rather Enterprise Service Bus (ESB). With it, you can build marvellous Service Oriented Architectures (SOA). So what? Well, my experience of XI is that its used as a replacement for IDOCs, BAPI, EDI and the like. Instead of those hard to use protocols, simply subscribe to a published web service. But hang on... If SOA is in use, couldn't we go a step further? SAP isn't very good at really rich clients (GUIs), and chances are, to develop one would cost a huge amount. So what about the idea of building your business logic on top of existing SAP functionality, so that you extend it to suit your business processes, and then build that rich client on top of the SOA that SAP can offer from your business logic? An example would be the project I'm working on at the moment. We need to build a planning tool for use in Service Stations for trains. Service stations consist of a large number of platforms where trains can be serviced. Some types of service can only be done on some platforms (axle change for example). As well as planning which trains go where and when and for…
