Data Access has been discontinued. Please refer to this page for more information.

How to: Extend the DTO Layer

This article is relevant to entity models that utilize the deprecated Visual Studio integration of Telerik Data Access. The current documentation of the Data Access framework is available here.

This topic describes how to extend the classes generated for the DTO Layer.

This topic applies to WCF Plain, Atom and RESTful Collection Services only.

Using Partial Classes

When working with automatically generated source (like the classes generated by the Service Wizard), code can be added to the class without having to modify the source file. Visual Studio uses this approach when creating Windows Forms, Web Service wrapper code and so on. You can create code that uses these classes without having to edit the file created by Visual Studio. Using partial classes is a perfect solution for separating auto-generated code from developer code. The most compelling reason for using a partial class is to separate your application business logic from the designer-generated code.

DTO Layer Classes That Could Be Extended

This section makes an overview of the DTO layer classes that could be extended.


The Assemblers can convert back and forth from DTOs to Telerik Data Access entities.

By default, the generated DTO layer doesn't include support for navigation properties. The Telerik Data Access Add Service Wizard provides code that can populate collections on entities and it is generated in the assemblers. However it is not plugged in and not executed by default. So, if you want to include support for navigation properties, you need to extend the generated assembler classes. For example:

using WcfPlainRelationships.Web.Assemblers;
using WcfPlainRelationships.Web.Dto;
namespace WcfPlainRelationships.Web
   public partial class ProductAssembler : ProductAssemblerBase, IProductAssembler
       public override ProductDto Assemble(Product entity)
           ProductDto productDto = base.Assemble(entity);
           if (entity.Category != null)
               productDto.Category = new CategoryAssembler().Assemble(entity.Category);
           return productDto;
Imports WcfPlainRelationships.Web.Assemblers
Imports WcfPlainRelationships.Web.Dto
Partial Public Class ProductAssembler
    Inherits ProductAssemblerBase
    Implements IProductAssembler
    Public Overrides Function Assemble(ByVal entity As Product) As ProductDto
        Dim _productDto As ProductDto = MyBase.Assemble(entity)
        If entity.Category IsNot Nothing Then
            _productDto.Category = New CategoryAssembler().Assemble(entity.Category)
        End If
        Return _productDto
    End Function
End Class


Repositories are used for retrieving, adding and deleting objects from the database and in order to do so they have a single dependency on the UnitOfWork implementation. If you want to add custom CRUD methods, this is the place to do it.


A service class is implemented for each entity, it exposes CRUD operations using DTO objects to the outside. It is the glue that holds together both the Assemblers and Repositories and is the perfect place for a customer to add domain logic to this DTO layer.


The actual implementation of all DTO classes. You could extend these classes by adding additional custom properties. For example:

public partial class CarDto
   public string Summary
           return this.Make + " " + this.Model;
Partial Public Class CarDto
 Public ReadOnly Property Summary() As String
   Return Me.Make & " " & Me.Model
  End Get
 End Property
End Class