In contrast with standard ADO.NET and other frameworks, you can turn a DataObjects for .NET application into a distributed 3-tier application without additional coding. With DataObjects for .NET, it is a simple matter of deployment. DataObjects for .NET uses the following mechanism to enable 3-tier configuration:

You use the same data library assembly in both 2-tier and 3-tier configurations. The only difference is that when your application wants to use the data library assembly in a 3-tier configuration, it signals this intent by setting the DataLibraryUrl property to a server location, a URL where the same data library assembly is installed and ready for invocation on a remote server. For example:


dataSet1.DataLibraryURL: http://www.mycompany.com/mydatalibrary/ThreeTierServer.soap

Your client machine already has the data library assembly, since it is used by your client application, included in its project's References. This is the data library your client application talks to.

When your application requests data (Fill), the request first goes to the client data library. Knowing the URL, the client data library invokes the data library on the server (server data library) passing it the request for data. Note that both client and server run the same version of the data library assembly that is ensured by Microsoft. NET remoting support. The server data library retrieves data and sends it to the client, where the client data library receives it and exposes it to the client application.

When your application updates the database, sends modified data to the database, the client data library takes the modified data, packages it and sends to the server data library for update. The server data library reconstructs the data set on its end, so that business logic code can work properly, see Update in 2-Tier and 3-Tier Configurations, and updates the database. Then it sends the refreshed data retrieved from the database back to the client.

So, the process involves two running instances of a data library: one on the client and one on the server. Developing a data library, you do not have to be concerned with interaction between these two instances. You do not need to write two different programs for the server and for the client, because the server and the client use the same assembly built from the same data library project. DataObjects for .NET handles the interaction automatically and transparently for the developer.

If you need to know, in data library event code, which instance is currently running, the client or the server one, this information can be obtained from the RunsAt property.

Most business logic events are handled on the client, by the client data library instance. For example, when the end user modifies a field value in a grid, the C1DataSet component (to which the grid is bound with its DataSource/DataMember properties) calls the client data library, and the BeforeFieldChange event is fired and handled by business logic code inside the client data library. However, update business logic events, BeforeUpdate, BeforeUpdateRow, AfterUpdateRow and AfterUpdate are handled by the server data library, see Update in 2-Tier and 3-Tier Configurations.