带有 REST 后端的 Angular 前端:CRUD 操作的实体设计 [英] Angular frontend with REST backend: entity design for CRUD-operations

问题描述

我正在为单页应用程序使用 Angular 12 前端和 Spring REST 后端.

I'm using an Angular 12 frontend, Spring REST backend for a Single Page Application.

如果每个 CRUD 操作的实体字段都不同，那么在 Angular 中创建实体的最佳方法是什么?

What is the best way to create entities in Angular if the fields of an entity are different for every CRUD operation?

让我们以一个用户对象为例，每个请求类型都有不同的字段:

Let's take an User-object for example with different fields for every request type:

export interface UserGet {
   id: string;
   firstName: string;
   lastName: string;
   hobbies: Hobby[];
}

export interface UserPost {
   firstName: string;
   lastName: string;
   hobbies: number[];
}

export interface UserPut {
   id: string;
   firstName: string;
   lastName: string;
   hobbies: number[];
}

export interface Hobby {
   id: string;
   hobby: string;
}

如您所见，Id 可以根据请求进行可选，hobby 的字段类型可以是 object 或 number.

As you can see, Id can be optional dependant on the request, and the field type of hobby can either be object or number.

像上面一样在 Angular 中保留三个对象更好，还是应该创建一个通用"对象?像这样的对象:

Is it better to keep three objects in Angular like above, or should I create one "common" object like this:

POST-Request 数据:

Data of POST-Request:

export interface UserCrud {
   id?: string;
   firstName: string;
   lastName: string;
   hobbies: Hobby[] | number;
}

export interface Hobby {
   id: string;
   hobby: string;
}

从长远来看，使用 Angular 12 有什么更好的方法?

What's the better approach on the long run with Angular 12?

提前谢谢

推荐答案

在我看来，UserGet、UserPost 和 UserPut 非常相似，现在你可以做一些事情，比如创建一个生成对象的服务并省略你的字段想要但我不会这样做 Hobby[] |合约(接口)上的 number 是在应用程序的其他地方发生奇怪突变的可靠方法，我通常倾向于在参数、范围变量或泛型类(例如 Subject 或类似的东西.我会使用通用接口作为基础，基本上:

In my opinion, UserGet, UserPost and UserPut are very similar, now you can do several things such as creating a service that generates the object and omits the fields you want but I would not do this Hobby[] | number on a contract (interface), is a sure way to get weird mutations to happen elsewhere in the application, I normally tend to do this on parameters, scoped variables or generic classes such as Subject<number | string> or something like that. I would use a generic interface as the base, basically:

export interface UserBase<TValue> { 
 id?: string;
 firstName: string;
 lastName: string;
 hobbies: TValue[];
}

然后您可以为每个接口设置单独的接口:

then you can have separate interfaces for each:

export interface User implements UserBase<Hobby> {};

export interface UserRequest implements UserBase<number> {};

export interface Hobby {
  id: string;
  hobby: string;
}

当然在各自的文件中.

您也可以从接口名称中删除 Http 动词，接口/对象应该根据它们的名称和目的命名，使用它的操作不应该包含在其中，因为如果在其他地方使用它会变得非常混乱应用程序，但用于不同的目的，但这是我的意见.

Also you can remove the the Http Verb from the interface name, interfaces/objects should be named for what they are and purpose the operation that makes use of it should not be included in as it can become quite confusing if used elsewhere in the application but for a different purpose, but that's my opinion.

这篇关于带有 REST 后端的 Angular 前端:CRUD 操作的实体设计的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！