What architecture is used in software design is still a headache.
The two-tier system (Figure 12) allows the user interface and application code to directly access the database and network storage APIs. The application uses the data model stored in the database, but does not need to establish a logical model on top of the model. Two-tier applications are ideal when the system in development is a prototype system or if it is known that its life cycle is short and the API does not change. Typically, this approach is used in small applications where development costs and time are minimal.
Figure 12. Two-tier architecture |
In addition, two-tier systems also make sense for the component-oriented development environment, which is used in the implementation of specific components. The component interface provides an isolation layer, contrary to the consequences of this approach. Most applications built using scripting languages fall into this category because the development of multi-schema layers can be cumbersome and impractical in this case.
Finally, the two-tier approach will provide better performance and reduce the need to control resource locking mechanisms. Although the two-tier model lacks the ability to handle multiple concurrent users with applications, its simplicity may be far superior to other alternatives. In addition, by adding a common data handler to a database application, it is often possible to use data stored procedures to eliminate some simple shared data issues.
With the development of the database, the three-tier (Three-tier) application is already very common. The three-tier system (Figure 13) satisfies the need for isolated execution. It is basically ideal for any application system where the storage/database layer may be modified. However, the isolation of this technology is not limited to databases. It can and should be used on any environment that does not require application developers, or more importantly, to have a detailed understanding of the lowest level of application maintenance personnel to share code.
Figure 13. Three-tier architecture |
Fairly frequent reuse is a major design consideration, in which case the application model needs to be established to allow a portion of it to be reused by multiple user interface viewing components. It has a guideline that developers should consider using a three-tier approach instead of a two-tier approach at any time when the application needs multiple views of the same data.
The main issues to consider when migrating from a two-tier model to a three-tier model include the availability of appropriate network resources and the locking scheme for managing concurrent data access.
As a result of increasing emphasis on network computing, a new trend has recently emerged, namely, the four-tier system (Figure 14). Four-tier systems can be considered when the application layer needs to support advanced behavior. The four-tier model is similar to the three-tier model, but its application layer is decomposed into a presentation layer and a dialog layer. The presentation layer presents the view portion of the application model and the application logic that is constrained by the operation of the particular view. The dialog layer handles the problem of resource sharing between the presentation components, including communication with the potential distributed business object model.
Figure 14. Four-tier architecture |
A four-tier development approach is required when there is a lot of coordination between the presentation components and the need to share a lot of resources between them. For example, buffering is necessary due to performance problems. The dialog layer allows many different presentation components to take advantage of the performance benefits provided by Buffering. Similarly, if a client is forced to make multiple, potentially complex, distributed conclusions, consider encapsulating this logic in a single layer of the application's conversation.
Many factors suggest a large number of requirements to consider four-tier development approaches. It is clear that any four-tier system is expected to have a long life cycle. The reuse of existing components and subsystems is often a sufficient reason to raise the costs associated with the four-tier system. Similarly, an environment in which individual components are expected to frequently change the target of a design needs to isolate the main part of the system from changes in the implementation of the component. The four-tier approach provides support for continuous porting of components and subsystems along with the development of technologies, including traditional and new technologies. In addition, the four-tier system is easier to upgrade than a three-tier system.
Other considerations include the reliability of the component as an unknown or variable system. In the intermittent component failure, the four-tier system can easily merge the runtime discovery mechanism (runtime discovery mechanisms) to switch to different component implementations. Many complex systems with four or more levels provide at least some of the capabilities to discover new capabilities (for example, they implement UDDI records when it comes to new Web service implementations). If the environment leverages multiple, potentially conflicting technologies, the four-tier system provides a mechanism for managing the differences in the Conversation management layer (Session management layer) or the Business Domain object layer. Similarly, a four-tier model can be ideal if the client has many different application models that need to share common data resources. Often, in an environment where other application components do not want to block and wait for resources, and have to manage client access in the dialog layer, the application components allow the business domain components to handle resource management issues and be able to withstand the wait for most resources.
The equivalent (PEER-TO-PEER,P2P) architecture approach is ideal for most systems that require a highly upgradeable system. Similarly, they are useful when distributed components need to coordinate the completion of certain transactions and the reliability of the communication and other components may change. It is important that the operating environment is easily understood when developing peer-to-peer systems, because bad habits can lead to major disasters. It is also important to standardize and not allow modification of interfaces when using peer-to-peer technology. It's a nightmare to be forced to deal with incompatible versions of multiple peer networks.
The N-tier and/or combination of these methods (Figure 15) should be used only for very complex systems consisting of subsystems and components of different software lifecycles. This is true for most large, different kinds of enterprise systems, in which case the components are being upgraded, replaced, or added at any time. For such systems, the management of the system components must be notified of the considerations.
Figure 15. N-tier and peer architecture combinations |
Which features are worth using complex n-tier systems? Typically, it includes systems that manage a large amount of data to enhance the user experience. The requirements might include documenting user profiles, allowing users to set parameters to control Web pages and applications, managing complex security requirements such as access control lists for controlling resources, and allowing users to request changes in storage management and rule execution in back-end applications, among other Web sites and applications.
With n-tier applications, the functionality of the application is decomposed into a large number of logical layers, which can be maintained and configured separately. Each level of functionality is not as standard as a three-tier application, and many layers are often combined into a set to provide performance, application, and/or business logic and storage management functions. The main advantage of supporting multiple tiers is that it is easier to modify a hierarchy without changing many levels (in most cases no other levels need to be changed). In addition, by changing the distribution or onboarding of one or more levels, the application can be expanded to handle a large amount of user load and/or data. Usually this scaling is transparent to the other levels, and in many cases it is automatic. In fact, a multilayer architecture is conceived to distribute programs across multiple computers and processors, rather than defining software boundaries in an application.
