Local Data Adapter
Purpose of Local DataAdapter
Data Abstract is built around the concept of multi-tier data access, where the client tier asks the middle tier (service) for data. But in some cases it is important to manipulate data locally, within the middle tier. Specially for that purpose, RO provides the Local Data Adapter component.
The Local Data Adapter (LDA) is a component for both Delphi and .NET, that allows access to data from the local service. LDA is very similar to the Remote Data Adapter (RDA). Like the RDA it knows how to request data, how to post changes back and how to handle reconciliation problems. The LDA also understands various client side technologies such as Dynamic Select, Dynamic Where and DA SQL, and – for .NET – it comes in two versions, one that supports regular DataSets, and another one that uses DA LINQ.
The key difference with RDA is that the LDA was specifically designed to work with data within the same tier, while RDA works on the client side with remote server.
When to use
Using Local Data Adapter can be helpful in several cases:
- making two tier applications (Database tier and Client tier) - in cases when you need to keep it simple, you can create an application that unifies middle and client tier in the same application. In the near future, we will provide templates for creating such single tier applications.
- using Local Data Adapter in the middle tier for implementing quite sophisticated business rules.
Tip: The LDA allows access to services that are defined "private" in the service builder as well as public ones.
How to use
Since LDA works directly against a local Data Service, there is no need to specify message and channel components. Instead, LDA needs to be directly connected to that local Data Service. There are two alternative ways to do that.
- If your code already has a reference to a concrete service instance, that reference can simply be assigned to the LDA’s ServiceInstance property, and be consumed directly. This is especially helpful when you’re using the LDA within event handlers on the Data Service or Business Processors. If your code is already executing in the context of a Data Service, so you can just use it.
- Alternatively, you can set the ServiceName string property to the name of a data service that exists within your application. As needed, the LDA will obtain a reference for this service using Remoting SDK’s regular server manager infrastructure. The LDA and RO will take care of instantiating (and releasing) the service as needed, and the regular instantiation mechanics will apply (for example, your chosen class factory will be used). This option is useful if your code does not have a reference to a service yet, for example when you are accessing data outside of a client request. In a sense, this second option more closely resembles how the RDA works – it connects to a data service by name; it just does not do it across the network, but locally.
Tip: When you are using the first approach above, that session will be inherited from the outer request, but when using ServiceName, you might need to set the SessionID and manually set up a session as expected by your service.
ServiceNamespecifies the name of the service that holds the schema and business logic.
ServiceInstancespecifies the service instance currently in use. When ServiceName is set this will be initialized when the first call is done. It's also possible to assign your own instance.
SessionIDspecifies the client ID that the service will get while running.
The .NET side represents two kinds of Local Data Adapter.
- Local Data Adapter is component that can fill and modify data using ADO.NET DataSet or/and DataTables objects.
- Linq Local Data Adapter is component that can obtain data as a generic collection of data classes using DALinq queries (like "
from r in linqLDA.GetTable<MyTable> where (r.Field == value) orderby r.OtherField"), it can also track changes inside collections and apply changes to the database.
The TDALocalDataAdapter component forms the center of communication from the client to a DataAbstract service defined in the same project. It provides all the logic for retrieving data into TDADataTables, applying changes back to the server and handling any other data-related communication with the database such as retrieving business rules scripts or schema information.
- Data Abstract Architecture
- Schemas — Data Tables — Column Mappings
- Deltas — Updates — Connections — Drivers
- Data Adapters – Data Streamers — Business Processors
- DA SQL — DA LINQ — Dynamic Select — Dynamic Where
- Data Types
- Business Rules Scripting
- Schema Modeler — DA SQL Data Browser — Relativity — Server Explorer for Mac