# Introduction

Not long ago we published the RemObjects SDK Beginners Guide. Now we’re taking it one step further and look at the Data Abstract framework.

Most present-day business applications operate with some database data, and most often they are required to run on a variety of mobile devices (from laptops accessing the network over WiFi connections to iPad and Android tablets); now add performance and security concerns and you get an explosive mixture that could take an unpredictable amount of efforts to deal with.

So how can Data Abstract help to minimize these software development risks? Take a look at just some of the features this framework provides:
a) Supports a huge variety of platforms on the client side and .NET (or Mono) on the server side.
b) Provides the ability to create SSL-protected or AES-encrypted communication channels.
c) It is possible to use literally any relational database that has an ADO.NET driver.
d) Data source (database schema or even database server type) can be changed without any changes in the server or client code.
e) Data is sent over the wire in binary-serialized compressed form to keep network traffic at a minimum.
f) The .NET client side provides simple-to-use LINQ interfaces, as well as old-fashioned DataTable-based interfaces to the remote data.
g) With our pre-built Relativity Server you can set up your own middle tier server without writing a line of code.
…and much more.

The article below describes the core Data Abstract facilities and their relationships. It also provides a (very short) jump-in crash course into Data Abstract. In just a few minutes you will be able create your first Data Abstract-based server and client applications.

Overview

Data Abstract is built on top of the RemObjects SDK communication framework. In short, a Data Abstract server application is a RemObjects SDK-based server with database connection management, efficient data exchange protocol and declaratively (i.e. not in the program code) defined mapping between the database schema and the data structure exposed to the client applications. On the client side, Data Abstract provides components to simplify the data access so there is no need to manually compose calls to the server.

So the whole picture looks like this:

As you can see, the core Data Abstracts components are:

• The ConnectionManager that manages connections to the underlying database (or databases). It allows to pool database connections if the database’s ADO.NET driver doesn’t provide this feature or when more precise control over the connections pool is needed.
• The Schema that describes mapping between the underlying database tables and data structures exposed by the server (called data tables). The client application only has access to the data exposed via Schema tables, without direct access to the underlying database tables. Schemas can be edited using the Schema Modeler tool.
  Note that the Schema mapping is not necessarily a 1-to-1 mapping (i.e. the database table is exposed as a Schema table). For example, it is possible to expose the result of an SQL SELECT statement as a Schema table and to handle any data updates applied to this Schema table using stored procedures. This approach allows to filter data on data access, do additional data integrity checks on data updates, etc., completely transparent to the client application. Also, some database tables are not suited to be exposed as Schema tables.
• The DataService, a predefined RemObjects SDK service that exposes Schema data. In most cases there is no need to add any code to this service’s definition.
• The DataStreamer component that serializes data request results and and data update requests. DataAbstract provides two data streamers – one that exposes data using the highly effective Binary format and another that uses the JSON format to exchange data. The latter one allows to exchange data with platforms that we don’t provide a Data Abstract client library for (f.e. PHP or Ruby server code).
• The DataAdapter, a client-side component that encapsulates the server method’s calls.

Sample Application

Let’s create a simple server and client application and see how the Data Abstract components are used in a real Data Abstract-based application. Luckily, Data abstract provides a simple-to-use project wizard, so an application skeleton can be created in literally 10 seconds. Just follow these steps:

1. Start Visual Studio and create a new solution using the Data Abstract -> Windows Forms Application template.
   
2. Select the ‘Client and a New Custom Data Abstract Server’ project kind on the Wizard screen to create both server and client Data Abstract applications, so we’ll be able to investigate both server- and client-side code.
3. Select the Default Connections ->PCTrade-SQLite database connection. This pre-defined connection points to a sample SQLite database created whith the Data Abstract installation.
   
4. Now we need to select the database tables that will be included in the Schema generated for the server application. Leave all tables selected and proceed to the next wizard page.
   
5. The last Wizard page allows to set up some additional options for the solution. We need to keep things simple, so uncheck the ‘Add Login Service’ and ‘Add support for Business Rules Scripting’ project options.
   

After the Finish button is pressed, the new solution containing the Data Abstract server and client applications will be generated.
You can find a detailed description of both server and client application projects in the corresponding Wiki articles:

• The Server Project generated by the Data Abstract New Project Wizard (.NET)
• The Client Project generated by the Data Abstract New Project Wizard (.NET)

For now, let’s examine the core Data Abstract components used in the solution and proceed to actually retrieving data from the server.

Server Application

DataService and DataStreamer

First, we need to take a look at the server’s RODL and the DataService definition.

As you can see, the server’s data service descends from the DataAbstractService defined in the core Data Abstract RODL and doesn’t define any new service methods. This allows us to avoid importing the custom interface file generated for this project, because a pre-generated interface for all service methods is already included in the RemObjects.DataAbstract.dll assembly.
Note that the DataService code file doesn’t actually contain any custom method definitions. All methods used in the Data Abstract client-server communication process are already defined in the base DataAbstractService class. Of course it is possible to add event handlers or even to override method definitions inherited from the base DataAbstractService class, yet this is not needed in the current sample application. However, there are some vital settings that have to be set for the Data Abstract Server to function. In our case, these properties were already set by the New Project Wizard.
Open the DataService implementation in design mode.
First you will see the DataStreamer component. It is tied to the Data Service via its ServiceDataStreamer property.

