HistoryIf we used word architecture some 200 years ago we would certainly relate to “an art of building” or “a style of building” that are the original meanings of the word. An architect was a chief builder responsible for:
- designing a building
- deciding on building blocks
- putting them together
Software ArchitectureThe original meaning of the word “architecture” has not changed too much from 200 years ago when it was describing buildings. It still means three qualities of the end product, only the end product is different. Then it was a building, church or a castle, now, it is a software application. It is still:
- type, purpose and design of the application
- libraries, components, classes the app consists of
- way of communication among the components for the desired end
1. Type, Purpose and Design of the ApplicationThis is the most general view of the app and its type. We can have local applications such as word processors, spreadsheets, presentations, we know client-server applications like emailing clients and server agents, there are also specialized real-time applications for controlling industrial technological processes or cars, washing machines and other appliances. Obviously, the type of the application has the decisive influence on other aspects of its architecture. A car control software would be significantly different from an Ext-based client-server web application.
2. Libraries, Components, ClassesThis is mainly about Ext applications, so the library used would be ExtJS, possibly also some additional libraries we might need (Google Maps and others). The library or frameworks themselves contains building blocks we use in architecting the application. In spite of the plenty of useful library-packed components, one of the main tasks of the application architect is to specify the higher level of the custom, application components put up together from the simpler, generic library pieces. Are we going to use MVC, MVVM, Blocking, Non-Blocking, Event-Driven, Synchronous, Asynchronous, Plugins, Extensions, to name a few of contemporary software architecture classifications? (You can google for them but for the purpose of this article you do not need to know what the above abbreviations or esoterically sounding words mean.) Ext currently supports all of the above concepts so the architect must wrap his head around the medley and select those that best suit the Type, Purpose and Design of the Application as described in the previous article. Corollary: The question if MVVM is better than MVC is irrelevant unless we evaluate it in the context of the application itself. For some types, MVVM is best, for other MVC, and usually it would be the combination thereof that is most suitable.
3. Inter-application CommunicationThis is the make-break area of the architect’s work. Based on how the communication is done you can tell stupid from wise, dilettante from qualified or amateur from professional. There are so many ways of how to go awry with components communication that it is quite rare to see a well-designed application. I have even seen a developer getting a reference to a button and then firing click event on it for the handler to execute and, unfortunately, these extremes are not too uncommon. What we have and what we must not neglect here are component inputs, outputs and hierarchy. Inputs are methods we can call on a component when we want it to do something – well, the real data of inputs are arguments to these methods. For example, if we want a component to enable and disable its main toolbar, we implement function (method)
setMainToolbarDisabled()or we can also add
disableMainToolbar(). Outputs are events (or publishing in MVVM). When we need to inform the rest of the application that something happened to a component, for example that data arrived, or the user clicked a button then we utilize events. We can use the predefined library or DOM events, but we could, and definitely should, utilize also the custom, application specific events. Hierarchy should be similar to a structure of an organization in real life. Subordinates do not tell seniors what to do – views do not call methods of controllers. One junior does not have more bosses – one view is not controlled by more than one controller. Employees of different departments do not need to talk to each other – lateral communication among views or controllers is detrimental to the application quality. Seriously, if you “only fix bugs”, if you are “scared to touch this code”, if “a change results in a heap of new bugs”, if the application is “too buggy”, or if the development, however fast it was at the beginning is now progressing a snail’s speed, then there is a problem in the area of inter-application communication. Period.