How to integrate validation with Telerik DataAccess

The Goal

The goal of this blog is to describe how to implement implicit validation of the entities in Telerik DataAccess.

The Setup

Before you begin, the Telerik DataAccess Context Extensions nuget should be installed:

Install-Package MayLily.DataAccess.ContextExtensions

The Telerik DataAccess Context Extensions nuget provides developers with a DataAccessContext, that adds additional functionality to the OpenAccessContext.

You could directly use this implementation or introduce your own one, that derives from it, in your data layer codebase.

The Implementation

Now you could instantiate a new context instance using the Fluent API introduced in the Telerik DataAccess Context Extensions:

Further information regarding the validation in Telerik DataAccess and how to use it, can be found here.

Glimpse plugin for OpenAccess ORM


Glimpse is a client-side debugger implemented in JavaScript which shows execution timings, server configuration, request data and more, all in browser, with no changes to your application code.

OpenAccess ORM and Glimpse

Once the Glimpse is installed and enabled it is very easy to start using OpenAccess ORM with it. You need to install the OpenAccess ORM plugin for Glimpse:

Install-package OpenAccess.Glimpse

We will register it in the Global.asax.cs file using the following code snippet:

The last step that needs to be done is to setup the logging for your OpenAccess ORM domain model. Helpful information on this topic can be found here.

Now you could run your application a have a look at the information logged in the OpenAccess ORM tab.

Telerik DataAccess Tab in Glimpse
Telerik DataAccess Tab in Glimpse

Additional information regarding the OpenAccess commands execution can be found under the Timeline tab.

Telerik DataAccess Timeline in Glimpse
Telerik DataAccess Timeline in Glimpse

The complete demo application can be found here.

Using OpenAccess ORM and ServiceStack

Service-Oriented Architecture

Service-Oriented Architecture is a set of services, where each service is a standalone loosely coupled unit. Each service receives one or more requests and provides responses to these requests using defined interface. SOA allows effective and flexible communication between systems regardless of technology they are built with.


ServiceStack is an open-source .NET and Mono REST Web Services framework, which provides simple, cleaner POCO-driven way of creating web services. Additional information why you should choose ServiceStack can be found here.

OpenAccess ORM and ServiceStack

It is very easy to integrate OpenAccess ORM as a persistence solution and use it from a ServiceStack web service.
Let’s start with the setup of ServiceStack, you could use the NuGet package manager to do that:

Install-Package ServiceStack

Before moving to the implementation of the service we will register it together with its dependencies. The following code snippet should be added under the Global.asax.cs file:

There are three parts in a ServiceStack service: Request DTO, Response DTO and the service implementation. In this blog post we will read category data filtered based on its identity. This means we need an appropriate request DTO:

The service will return the following response:

Note the name of the response DTO. It is constructed by appending Response to the request DTO name. This is the convention used by ServiceStack. To support automatic exception handling a ResponseStatus property is added to the response DTO class.

And here is the implementation of the service itself:

If everything is configured correctly, you could run the service and go to http://[server_uri]/get-category/1 to see your OpenAccess ORM ServiceStack web service in action.

The complete demo application can be found here.

How to integrate OpenAccess ORM and NAnt

Build Automation

Build automation is important part of software development. It encompasses many tasks – build integration, unit testing, code analysis and deployment. The goal is to automate the repetitive steps, to establish consistency and remove error-prone tasks.

Build Tools

The build tools are programs which organize the software builds by automating the build processes. Among the widely-used build tools in the .NET world are MS Build and NAnt. NAnt is an xml-based open-source build automation tool. This section describes the NAnt fundamentals.

OpenAccess ORM and NAnt

In this blog post I will demonstrate how to integrate OpenAccess ORM and NAnt. There are a few important steps that need to be implemented in order to automate an OpenAccess domain model using NAnt.

The NAnt build definition includes several targets which will be used to automate the build process for the given OpenAccess ORM domain model. A target is a set of tasks which are executable piece of code.

    • Clean target – this is an optional target. It is used to clean up the build folder;
    • Build target – builds the source files, embeds the rlinq file as a resource, defines the needed references and copies the necessary OA assemblies;
    • Enhance target – runs the OpenAccess ORM Enhancer over the built project using the rlinq file as a metadata source;

Note the exec task’s arguments listed above. They are providing the enhancer with the built assembly, which will be enhanced, and its metadata source. The metadata source will be used to obtain the metadata container which describes the domain model metadata. In this example the domain model is using an xml mapping. There can be scenarios where the model is defined using attributes or fluent mapping. It is possible to combine all of the mapping types in one OpenAccess ORM project. 

The complete demo application can be found here.