.NET Data Services  Any Time, Any Place, Anywhere with "Diamondback"!

At the 2004 Borland Conference in San Jose, USA, Borland showcased its next version of Delphi for the first time, codenamed "Diamondback". Of the many capabilities of this significant new version, I am going to focus in this article on the database side of things and more specifically on parts of the product that come under the banner of RAD for ADO.NET.

In this article, we are going to build up an example .NET database application. The application will grow through three iterations. Firstly, no-code .NET database access using the Borland Data Provider technology. Secondly, we will move on to show some of the new and exclusive ways that Borland enables developers to manage data from (and to) multiple databases within .NET applications. The final stage will be to separate the database services into tiers, with server and client applications to show how you can use .NET remoting to provide effective data services with minimum effort and maximum business impact.

First step is to introduce you to "no-code" .NET data Access with the Borland Data Providers (BDP). Borland have developed a data access layer on ADO.NET called the Borland Data Providers. This set of components provides developers with instant access to all major Enterprise databases.

Figure 1 : The Borland Data Provider Components

In Figure 1, you see the "Diamondback" Tool Palette with the BDP components selected  notice the incremental key search that the tool palette provides. The main components that we will be using here are the bdpConnection and bdpDataAdapter components. Before that though, we need databases to work with, Figure 2 shows a shot of some of the embedded Data Explorer functionality within "Diamondback".

Figure 2 : Access, and now maintain all aspects of your connected databases with the enhanced "Diamondback" Database Explorer

Figure 2 shows the Northwinds MS SQL Server database with the Data Explorer speed menu activated. The Data Explorer now enables you to maintain your entire database, as well as providing the capability to migrate whole tables, including data, from one database type to another. In this shot, you can also see the other enterprise databases that have default BDP support within "Diamondback" Enterprise and Architect Editions.

Now to get our example rolling, with "Diamondback" running, start a new Winform application using File | New Windows Form Application. Click on a table node within the Data Explorer - I chose the Customer table  and drag the table from the Data Explorer and drop it onto the Winform. This automatically creates and configures both a bdpConnection and a bdpDataAdapter component for you. Right Click on the bdpDataAdapter component and select Configure Data Adapter. Take a look at the Adapter Configuration as shown in Figure 3.

Figure 3 : Configuring a Data Adapter

You will see that Select, Update, Insert and Delete queries have been set up, but we would be free to modify these statements if needed. Select the DataSet tab, then set the New DataSet radio button, before pushing OK. This creates a DataSet that is already hooked to your data provision layer. We now have an application-ready data layer to use.

Now, go back to the bdpDataAdapter and set the Active property to true, before dropping a DataGrid onto the form. With the DataGrid selected, use the dropdown on DataSource property of the Object Inspector to select DataTable1. We now have live data at design time and have not written a single line of code. If you hit the F9 key to compile and run the application, you can now inspect the data within a running application. Figure 4 shows our simple data accessing form application running, connected to the customer table of the Northwinds database. Just to stress the point that we have achieved this all with zero code.

Figure 4 : Why write code to access your enterprise database?

At this stage, I am not going to explore how you would write back changes to the database, we will do that when we get onto the next level of the article. Also, white papers already exist on working with BDP at this level, references are provided at the end of this article.

Now to turn the heat up. The next stage is to look at how we can access, edit and update data, both to and from multiple data sources using BDP technology. Whats even better is this is all provided in a very generic, yet effect manner. Basic BDP, as covered so far, has been around in C#Builder and Delphi 8 for some time, now lets move on to things that are new for "Diamondback". I hope that you will see that the implications of this next stage are very significant for the use of data services on the .NET platform.

At this point, the fastest way forward, is to actually take one step back first. Select the DataSet1 component and delete it. This is going to be the easiest way to remove dataset references in both the DataAdapter and DataGrid components.

In the example that I am building, I am going to use the example Employee.gdb InterBase database as the second source of data. Which I have set up as a BDP connection in my Data Explorer. In the same way as you accessed the SQL Server database in the first part of this article, select the Country table and drop this onto the form to provide respective bdpConnection and bdpDataAdapter components to this second data source. Dont be tempted to provide another DataSet yet, move straight on to select the Tool Palette (you can do this very quickly by selecting CTRL-ALT P. Now type "data" and you will see the filter operate. Its the components in Figure 5 that we are interested in here.

Figure 5 : New "Diamondback" DataSync and DataHub Components

Firstly click on the DataSync component and drop this onto the form. The job of the Datasync component is to synchonise and manage data from multiple data adapters. The minimum that we will have to do to illustrate this is going to some configuring of the Providers property. In the Object Inspector, click on the Providers property ellipsis () button to show and configure the DataProvider Collection Editor as shown in Figure 6. You can see that I have added two new Members, one for each bdpDataAdapter that we want to access. Note that I provided more informative names for each, dpCustomer and dpCountry.

Figure 6 : DataProvider Collection Editor

We now have full control over two different types of database from within our .NET application and have written no code! Next, in the same way as we have been doing all along, drop a DataHub and a new DataSet onto the form. The job of the DataHub is to work with the database access provided by the DataSync and channel that to application for use. Using the Object Inspector, configure the DataHub component as shown in Figure 7. You will shortly see how this configuration is going to work together. Hang on in with the build process for a minute.

Figure 7 : Three properties to configure the DataHub

Now we are really starting to get there. Go back to the form itself and select the DataGrid. Drop down the DataSource property. You will see that there are four options - <none>, DataSet1, dpCustomerTable and dpCountryTable. Select DataSet1. Now set the DataMember property to one of the two tables. I set mine to dpCustomerTable. You will see that the DataGrid now springs back to life with data from the Northwinds Customer table. So, are we only back to square one? Not when we complete the next stages.

Place three Button components onto the form. Set the Text properties of the Button components from Button1 to Button3 as follows. "Customer", "Country", "Update".

Now double click on each button in turn to handle the Click event for each as shown in Table 1.

Table 1 : Code for Button Click Event Handler Methods

Hit F9 to compile and run this application. You will see that the first two buttons allow you to "hot swap" the grid from one database to another. The real power comes in when you use the "Update" button. One single, short and generic line of code will update any changes that are made to either or both of the databases. You can see our application so far in Figure 8.

Figure 8 : Multiple data sources, configurable at runtime and written back to all connected databases with a single code line

With a single line of code, we have full access to multiple enterprise databases

Before we move on, lets take a look at what we have configured. Figure 9 shows us the schematic well.

Figure 9 : The structure of what we can configure within a single process with RAD for ADO.NET DataSync and DataHub components

The final stage of our look at RAD for ADO.NET is to extend the multi database accessing single application that we have developed so far to work over .NET remoting. In this way, we will be able to offer .NET database services to many types of consumers (Winform, Web apps, Web services and so on) and all with minimum effort and maximum business impact. We are going to use the application that we have built so far as a server application that provides database access and resolving capability to client applications. It has been made very simple to do this through the provision of two more components in "Diamondback", the RemoteServer and RemoteConnection components. Save the application that you have built so far  dont worry the new "Diamondback" history and local backup capabilities will enable you to come back to this glorious landmark stage whenever you like. Drop a RemoteServer component onto the form (from under the General tab on the Tool Palette).

The properties that you need to configure are shown in Table 2.

Table 2 : RemoteServer Component Settings

This is not the time or place to go into detail about .NET remoting  however much fun that might be. If you would like to read up on it, there are references at the bottom of this article. Just suffice to say that the DataSync component is offered as the component to be "remoted", I want the remoting service of the application to start automatically with AutoStart to True, and I want the protocol to be binary TCP as the ChannelType, as opposed to the HTTP alternative given. Hit F9 to compile, link and run your application. You are going to need to leave the server application running while we configure our data client application in this next section.

Using the Project Manager, right-click on the Project Group node and select Add New Project from the speed menu. Select to add a new Winform application to your Project Group (the equivalent of Solution to Visual Studio.NET readers). Using the Tool Palette, drop a RemoteServer component onto the form and configure it. The properties that you will need to change are shown in Table 3.

Table 3 : RemoteConnection Component Settings

Note that you will need to set the URI property and have the server application running before trying to select a ProviderType, otherwise you will not be able to select anything from the ProviderType drop down list.

The next stage is to use our data services, so add a DataHub, a DataSet and a DataGrid component onto the form, and configure the DataHub as highlighted in red in Figure 10.

Figure 10 : Configuring the client apps DataHub component

You should be ok with configuring the DataGrid, as we did that for the server application just after Figure 7, but to save you flicking back, here it is again. Drop down the DataSource property of the DataGrid and select DataSet1. Now set the DataMember property to one of the two tables. I set mine to dpCustomerTable. This time, the client application has live data at design time - all delivered live from your running data server application.

If you want to get really smart, add the three buttons, as we did for the server application user interface too! Drop three buttons on the form (or copy/paste from your server form) and re-follow Table 1 to code the button Click event methods.

Compile and run the client application  again dont forget to have your server running first  and you will be the proud owner of a .NET remoting, data serviced, client application. You can see the schematic of the component structure in Figure 11 to finish.

Figure 11 : Component schematic of RAD for ADO.NET remote tiers

Summary

Is this simple for the application developer to use? Certainly! Does this have implications for extending the use of .NET remoting? Certainly! I have built.NET remoting applications previously and it took a lot of reading, time and effort to get it right - as well as code, code, code to get it off of the ground. Borland "Diamondback" provides an easy and effective way to provide real, out-of-the box, business benefit with .NET remoting and it can all be pieced together  for both Delphi and C# language developers - with the component parts of the RAD for ADO.NET included in Borland "Diamondback" that I have outlined here. Please feel free to have a play with this code. I am going to post it to Borlands CodeCentral, as referenced below. Have fun!

References

BDP introduction White Paper

http://www.borland.com/products/white_papers/del_borland_data_provider_for_dotnet.html

MSDN .NET Remoting

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconnetremotingoverview.asp

Borland CodeCentral Project Reference

http://cc.borland.com/

About the Author

Jason Vokes works for Borland as a European Product Line Manager. He is an accomplished software developer and author, with over 15 years experience in software development. Jason often presents at conferences and seminars across Europe. If you would like to discuss any part of this article, drop Jason a line at jvokes@borland.com.

Disclaimer

In order to bring you this article as soon as possible, the examples referenced have been developed using a pre-release version of "Diamondback" (USA BorCon 2004 Build). This means that it is possible that some details may have changed between this article being written and you reading this.

Editor's note: You can watch and listen to Jason build a data remoting system with "Diamondback" with the BDNtv episode Diamondback preview of Data Remoting