Using the Client Dataset in an N-Tiered Application
My last two articles demonstrated the use of the client dataset in a two-tier application. The two-tier architecture may be effective in some situations but in many circumstances it suffers from some serious drawbacks. This is where the concept of an n-tiered or multi-tiered architecture comes in.
Using the Client Dataset in an N-Tiered Application - Connecting to the Application Server (Page 4 of 4 )
This connection object can be used to link the client dataset to the provider in the application server. Assign the name of the connection component to the RemoteServer property of the client dataset. The ServerGUIDproperty of the client dataset will be automatically updated to hold the GUID of the server. The provider property of the client dataset in the Object Inspector lists all the dataset providers available. Select a dataset provider and set the active property of the client dataset to true. The client application is now fully functional and can be used to view and edit data.
When you start the client application it tries to connect to the application server specified through the connection component. If the server is not running the client application starts it. It then receives an IAppServer interface which is used by it to communicate with the application server.
The client application, through the client dataset, requests data from the application server. The application server receives the data from the data source. The provider residing in the application server then encodes the records into data packets and sends them across to the client application. The client dataset in the client application decodes the data packets and displays them to the user through visual components.
The data modified by the user is not sent to the server immediately. It is cached locally in the change log. When the user calls the ApplyUpdate method, the client dataset converts the records in the ChangeLog into data packets and sends them to the application server, which decodes the data packets and posts them to the data source. Records which could not be updated are sent back to the client dataset which tries to reconcile them.
You can reconcile the erring records in many ways, but the easiest of them is by using the Reconcile Error Dialog. Reconciling errors using the Reconcile Error Dialog is discussed in detail in the next installment. After reconciliation, the reconciled records are discarded from the change log and the client dataset refreshes the data to reflect the current values of the fields.
In this article I have talked about just one of the approaches to creating n-tiered applications. Delphi provides many different approaches for this, but as I said in the beginning, the objective of this article is not to discuss architectures but features provided by the client dataset and provider components. We have seen how these components can be used to create file-based database applications, single-tiered, two-tiered and n-tiered applications, but we have not really discussed in detail some of the key features of the client dataset, especially those related to controlling database transactions. The next article will focus on how the client dataset and dataset provider allow you to control transactions and how to apply updates, reconcile errors and work with data packets.
DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.