In the above, I introduced Internet technology, and Web services gave us more choices at home, but what architecture used in software design is still a headache. Two-layer system (Figure 12) allows the user interface and application code to directly access the API of the database and network storage. The application uses the data model stored in the database, but does not need to establish a logical model over the model. When the system in the development is a prototype system or it has been known that its life cycle is shorter, the two-story application is ideal when the API does not change. In this typical case, this approach is used for small applications, and their development costs and time are small.
Figure 12. Two-layer architecture
In addition, the two-layer system is also meaningful for the assembly development environment, which is used in the implementation of a particular component. The assembly interface provides an isolation layer, which is opposite to the consequences of this approach. Most applications established using scripting languages belong to this, because the development of multi-architectural layers can be very troublesome in this case. Finally, two layers will provide better performance and reduce the mechanism of controlling resource locking. Although the two-layer model is dealing with multiple concurrent users to use applications, it is lacking, but its simplicity may be much better than other options. In addition, by adding a universal data handler to the database application, you can often use data stored procedures to eliminate problems with simple sharing data. With the development of the database, the three-tier application is very ordinary. The three-layer system (Figure 13) satisfies the demand of the permeated isolation. It is basically an ideal for any application system that may be modified for storage / database layers. However, the isolation of this technique is not limited to the database. It can, and should be used in any application developer, or more important application maintenance personnel to understand the environment for the minimum layer.
Figure 13. Three-layer architecture
Quite frequent repetitive use is a major design consideration, in which case the application model is required to allow it to be reused by multiple user interfaces. It has a guideline that developers should consider using a three-layer manner to replace two layers using a three-layer manner at any time when the application requires the same data. The main problems that migrate from two models to the three-layer model require consideration include appropriate network resources availability and management concurrent data access. As the result of increasing network calculations, a new trend has recently occurred, which is a four-layer system (Figure 14). When the application layer needs to support advanced behavior, you can consider the four-layer system. The four-layer model is similar to the three-layer model, but its application layer is decomposed into a performance layer and a dialogue. The performance layer presents the view part of the application model, and application logic constrained by the operation of the particular view. The problem of resource sharing between the dialogue processing, including communication with potential distributed business object models.
Figure 14. Four-layer architecture
A large number of coordination is required between the representation components, and the four-layer development method is needed when you share a lot of resources. For example, the buffer is necessary for the performance problem. The dialogue allows many different performance components to utilize the performance advantages provided by the buffer. Similarly, if a client is forced to make multiple, potentially complex distributed conclusions, you can consider encapsulating this logic into a dialogue of the application. Many factors indicate that the demand for four-story development is numerous. Obviously, any four-layer system is expected to have a long life cycle. Reuse for existing components and subsystems is usually sufficiently reason to initiate costs related to four-layer system. Similarly, the environment that is expected to frequently change the design of the design, which needs to isolate the main part of the system to the change in the assembly implementation. Four layers provide support for continuous transplantation of components and subsystems with technology development (including traditional and new technologies). In addition, the four-layer system is more easily upgraded than the three-layer system. Other considerations include the reliability of the assembly is an unknown or variable system. In the failure of intermittent components, the four-layer system can easily consolidate the runtime discovery mechanism to switch to different component implementations. Many complex systems with four or more hierarchies offer some of the ability to discover new capabilities (for example, when new Web service implementations, they implement UDDI records). If the environment utilizes multiple, potentially conflicting technologies, the four-layer system provides mechanisms for managing dialog management (session management layers) or business domain object layers. Similarly, if the client has a variety of different application models, these models require sharing common data resources, then the four-layer model may also be ideal. Frequently, in other application components do not want to block and wait for resources, the application components allow business domain components to handle resource management in the interviews, and can withstand most resources. . Peer-to-Peer, P2P architecture is ideal for most systems that require highly upgraded systems. Similarly, it is also useful when distributed components need to coordinate certain matters and communications and other components may change, they are also useful. It is very important to operate in the development of a P2P system, because bad habits may lead to major disasters. Similarly, when using P2P technology, it is also important to standardize and not allow for modification. The incompatible version of more than a plurality of P2P networks is simply a dream. A combination of n layers and / or these methods (Fig. 15) should only be used in a system that is very complex, consisting of subsystems and components different from multiple software life cycles. This is true for most large different kinds of enterprise systems, in which case components are upgraded, replaced or added at any time. For this system, it is necessary to inform the management department of the system components. Figure 15. Combination of N-layer and peer architecture