Also note the AcquireConnection and ServiceSchemaName properties. The first one defines whether the database connection should be acquired using the default Connection Manager when the service is accessed by the client app or if a more advanced connection retrieval process should implemented in the user code (this is not needed for simple Data Abstract servers, but for example Relativity Server uses its own connection management engine). The ServiceSchemaName property points to the project file containing the Schema definition. On application startup, Data Abstract will load this file, deserialize the Schema from it and cache the result.

Connection Manager

The Engine.cs file contains definitions of network-communications-related stuff like Server Channel, Session Manager and Message (see the RemObjects SDK Beginners Guide for more information about these components). Additionally, it contains the Connection Manager that will handle connections with the underlying database.
The Connection Manager will load connection definitions from the .daConnection file on server application startup and will provide connection instances (either from its own internal pool or directly from the driver).

Schema

The last (but not least) server application element is the .daSchema file. It contains the mapping between the underlying database and the data structures actually exposed by the server application.
In the simplest case, the database tables are mapped on a 1-to-1 basis to the Schema tables. This the easiest scenario. At the same time, Data Abstract makes it possible to, for example, define a Schema table that exposes data from a complex SQL query involving joins of several tables as a plain table. Given that the needed SQL statements (either stored procedures or plain SQL statements) are defined to handle insert, update and delete operations, the client application will work with the data as if it was a simple plain table. Furthermore, if in the future the data source structure will be changed (for example if a data table containing the needed data will be introduced to the database schema) it would be possible to point the Schema table to this changed data source without changing a line of code in either the server or the client application.
The .daSchema file can be edited using a tool called Schema Modeler. The Schema Modeler can be started either as a standalone application from the Windows Start menu or by double-clicking the .daSchema file in the Solution Explorer.

Additional Information

You can find more about the generated server application project in the following Wiki article.

Client Application

Overview

The client application doesn’t differ much from an ordinary WinForms (in this case) application. It contains the main form, the regular Program.cs file, as well as a usual set of references.
Client-side Data Abstract stuff is contained in the RemObjects.DataAbstract.dll assembly. Also, the RemObjects SDK client-side set of assemblies (i.e. the RemObject.InternetPack.dll, the RemObjects.SDK.dll and the RemObjects.SDK.ZLib.dll) is required for Data Abstract, because the network communication relies on the RemObjects SDK infrastructure.
Note that the client application doesn’t contain a custom interface file. It is not needed because all interface classes and interfaces needed to communicate with the server are already defined in the RemObjects.DataAbstract.dll assembly. Of course, if the client application needs to call some custom server methods, a custom interface file will be required.
Look at the Data Module project element. It contains pre-configured server communication components.

The Client Channel and Message components are used to send data to the server and retrieve its responses.
The Data Streamer, Data Adapter and Remote Service components, however, are Data Abstract-specific. They are configured to work together:

• Remote Service receives requests from the Data Adapter and sends them to the server using Client Channel and Message.
• Data Streamer is used by the Data Adapter to serialize and deserialize requests (including data table data and data update requests). Data Abstract supports two types of Data Streamers – binary and JSON-based. The binary Data Streamer (implemented in the Bin2DataStreamer class) is the preferred one to use, because it is faster and its use consumes less network traffic. Please note that Data Streamer types used by the client and server applications should match, otherwise data exchange won’t be possible.
• Data Adapter is basically the core of the client-side Data Abstract infrastructure. It exposes the APIs needed to retrieve data from the server and to send data update requests without the need to explicitly call Data Streamer to serialize the data, call server methods etc. And again, there are two Data Adapter kinds that differ in the way data is accessed – via LINQ request or using plain System.Data.DataTable instances (either typed or untyped). Both kinds of data adapters can be used with the same server application (or even in the same client application).

Additional Information

You can find more about the generated client application project in the following Wiki article.

Data Access via DA LINQ

