System-level architectural style

 

Two-story and three-tier C / S architecture style

Layer C / S structure is represented by the application layer functions into three parts functional layer and data layer.

The presentation layer is the user interface portion of the application, which bears the function of dialogue between the user and the application.

A functional layer corresponds to the application of the body, which is specifically incorporated into the business logic procedures.

Data layer is the database management system, is responsible for managing the database to read and write data.

B / S architecture style

MVC architecture style

MVC full name is Model ViewController, is a model (model) - view (view) - abbreviation controller (controller), which is a layered architecture style.

MVC division and cooperation of the various parts is such that: (1) Model is an application state and the encapsulation of business functions, we can understand it contains both data and behavior model field. Model Controller accepts the request and complete the corresponding business process, to give notice of the state change when the View.

(2) View visualization interface presentation and capturing the end-user interaction (e.g., mouse and keyboard operation).

After forwards (3) View captured user to directly interact Controller, which performs the corresponding UI logic. If you need to involve invoking business functions, Controller will direct calls Model. Upon completion of the UI processing, Controller controls the original View as needed or create a new View responds to user interaction.

MVP architectural style

Not directly used in MVP Model View, communication between them is performed by Presenter (Controller MVC in), all of the interaction taking place within the Presenter, and reads the data directly from the MVC is the Model View rather than through the Controller.

SOA model

SOA is a computing environment design, development, deployment and management of discrete logic unit (service) model method.

SOA design principles:

(1)明确定义的接口。服务请求者依赖于服务规约来调用服务,因此,服务定义必须长时间稳定,一旦公布,不能随意更改;服务的定义应尽可能明确,减少请求者的不适当使用;不要让请求者看到服务内部的私有数据。

(2)自包含和模块化。服务封装了那些在业务上稳定、重复出现的活动和构件,实现服务的功能实体是完全独立自主的,独立进行部署、版本控制、自我管理和恢复。

(3)粗粒度。服务数量不应该太多,依靠消息交互而不是远程过程调用,通常消息量比较大,但是服务之间的交互频度较低。

(4)松耦合。服务请求者可见的是服务的接口,其位置、实现技术、当前状态和私有数据等,对服务请求者而言是不可见的。

(5)互操作性、兼容和策略声明。为了确保服务规约的全面和明确,策略成为一个越来越重要的方面。

Guess you like

Origin blog.csdn.net/q947448283/article/details/93858852