Блог

В чем преимущество определения отношения «Принадлежит»?

Когда я определил HasMany отношение, я мог выполнять все свои запросы, никого не пропуская (я предпочитаю приводить пример на случай, если вы сочтете важным использовать BelongsTo отношение).

Преимущество заключается в возможности перевернуть «базовый» и «дочерний» отношения. Фильтры отношений LoopBack 4 похожи на SQL LEFT JOIN, что означает, что фильтр должен быть ограничен из базовой модели.

Из документов «Фильтрация по родительской модели»:

Где фильтры, такие как те, которые используются запросами модели ( create() , find() , replaceById() , и так далее), не могут использоваться для фильтрации модели по значению ее родительской модели. Смотрите Его проблему на GitHub.

Например, у нас может быть много заказов, сделанных клиентом:

 @hasMany(() => Order)
orders?: Order[];
 

Это отношение позволяет запрашивать «заказы, сделанные клиентом» или «заказы, сделанные списком отфильтрованных клиентов», но не наоборот; «клиент, который сделал этот заказ» или «клиенты, которые составили список отфильтрованных заказов».

Отношение «Принадлежит» решает эту проблему, создавая ключ в заказе, который ссылается на клиента:

 @belongsTo(() => Customer)
customerId: number;
 

Это означает, что теперь мы можем запросить «какой клиент сделал этот заказ» или «какие клиенты составили отфильтрованный список заказов».

Другим важным фактором является то, что отношение «Имеет много» не может быть преобразовано в сильное отношение, поскольку ANSI SQL не имеет метода представления таких отношений. Из документов:

LoopBack 4 реализует слабые отношения с @belongsTo() , @hasMany() , и т.д. @hasOne() Это означает, что ограничения применяются самим LoopBack 4, а не базовым механизмом базы данных. Это полезно для интеграции отношений между базами данных, тем самым позволяя приложениям LoopBack 4 частично выполнять роль озера данных.

Однако это означает, что неверные данные могут быть введены вне приложения LoopBack 4. Чтобы решить эту проблему, некоторые соединители LoopBack 4 (такие как PostgreSQL и MySQL) позволяют определять ограничение внешнего ключа через @model() декоратор. Пожалуйста, обратитесь к соответствующей документации соединителя для проверки совместимости.

Курсивом я подчеркиваю, почему применяются эти ограничения.