Repository Decorators

As a domain-driven designconcept, the repository is a layer between your domain object and data mappinglayers that uses a collection-like interface for accessing domain objects.

In LoopBack, a domain object is usually a TypeScript/JavaScript Class instance.A typical example of a data mapping layer module could be a database’s node.jsdriver.

LoopBack repository encapsulates your TypeScript/JavaScript Class instance andthe methods that communicate with your database. It is an interface to implementdata persistence.

Repository decorators are used for defining models (domain objects) for use withyour chosen datasources and for the navigation strategies among models.

If you are not familiar with repository related concepts like Model, Entityand Datasource, see LoopBack concept Repositories tolearn more.

Model Decorators

Model is a class that LoopBack builds for you to organize the data that sharesthe same configurations and properties. You can use model decorators to define amodel and its properties.

Model Decorator

Syntax: @model(definition?: ModelDefinitionSyntax)

Model decorator is a class decorator. In LoopBack 4, we inherit the modeldefinition format from LoopBack 3, which is described in theModel definition JSON file.For usage examples, see Define Models.

Please note we will elaborate more about model and model definition in theModel page, and replace the link above with a LoopBack 4 link

By using a model decorator, you can define a model as your repository’smetadata, which then allows you to choose between two ways of creating therepository instance:

• Inject your repository and resolve it with the datasource juggler bridgethat’s complete with CRUD operations for accessing the model’s data. A usecase can be found in this section:Repository decorator

• Define your own repository without using the datasource juggler bridge, anduse an ORM/ODM of your choice.

// Missing example here
// Will be provided in Model.md
// refer to [example code](https://github.com/strongloop/loopback-next-example/blob/master/services/account-without-juggler/repositories/account/models/Account.ts)

Property Decorator

Syntax: @property(definition?: PropertyDefinition)

The property decorator defines metadata for a property on a Model definition.The format of property definitions can be found inProperty definitions

For usage examples, see Define Models.

Repository Decorator

Syntax:

@repository(modelOrRepo: string | Class<Repository<Model>> | typeof Entity, dataSource?: string | juggler.DataSource)

This decorator either injects an existing repository or creates a repositoryfrom a model and a datasource.

The injection example can be found inRepository#controller-configuration.

To create a repository in a controller, you can define your model and datasourcefirst, then import them in your controller file:

src/controllers/todo.controller.ts

import {Todo} from '../models';
import {db} from '../datasources/db.datasource';
import {repository, EntityCrudRepository} from '@loopback/repository';
export class TodoController {
  @repository(Todo, db)
  todoRepo: EntityCrudRepository<Todo, number>;
  // ...
}

If the model or datasource is already bound to the app, you can create therepository by providing their names instead of the classes. For example:

// with `db` and `Todo` already defined.
app.bind('datasources.db').to(db);
app.bind('models.Todo').to(Todo);
export class TodoController {
  @repository('Todo', 'db')
  repository: EntityCrudRepository<Todo, number>;
  // etc
}

Relation Decorators

The relation decorator defines the nature of a relationship between two models.

Relation Decorator

Syntax: @relation

Register a general relation.

This feature has not yet been released in alpha form. Documentation will beadded here as this feature progresses.

BelongsTo Decorator

Syntax:@belongsTo(targetResolver: EntityResolver<T>, definition?: Partial<BelongsToDefinition>)

Many-to-one or one-to-one connection between models e.g. a Todo model belongsto a TodoList model. See BelongsTo relation formore details.

todo.model.ts

import {belongsTo} from '@loopback/repository';
import {TodoList} from './todo-list.model';
export class Todo extends Entity {
  // properties
  @belongsTo(() => TodoList)
  todoListId: number;
  // etc
}

HasOne Decorator

Syntax:@hasOne(targetResolver: EntityResolver<T>, definition?: Partial<HasOneDefinition>)

One-to-one connection between models e.g. a TodoList model has oneTodoListImage model. See HasOne relation for moredetails.

todo-list.model.ts

import {hasOne} from '@loopback/repository';
import {TodoListImage} from './todo-list-image.model';
export class TodoList extends Entity {
  @property({
    type: 'number',
    id: true,
  })
  id?: number;
  // other properties
  @hasOne(() => TodoListImage)
  image?: TodoListImage;
  // etc
}

todo-list-image.model.ts

import {belongsTo} from '@loopback/repository';
import {TodoList} from './todo-list.model';
export class TodoListImage extends Entity {
  @property({
    type: 'number',
    id: true,
  })
  id: number;
  // other properties
  @belongsTo(() => TodoList)
  todoListId: number;
  // etc
}

HasMany Decorator

Syntax:@hasMany(targetResolver: EntityResolver<T>, definition?: Partial<HasManyDefinition>)

One-to-many connection between models e.g. a TodoList model has many of theTodo model. See HasMany relation for more details.

todo-list.model.ts

import {hasMany} from '@loopback/repository';
import {Todo} from './todo.model';
export class TodoList extends Entity {
  @property({
    type: 'number',
    id: true,
  })
  id?: number;
  // other properties
  @hasMany(() => Todo)
  todos?: Todo[];
  // etc
}

todo.model.ts

import {belongsTo} from '@loopback/repository';
import {TodoList} from './todo-list.model';
export class Todo extends Entity {
  // other properties
  @belongsTo(() => TodoList)
  todoListId: number;
  // etc
}

Other Decorators

The following decorators are not implemented yet. To see their progress, pleasego to theRelations epic.

• @embedsOne
• @embedsMany
• @referencesOne
• @referencesMany