Now let’s fetch some data from the server and then post some update data back to it. In the following, I’ll show both the LINQ and the DataTable way of accessing the data. Let’s begin with DA LINQ, as it is the more advanced approach. You can consider DA LINQ as a (very simple) ORM that fetches data from the remote server and converts it into objects.
As you can see, the client application contains a TableDefinitions_… file. This mysterious file contains a set of classes that are code representations of Schema tables. Each public Schema table is mapped to one of the classes contained in this file, including all table fields represented as class properties. This means that this file should be regenerated in case the data structure of the Schema tables exposed by the server is changed. [This article](http://wiki.remobjects.com/wiki/How_to_Generate_and_Work_with_DA_LINQ_Table_ Definitions) describes how to manage the table definition classes. I suggest you to read this article later, as for now we already have the needed set of Table Definition classes.
To emphasize that Data Adapters (and any other Data Abstract or RemObjects SDK component) can be configured in code and designer support is just a way to speed up development, the following code will use a Data Adapter defined in code.
So let’s instantiate the Data Adapter, create some data access and data update methods and tie them to the GUI.

1. Data Adapter definition
   Define private field

LinqRemoteDataAdapter fLinqDataAdapter;

Add the following code to the constructor (AFTER the InitializeComponent method call):

this.fLinqDataAdapter = new LinqRemoteDataAdapter(); this.fLinqDataAdapter.DataStreamer = this.dataStreamer; this.fLinqDataAdapter.RemoteService = this.remoteService;

Now the Data Adapter is instantiated and tied to the Data Streamer and Remote Service instances.
2. Data access
The simplest Data Access method would look like this:

public BindingList GetData() { var lServerQuery = from x in this.fLinqDataAdapter.GetTable() select x; return lServerQuery.ToDABindingList(); }

Note how the data is accessed with a simple LINQ statement on the this.fLinqDataAdapter.GetTable<customers>()</customers> object. Data Abstract does all the work needed to convert the provided LINQ expression into a form that can be understood by the server application, send the request over the network and retrieve the data. The query used here is very simple. More advanced queries are shown by the DA LINQ Sample, including queries with conditions and queries that fetch only a subset of the target’s table columns.

The mysterious BindingList is a class that simplifies data binding. You can read more about this class in the corresponding wiki article. Of course, the data can be loaded into a simple List<T> as well.

3. Data update
   The data update method is very simple:

public void UpdateData() { this.fLinqDataAdapter.ApplyChanges(); }

The Data Adapter tracks changes made to the data into a BindingList, so all changes can be applied using a single line of code. More advanced scenarios are out of the scope of this article. You just need to know that it is possible to make data changes using methods like AddRow, UpdateRow and DeleteRow exposed by remote table instances that can be acquired using the GetTable<T> method of the Data Adapter.

4. GUI
   Add 2 buttons and a Data Grid View to the main form of the client application.
   
   Add the following code to the Click handler of the Get Data button:

this.dataGridView1.DataSource = this.fDataModule.GetData();

Add the following code to the Click handler of the Update Data button:

this.fDataModule.UpdateData();

Run both server and client applications and try to fetch data from the server, update some fields in the data grid and then push the updated data to the server. And that’s it. You have created a network server and client application and added load and save data features to the client application using just a few lines of code.

Data Access via DataTables

While DA LINQ is the more preferred way of accessing data, Data Abstract also exposes a more old-fashioned data access interface, based on the System.Data.DataTable instances, both strongly typed (corresponding to the server Schema) and untyped ones. This article describes how to manage the strongly typed dataset definitions.

In the following part of the tutorial, we’ll use the untyped dataset, for simplicity reasons.

So let’s again instantiate the Data Adapter, create some data access and data update methods and tie them to the GUI.

1. Data Adapter definition
   Define private field

RemoteDataAdapter fDataAdapter;

Add the following code to the constructor (AFTER the InitializeComponent method call):

this.fDataAdapter = new RemoteDataAdapter (); this.fDataAdapter.DataStreamer = this.dataStreamer; this.fDataAdapter.RemoteService = this.remoteService;

As you can see, the instantiation of the Data Adapter and its setup are very similar to the LINQ Data Adapter.

2. Data access
   In the case of the table-based Data Access, the simplest data access method would look like this:

public System.Data.DataTable GetDataTable() { System.Data.DataSet lDataSet = new System.Data.DataSet(); this.fDataAdapter.Fill(lDataSet, new String[] { "Customers" }, true); return lDataSet.Tables[0]; }

This code fetches only the Customers data table from the server.

3. Data update
   The data update method is very simple:

public void UpdateData(System.Data.DataTable table) { this.fDataAdapter.Update(table.DataSet); }

Note that unlike the LINQ Data Adapter, the Table Data Adapter relies on the .NET DataSet to track data changes.

4. GUI
   Change the Click handler of the Get Data button to

this.dataGridView1.DataSource = this.fDataModule.GetDataTable();

Also change the Click handler of the Update Data button to

this.fDataModule.UpdateData((System.Data.DataTable)this.dataGridView1.DataSource);

Run both server and client applications and try to fetch data from the server, update some fields in the data grid and then push the updated data to the server.
As you can see, the table-based access is similar to the DA LINQ-based one, but still differs from it in some details. It is up to you to choose the approach to use, as both of them are valid and fully supported by Data Abstract.

Conclusion

This article only scratches the surface of the Data Abstract framework world. Again (as in the RemObjects SDK Beginners Guide) many features weren’t touched or even mentioned to simplify the article.

Search our Wiki for the questions you are interested in. If for some reason you can’t find the info you need, don’t hesitate to call on our support via RemObjects Connect or drop an email to support@remobjects.com.
I would also be glad to hear your suggestions on what to describe next – Relativity Server, Olympia, or something else?