Angular 项目 - 为什么到处建模？

Question

我刚刚开始处理现有的 angular 项目。下面的代码只是代码如何编写的想法？他们到处都使用如下模型（此处所有业务逻辑代码）。我不明白使用这样的模型背后的逻辑。他们显然违反了 DI 规则。如果我必须在模型中注入一些东西，那么首先我必须注入组件然后我才能注入模型。我就此询问了现有团队成员之一。他说 "We did this to load component fast."

我很困惑，将所有代码移动到单独的模型中如何有助于更快地加载组件？请提供您的想法。

// play.component.ts

@Component({
    selector: 'app-play',
    templateUrl: './play.component.html',
    styleUrls: ['./play.component.css']
})
export class PlayComponent {
    public model: PlayModel;

    constructor(private formBuilder: FormBuilder, private apiDataService: ApiDataService) {
        this.model = new PlayModel(apiDataService);
        this.model.initialize();
    }
}

// play.model.ts

export class PlayModel {
    public displayedColumns: string[] = [
        'id',
        'first_name',
        'last_name',
        'avatar'
    ];
    public users: Observable<IUserList>;

    constructor (private apiDataService: ApiDataService) {

    }

    public initialize() {
        this.users = this.apiDataService.getUsers();
    }

    public refresh() {
        this.users = this.apiDataService.getUsers();
    }
}

在html他们到处都使用这样的模型

<button mat-button (click)="model.refresh()">Refresh</button>

为什么到处都是额外的模型？

Answer 1

好吧，这只是一个意见。那里有很多意见。

在 AngularJS 中，有一个 Skinny Controllers 的自以为是的概念，其中 Controller 的大部分逻辑被移动到一个服务。

您的团队可能会效仿 Angular 通过使您的组件变瘦。

查看此内容的理想方法是遵循关注点分离。这就是 Angular 团队作为 Single Responsibility Principal 推荐的内容，其中指出一些以下内容：

Do define one thing, such as a service or component, per file.

Consider limiting files to 400 lines of code.

Do define small functions

Consider limiting to no more than 75 lines.

为简单起见，只需考虑单一职责原则：

组件：组件的唯一任务是在 UI 上呈现某些内容。或者获取一些用户输入。所以只有这段代码应该写在一个Component中。所以一个组件不会有任何业务逻辑。
Service：这些服务用作您的应用程序的实用程序或业务逻辑容器。因此，与此相关的任何内容都应该放在服务中。
指令：这些通常用于增强模板的行为。因此，与此相关的任何内容都应包含在指令中。
管道：通常用于转换数据只是为了在UI上显示它而不实际改变数据。
接口：使用它们来编写数据模型。

这个列表可以继续......但希望你知道什么地方去了。

您可以考虑相应地重构您的代码。

Angular 项目 - 为什么到处建模？

Angular project - Why model everywhere?

javascript

mean-stack

angular