Monolithic Development
In the days of the mainframe or the standalone personal computer, when an application was housed on a single machine, it was common to find monolithic applications containing all the functionality of the application in one large, frequently unmaintainable piece of software (sometimes referred to as spaghetti code). All user input, verification, business logic, and data access could be found together. This suited the world of the mainframe and corporate data center because everything was controlled and the systems themselves tended to evolve slowly. However, as the world has speeded up over the last two decades, the high levels of maintenance required to keep up with changing business needs using such an application would mean that recompilation would be almost a daily event.
Note
Even today, if you need a very simple application where, for example, the client application accesses and updates information on a database, locally you need only one tier. However, as you will see, you will still probably want to use components and or layers to control its complexity.
Figure 1.1 shows how this application may look running on a single machine.
Figure 1.1. Monolithic code scenario.
Consequences of Monolithic Applications
If you are writing a simple utility that does not use network connectivity, the previous scenario might suffice. However, any changes required to any part of the functionality may potentially affect other parts. Because the Presentation, Business, and Data Access logic are located within the same piece of application code, recompilation of many parts of the code may be necessary, increasing the overhead of adding or changing functionality. Worse still, changes in part of the code may introduce unintentional bugs in other, seemingly unrelated, parts.
Of course, updating the application involves only one machine, but the rollout of new versions of the software gets more complicated as more users install and use the application.