前端学堂
几乎在每个应用程序中都有一个文件，我们把所有的endpoints都放到里边。如果你正在使用Angular，它可能看起来像这样：
乍一看，一切看起来都很好，但随着应用程序的增长，这个文件也会产生一些问题。
我们违反了单一的责任。我们暴露于合并冲突，我们的端点不可移植，并且在文件中找到端点位置变得困难。
我们需要将责任分配给负责的模块，因此每个模块负责揭示其端点。
然后，我们可以在我们的API服务中汇总和加入整个端点。
让我们来看看如何在Angular 依赖注入DI和multi选项的帮助下做到这一点。
创建API服务
首先，我们需要创建负责执行聚合的服务并公开endpoint。
我们有一个InjectionToken将代表每个端点。现在让我们看看我们如何填充END_POINTS令牌。
创建验证模块
每个模块需要创建两个额外的文件。
顾名思义，这个文件将负责AuthModule
我们仍然想通过杠杆打字稿声明合并来使用打字稿的力量。
在最基本的层面上，合并将两个声明的成员机械地连接成一个同名的接口。
现在，打字稿会将每个端点合并到EndPoints接口，以便我们可以自动完成。
接下来，我们为Auth相应模块中的Angular DI 提供端点，在我们的例子中是Auth模块。
你可以把这个multi选项想象成一个数组。每当我们添加一个新的提供者，Angular将提供者推入数组中。
所以，如果我们回到我们的API服务并记录_endpoints属性，我们将看到我们在数组中有一个项目 - AuthModule。
太好了，现在我们只需要把我们的东西endpoints放到一个大对象上。
最后，我们来创建一个简单的方法来帮助我们解析url。
现在，我们可以在我们需要的每个服务中使用API服务。为了简洁起见，我已经添加了一个Todos与我们描述的过程相同的模块。
例如：
总结
在这篇文章中，我们目睹了Angular DI的强大功能，以及我们如何利用这个multi选项。有了这个变化，我们就不太容易受到合并冲突的影响，模块可以随API一起移植，使我们可以在其他应用程序中使用它们。我们也避免违反单一责任，而且我们的代码组织得更好。
