Monolithic Development
In the days of the mainframe or the standalone personal computer, when an application was run on a single machine, it was common to find monolithic applications containing all the functionality of the application. 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, the high levels of program maintenance required to keep up with today's changing business needs means that applications, written in this way, might have to be updated and recompiled daily. In this world monolithic code is no longer a workable software architecture. Monolithic code is called single or one-tier.
NOTE
Even today, if you need a very simple application where, for example, the client application accesses and updates information in a database, locally you need only one tier. However, as you will see, you probably want to use components and/or layers to manage application complexity.
Figure 1.1 shows how this application may look running on a single machine.
Figure 1.1. Monolithic code scenario.
If you are writing a simple utility that does not use network connectivity, the monolithic 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 and the rollout of new versions of the software gets more complicated as more users install and use the application.