Intro to Data Abstract for .NET (8:51)
Data Abstract is a way to remotely access your data.
More precisely, it is a framework that provides multi-tiered access to a database from multiple platforms. It allows you to create truly database-agnostic client apps that efficiently work with data. From desktop to mobile or the web, Data Abstract has you covered.
Let's create our first Data Abstract server and client using .NET.
In Visual Studio we search the project templates for Data Abstract and select the C# "Data Abstract WPF App" project. Click "Next" and give your project a nicer name.
The Data Abstract wizard offers a few options, but for now let's just pick the "Client and a New Custom DA Server" option which creates both a server and a client. We'll explore the other options in another video.
The project wizard allows you to define the set of database connections you commonly use. For this video we will use the PCTrade sample database that ships with Data Abstract.
Click "Next". the wizard now fetches the database structure. Let's just select a few tables to make available on our server.
After clicking "Next", the last wizard step allows us to fine-tune the server and the client projects being created. For now we'll just stick with the defaults. Click "Finish" and our projects will be opened in Visual Studio.
Let's look at the server project first. The wizard added a few files to the project, most interesting are the
.daSchema files. Much* more than the code, the Schema really is the heart of a Data Abstract server, and there's a special tool to develop schemas in called the Schema Modeler that is central to working with Data Abstract.
Double-click the Schema file to open it in Schema Modeler. You'll see that Schema Modeler opens two windows: one for the Schema itself, and one for the associated
In the Connection Manager on the right, you can manage the live connection to one or more of your databases. In this case, we see the SQLite database we picked before. The Connection Builder makes it easy to edit or add new ones as needed: simply click the add or edit button here. But for now what we have is fine.
When we fold open the connection, you can see all the objects in our database are shown. This is a live* view of what is in the actual database.
We can easily add more tables to the Schema with a simple drag to make the data available to client apps.
In the main Schema window, we see the objects identified in the Schema. In contrast to the connections window, this is the view of our database as it is exposed to the client applications.
We can make changes here: For example, let's remove the "
Notes" field so clients can't access it anymore. We could make more adjustments to customize what the client sees, including renaming whole tables and fields and more.
The "Statements" node of each table has statements that link this table to the underlying database. There could be more than one in a more complex server.
By default, Data Abstract will generate all the SQL for you, but you can also choose to provide a custom SQL statement or even a stored procedure to fetch and/or update data. If we change the statement type from "AutoSQL" to "SQL", we can provide a custom statement which Schema Modeler pre-fills for us.
As you will see in many places, Data Abstract makes the simple things easy but it also allows you to customize and fine-tune as needed.
Now let's close Schema Modeler and launch our server.
Note that we actually did not have to write any custom code at all for this server, Data Abstract takes care of everything. Of course you can customize and extend the code as you see fit.
Under the hood, Data Abstract uses our Remoting SDK framework for the network communication. This is not something you ever have to care about, but it does offer you access to all the flexibility the SDK provides if you need it. For example, to add custom non-database services to the server.
By default, our server is now live on port 8099 via HTTPS serving data via Data Abstract's highly optimized binary data format. Just like on the SDK level, Data Abstract also provides different ways to make your data available in addition to Bin2, For example as REST or OData.
The server exposes a Remoting SDK service called "
DataService" that handles all access to the data. When data is accessed, the client calls into the service. Internally, that service consults the schema and the business rules that you defined to determine how the request from the client maps to the actual database. This includes respecting renamed tables and fields, or any other restrictions to ensure the client can only access what it is supposed to.
Back in Visual Studio, our solution already contains a WPF project that is set up as a client for this server. Keep in mind you can connect any existing project to this server via the connect to Data Abstract server option here in the "Extensions" menu.
Data Abstract has created a
TableDefinitions_ file for us based on the server Schema.
Table Definitions are a set of classes representing the server schema as code. These definitions access data using a feature called DA LINQ. It is like a remote ORM that can securely access your database from across the world.
As you can see, table definition classes are simple C# classes annotated with a few attributes. We'll never really have to touch or even look at this file directly, though.
Also take note that your project contains a
.remoteSchema file. This file is a link to the remote server. It can be used to preview the remote server schema or regenerate the table definition file if needed.
Now is the time to actually access the data.
Let's open the
MainWindow.xaml file and add a simple data grid.
Switch over to the code next, and we'll add a few lines of code.
We'll add this snippet to login to the server. By default, the Data Abstract server will check for a matching username and password. For a real application, you would change the server to check for actual user data.
With that done, these three lines of code download the data and bind it to the grid.
Note that we're using LINQ syntax, so you could specify a more complex query here. LINQ queries are translated into database level SQL and executed safely on the server side.
Sending updated data back to the server is also very easy. The bindable list we created in the last step keeps track of all data changes performed locally, so these changes can be applied back to the server with a single line of code.
And that's it! Let's launch our app and see it in action.
Clicking "Load Data" downloads the
Customers table from the server. We can make some changes in the grid - for now these are just maintained locally. And finally, clicking "Apply Changes" will send the changes back to the server so they can be applied to the database.
Close the app and restart it, and you can see our change has persisted.