Relationship and implementation model of each layer in a three-tier architecture

In a three-tier architecture, the application presentation layer (client), business logic layer (middle layer), and data layer may be located at different network ends, therefore, communication and scheduling between them will become very difficult, and transactions between components widely used in the middle layer will become complicated. Therefore, microsoft provides a system solution to solve these problems. Specific implementation technologies/tools include: MS Remote Data Services, Ms Transaction Server, COM/DCOM/COM +.
On the client, use RDS to remotely create data service components in the middle layer.
The sharing mechanism works when rdsserver. DataFactory or custom business objects are run in the Transaction Server Runtime Environment of the intermediate layer. Using only several hundred instead of thousands of database connections can still support thousands of clients. This is the ODBC resource distributor function in Microsoft Transaction Server.
The middle layer and data layer can be connected through ADO to implement data read/write operations.
?
You can use RDS to return a recordset from the server to the client in three ways. The three methods are as follows:
(1) Use the RDS. datacontrol method and attributes that automatically call the rdsserver. DataFactory object.
(2) manually call the rdsserver. DataFactory object.
(3) create a custom ActiveX DLL for data access.
Here, our client uses a custom intermediate layer object (DCOM/COM +) to process business logic and access data.
First, let's look at the basic RDS programming model:
RDS determines the address for the application that exists in the following environment: the customer application specifies the program to be executed on the server and specifies the parameters used to return the corresponding information. The program called on the server accesses the specified data source, retrieves information, processes the data, and returns the result information to the customer application in an easy-to-use format.

The specific implementation model is listed below.
(1) Specify the program called on the server and obtain a way to reference the program from the client. (This reference is sometimes called a "proxy", which represents a remote server program. The client application calls a proxy like a local program, but actually calls a remote server program .)
(2) Call the server program. Send parameters to the server program that identifies the data source and the command to be released. (The server program actually uses ADO to access the data source. Ado establishes a connection with a given parameter, and then publishes the command specified in other parameters ).
(3) The server program obtains the recordset object from the data source. You can choose to process the recordset object on the server.
(4) The server program returns the final recordset object to the client application.
(5) on the client side, the recordset object is converted into a format that is convenient for visual controls.
(6) Any modifications made to the recordset object will be returned to the server program, which will be used by the server program to update the data source.
?
The corresponding programming model is as follows (RDS provides a way to execute the following action sequence). The programming model refers to the activity sequence necessary to accomplish this purpose:
(1) Specify the program called on the server and obtain the method (proxy) for calling the program through the client ). (RDS. DataSpace)
(2) Call the server program. Pass the parameters to the server program that identifies the data source and the command to be released. (Proxy or RDs. datacontrol)
(3) The server program obtains the recordset object from the data source (generally by using ADO ). You can choose to process the recordset object on the server. (Rdsserver. DataFactory)
(4) The server program returns the final recordset object to the client application. (Proxy)
(5) on the client side, the recordset object is converted into a format that can be conveniently used by visual controls. (Visual control and RDS. datacontrol)
(6) changes made to the recordset object are returned to the server and used to update the data source. (RDS. datacontrol or rdsserver. DataFactory)
The above is a standard three-tier architecture programming solution provided by Microsoft. In fact, we can use the self-implemented middle layer to replace rdsserver. dataFactory, and a variety of custom active control/dll can be used for RDS. datacontrol. Reasonable customization of components that meet our requirements will greatly modularize the entire system and make the client logic simple and easy to transplant.