Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
None of these requirements presents an insurmountable programming challenge. If the code that handles each requirement had to be written de novo, however, it would add significant work to the overall effort. Fortunately, support for these tasks is already provided by the Java class library in the form of interface Observer and class Observable. The functionalities of these two were inspired, in part, by the requirements of the Model/View/Controller architecture.
The Model/View/Controller architecture was introduced as part of the Smalltalk-80 version of the Smalltalk programming language (a popular object-oriented programming language invented by Alan Kay). The Model/View/Controller architecture was designed to reduce the programming effort required to build systems that made use of multiple, synchronized presentations of the same data. Its central characteristics are that the model, the controllers, and the views are treated as separate entities, and that changes made to the model should be reflected automatically in each of the views.
In addition to the program example described in the opening paragraph above, the Model/View/Controller architecture may be used for projects such as the following:
Figure 1 illustrates the Model/View/Controller architecture in its most general form. There is one model. Multiple controllers manipulate the model; multiple views display the data in the model, and change as the state of the model changes.
The Model/View/Controller architecture has several benefits:
By incorporating the Model/View/Controller architecture into a design, pieces of a program can be designed separately (and designed to do their job well) and then bound together at run time. If a component is later deemed to be unsuitable, it can be replaced without affecting the other pieces. Contrast that scenario with the monolithic approach typical of many quick-and-dirty Java programs. Often a frame contains all of the state, handles all events, does all of the calculations, and displays the result. Thus, in all but the simplest of such systems, making changes after the fact is not trivial.