Question

我刚刚开始研究现有的角度项目。下面的代码只是如何编写代码的想法？他们在每个地方都使用了如下所示的模型（此处为所有业务逻辑代码）。我没有得到像这样使用模型的逻辑。他们显然违反了DI规则。如果必须在模型中注入某些东西，那么首先我必须注入组件，然后才能注入模型。我问了一位现有的团队成员。他说：“我们这样做是为了快速加载组件。”

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

// 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，其中指出了以下内容的一些：

请为每个文件定义一件事，例如服务或组件。

考虑将文件限制为400行代码。

定义小功能

考虑限制为不超过75行。

为简单起见，请考虑“单一责任原则”：

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

此列表可能会继续下去...但是希望您对下一步的想法有所了解。

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

Answer 2

作为一个终身面向对象的人，我发现在Angularjs中看到具有数百甚至数千行代码的控制器非常令人震惊。这是Java语言在那些不愿意学习OOP的人的证明。特别是SOLID主体。他们也没有真正了解控制器的作用。

当Typescript出现时，智能的力量在Javascript世界中得到了体现。类（后来成为ECMA 6的一部分）打开了模型并查看了模型概念。模型是视图的绑定机制。而视图模型要么包含模型，要么通过动作来实现。 Intellisense支持单一职责，因为它会在您键入时找到其中的所有类和功能。没有更多重复的代码支持单一职责。现在，类可以直接与服务竞争，因为它们是可重用的，并且可以在任何需要的地方寻址。它们可以是静态的也可以是动态的，最终可以完全转移到任何项目。

如果我们将角形组件视为一个或多个类组成的容器，我们已经实现了每种复合材料的正确封装，这样我们就可以添加或删除所需的东西而不会影响任何其他复合材料。

这绝不会损害“功能”的所有内容，因为即使在OOP中，持续重构也最终会“功能”的所有内容。纯函数式编程是单一职责的化身。

道德是：课程很棒。它们可以只是模型，也可以是视图模型（具有功能的模型）。到处都是纯功能，只有一个关注点。类可以是仅包含函数的实用程序。实现用于DI的接口，您就可以开始构图了。使用预制零件总比制造新零件好。

下一个主要的Java语言浪潮是泛型。对于泛型，事物的类型无关紧要，这就是它完成的工作。我们在lodash中看到了这种行为。

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

2 个答案: