几乎在每个应用程序中都有一个文件,我们把所有的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
一起移植,使我们可以在其他应用程序中使用它们。我们也避免违反单一责任,而且我们的代码组织得更好。