Creating Domain Model

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.

The Telerik Data Access Domain Model uses five key concepts to describe the structure of a domain model: entity, property, association, navigation property and context. These are the most important concepts in describing the structure of data in the domain model.

Entity/Domain Class/Persistent Class/Persistent Type

The entity is the fundamental building block for describing the structure of data within the domain model. Entities are constructed from properties and describe the structure of top-level concepts, such as products and orders in a business application. Simply, you can consider domain model entities as regular CLR classes.

Property

Entities contain properties that define their structure and characteristics. For example, a Product entity may have properties such as ProductId, Name, Picture, etc. Properties define the shape of the class and carry information about objects.

Association

An association type (also called an association) is the fundamental building block for describing relationships in the Telerik Data Access Domain Model. Associations define relationships between persistent types in the domain model. Associations can only have two participating types, and each participating type in the association is known as an End (Source and Target). Associations are represented on the design surface as a line that connects two persistent types.

A navigation property is a property on a persistent class that allows navigation from one end of an association to the other end (e.g. product.Category).

Context/OpenAccessContext

The OpenAccessContext represents the container defined in the conceptual model. It contains a connection to the underlying data source and provides services such as change tracking and identity resolution. When you generate a new Telerik Data Access Domain Model, a class that derives from the base OpenAccessContext class is created for you. This class is simply called context or OpenAccessContext. You use the context class as an entry point to the underlying database. You use the context class for Create, Read, Update and Delete operations (CRUD operations).

How to Create a Domain Model

Basically, when you use Telerik Data Access, you have two main scenarios. Recall that when you start the Create New Domain Model wizard, the first step is to choose the Telerik Data Access domain model type.

In the first case (Populate from database), you have a legacy database and you want to generate a domain model based on that database. To meet the needs of developers who want to derive a domain model from an existing database, Telerik Data Access provides a set of modeling tools that generate a domain model, validate a domain model, and create persistent classes based on the storage (database) model. This is also known as Database First Scenario.

In the second case (Empty domain model) you don't have a database in advance. You start working from scratch with your object model and just create your new relational database from that model. Telerik Data Access gives you the ability to create a conceptual model first and then derive the storage model (the database). This approach is known as Model First Scenario.

Database First Scenario

Database First Approach (also known as Reverse Mapping) allows you to start with your legacy database. The reverse mapping experience begins the minute you connect your new Visual Studio project to the legacy database using the Create Data Model wizard. Telerik Data Access recognizes the data model, data types and additional information like keys and creates the matching object model. Then you can start designing and developing your new .NET application.

Model First Scenario

Model First approach (also known as Forward Mapping) allows you to start working from scratch with your object model and just creates your new relational database with an optimized data schema. You don’t need to think in relations anymore, but you still can. Telerik Data Access optionally allows you to define almost any kind of schema and you can influence the given names of tables or columns.

In this section: