Как разместить правила валидации в репозитории - PullRequest
Новая
       28

Как разместить правила валидации в репозитории

0 голосов
/ 12 мая 2018

У меня есть этот объект, который включает в себя правила проверки. Оно работает. Но, похоже, что Entity - не лучшее место для хранения таких правил, потому что, если у меня есть список из 100 сущностей, этот код запускается 100 раз, что кажется ненужным.

Так что мне кажется, что лучшее место для соблюдения правил - это хранилище. У меня есть хранилище для каждой сущности, и это синглтон.

Но вопрос в том, как это сделать? 

import { type, Entity, validatedResource, association, resource, repository } from 'aurelia-orm';
import { ValidationRules } from 'aurelia-validation';
import { InviteRepository } from 'data/service/invite-repository';
import { autoinject } from 'aurelia-framework';
import { autoinject } from 'aurelia-framework';


@resource()
@repository(InviteRepository)
@validatedResource()
@autoinject()
export class Invite extends Entity {
repository: any;

    id: number;
    firstName = null;
    lastName = null;
    email = null;
    message = null;
    invitedOn: Date;

    constructor() {
        super();

        ValidationRules
            .ensure('firstName').required().satisfies(
                (value)=> this.validateFirstName(value)
            ).withMessage("First Name must be Greg")
            .ensure('lastName').required()
            .ensure('email').email()
            .on(Invite);
    }

    validateFirstName(name: string): boolean {
        return this.getRepository().validateFirstName(this.firstName);
    }

}

1 Ответ

0 голосов
/ 12 мая 2018

Существует несколько видов проверки.

Во-первых, это формальная валидация, которая должна быть выполнена для любого объекта или значения, которое должно быть обработано. Например, "имя поля обязательно для этого набора полей". Или «имя должно быть не пустым». И так далее. Эта логика проверки принадлежит фабрикам или конструкторам сущностей / значений и не нуждается во внешних вызовах.

Другой тип - проверка бизнес-правил на предмет текущего состояния системы. Например, «вы не можете добавить правило маршрутизации, которое сделало бы маршрутизацию неоднозначной». Вы можете поместить эту логику в доменные службы, если она включает в себя более одного объекта / агрегата. Или вы можете поместить его в сущность, при условии, что вы вызываете его из прикладного уровня со всеми необходимыми внешними данными для принятия решения о валидации.

Наконец, на уровне БД существуют правила, предназначенные для сохранения согласованности данных. Они естественным образом соответствуют ограничениям БД и относятся к репозиториям.

Итак, в вашем случае все будет в порядке, если поместить его в конструктор сущностей.

...