Data Abstract Architecture Overview (.NET)
From RemObjects Software
This is a Data Abstract Architecture entry
Feel free to add your notes to this topic below.
Introduction
Data Abstract is a data access framework developed to facilitate the creation of multi-tier systems that might support any number of back-end RDMBs.
The following diagram summarizes the most important pieces of Data Abstract’s architecture and shows the place and role some of the fundamental components of the framework.
As you can see from the diagram, some elements are meant to be used only server side (schema, business processor and Data Abstract Service), some only client side (RemoteDataAdapter) while others have a place on both ends (DataStreamer).
This separation of domains is reflected in the Data Abstract framework by the existence of 2 assemblies: DataAbstract.Server.dll (server only classes, not to be referenced by client applications) and DataAbstract.dll (client only and shared classes, required on both sides).
Service Orientation
A Data Abstract server application is a process hosting a number of services.
You can think of a service as a remotely accessible object meant to address the needs of a specific area of functionality (for example customer management, security and privilege management or order processing) and containing all the data access logic to deal with it.
Data Abstract services are conceptually equivalent to SOAP web-services: the main difference is that a Data Abstract service offers a lot of pre-built functionality that not only makes it accessible over a network, but also helps you accessing databases, enforce security, define an aspect oriented behavior and much more.
Schemas and the Data Layer
The first important element to understand is that data access elements such as data tables, relationships between data tables, commands or update rules are defined, server side, in schemas. The schema is then referenced by the service itself.
When you develop a Data Abstract service you don’t usually write SQL queries and commands in your code: you add them to a schema at design time and then ask the schema to instantiate or execute them for you in your code.
The ultimate result is that your service code will not contain data access related code that, for instance, instantiates an ADO.NET command, passes a SQL string to it and then calls an ExecuteReader method. It will contain mostly one-liners such as
Schema.NewDataReader(“Customers”);
or
Schema.NewCommand(“Insert_Customer”, new string[] { “Name”}, new object[]{ “Jack”})
which know how to do all that work for you.
This is a very unique feature of Data Abstract and ultimately provides you with a pre-built design that allows you to separate data access logic from business logic.
An immediate benefit of this separation is that you can also modify your data access layer independently from the business layer, add support for new database types or change the text of any SQL element without touching anything in the business code itself.
Data Transfer
At a certain point, client applications will need to query for data. Later they might need to insert, delete or update this data and will want to commit the changes to the database.
This is done in a manner that is very similar to standard ADO.NET: by using a data adapter. The main difference is that instead of using a database-specific adapter such as the SqlDbAdapter or OdbcDbAdapter, you will use Data Abstract's RemoteDataAdapter component.
The RemoteDataAdapter is a special breed of data adapters that is capable of interacting with a remote service, rather than dealing directly with a database server. It supports all the standard methods such as Update, Fill and FillSchema, but their implementation will invoke the remote methods of your service (by default GetData and UpdateData), rather than querying a database.
The format of the data traveling when one of these calls is made is determined by data streamer components. Both the remote service and the client’s RemoteDataAdapter will reference an instance of the same type of data streamer component whose responsibility will be to pack row-sets and deltas in binary or XML streams.
Updates and server-side business rules
Once a client is done manipulating row-sets (by adding, deleting or updating their data), it will need to get these changes committed on the original database. To do so, you will call the RemoteDataAdapter.Update method which will ultimately call the UpdateData passing it a number of deltas (one per data table in your ADO.NET dataset).
At this point Business Processors will get involved. The BusinessProcessor component is capable of applying all changes related to one data table by generating appropriate SQL statement for updates, deletes and inserts and executing them against the database server.
When the service UpdateData method is invoked, the service will search for a Business Processor for each of the deltas it received. Once a processor is found (or auto-created), the service will hand the delta to it and invoke the BusinessProcessor.ProcessDelta method. This is what ultimately performs the database updates.
While the ProcessDelta executes, a number of events will be triggered. There are events that are raised when a delta is about to be processed or has finished processing, events that are raised before and after each delta change is about to be processed and more. By hooking to these event handlers, you have the opportunity to enforce specific business rules and control every aspect of the updates.
See Also
Product: RemObjects Data Abstract
Current version: Data Abstract 'Vinci' (5.0)
Lists — Glossary — Features — How To — Drivers — Components — Tools — Samples — Articles — Architecture — Issues
Categories: Index | Data Abstract | Architecture | .NET
