类似 endpoint url 的东西可能是一般 配置 文件的一个很好的例子。
在我的 Angular 2 应用程序中,我使用了依赖注入。在这种情况下,我有类似 app.config.ts 的东西,使用 OpaqueToken 使其可注入:
import { OpaqueToken } from '@angular/core';
export interface IAppConfig {
appTitle: string;
endpointUrl: string;
};
export const CONFIG: IAppConfig = {
appTitle: 'MyApp',
endpointUrl: 'http://api.myrealservice.com/'
};
export const LOCALCONFIG: IAppConfig = {
appTitle: 'MyApp (LOCAL)',
endpointUrl: 'http://localhost:8080/api/'
};
export let APP_CONFIG = new OpaqueToken('app.config');
这样你可以有几个配置(例如本地开发或生产等),并将其定义为你的模块中的提供者,如下所示:
providers: [
...,
{
provide: APP_CONFIG,
useValue: CONFIG
},
...
]
然后我只需在我可能需要的地方注入此配置,例如在后端服务中使用 endpointUrl:
...
constructor(@Inject(APP_CONFIG) private _config:Config) {
console.log(this._config.endpointUrl);
}
在您的模块中,您只需更改您想要提供的配置类型(在此示例中为 CONFIG 或 LOCALCONFIG),而不必再在其他任何地方进行更改。
希望这会有所帮助。
在您编辑之后,您添加了第二个问题或者我应该创建其他一些使用 http 的 managerService 吗?:
简短的回答:是的。您应该尽可能将组件、服务等的逻辑分开。
假设您有一个提供有关猫和狗的信息的 API。你想在你的前端拥有的可能是CatService、DogService 和BackendService 或ApiService,无论你想怎么称呼它。
CatService 和 DogService 是您的视图组件将与之交互的对象,例如它们将具有 getCatById() 之类的方法或类似的方法。这些服
所以您的BackendService 是必须知道具体网址、处理响应或错误并将结果报告给调用服务的人,而其他人将仅用作管道并处理特定业务逻辑。