2015-12-21 23 views
10

我创建了一个需要“常量”类来包含一些配置值的项目。下面是这个类的一个摘录:注入与Angular 2的全局静态类

export class Constants 
{ 
    static Configuration = class 
    { 
     static CookieName:string = 'etl_language'; 
    }; 

    ... 

    static View = class 
    { 
     static Militaries:string = 'militaries'; 
     static Mutants:string = 'mutants'; 
     static Objects:string = 'objects'; 
     static Scientists:string = 'scientists'; 
    }; 
} 

当我与角2的组件的时候,我可以通过导入它使用类:

import {Constants} from "../../misc/constants"; 

接着,就引用它:

this.cookieName = Constants.Configuration.CookieName; 

它工作得很好,但我有,我应该使用的角2依赖注入引擎注入到在构造函数类的引用的感觉,但似乎有点矫枉过正。但是,我觉得我违反了“做法”的“角度方式”,所以我不知道我是否可以坚持我的解决方案,或者如果我必须使用DI。

有什么建议吗?

+1

随着DI你可以摆脱所有的'静态'东西,并注入相同的对象实例(单身)在任何地方。 –

回答

6

我会建议做,而不是被更改Constants类拥有只读属性,并创建他们Providers[]像这样

@Injectable() 
public class ConfigurationConstants() { 
    private _cookieName:string = 'etl_language'; 
    ... 
    get cookieName():string { 
    return this._cookieName; 
    } 
    ... 
} 

export var CONSTANTS_PROVIDERS:Provider[] = [ 
    provide(ConfigurationConstants, {useClass: ConfigurationConstants}), 
    provide(ViewConstants, {useClass: ViewConstatns}) 
]; 

然后,您可以将这些提供程序引导到您的应用程序的顶级注入器中,使其在任何需要它们的地方都可用。

import {CONSTANTS_PROVIDERS} from './constants'; 

bootstrap(App, [CONSTANTS_PROVIDERS]) 
    .catch(err => console.error(err)); 

这里有一个普拉克证明:http://plnkr.co/edit/RPjDxoIZ8wLY3DDIdhJF

编辑2: Plunker又回来了,现在我已经更新的例子

编辑: Plunkr是死的,现在这样我就可以没有更新,但在我的评论我的意思是这样的(我没有测试过,但它应该可以):

public class SubConstants() { 
    private _someString:string = 'Some String'; 
    ... 
    get someString():string { 
    return this._someString; 
    } 
    ... 
} 

@Injectable() 
public class ConfigurationConstants() { 
    private _cookieName:string = 'etl_language'; 
    private _subConstants:SubConstants = new SubConstants(); 
    ... 
    get cookieName():string { 
    return this._cookieName; 
    } 

    get subConstants():SubConstants { 
    return this._subConstants; 
    } 
    ... 
} 

// ... this would allow you to then do: 
confConstants.subConstants.someString 
// assuming you injected ConfigurationConstants as confConstants 

再次,这是更多的代码比你对内部类的建议,所以它可能是你喜欢的。

+0

旁边的“常量”类,我也有一个“语言”类应遵循相同的模式。问题是这个类包含很多内部类。有时候,你可以有一个像“Language.Materials.Metal.Name”这样的键。你的方法很有趣,但是这个类的结构会让我写很多代码。把你的方法和我的方法混合起来不是很有趣吗?我删除了我班的所有“静态”,但是我像你一样将它导出为一个班级? – ssougnez

+0

我的意思是“我从班上除去所有的静电,但是我像**一样将它注入班级”? – ssougnez

+0

就个人而言,我会避免嵌套的分类和使用组合来获得您正在寻找的嵌套键。我会用一个例子更新我的答案 – Zyzle

3

DI是可选的,但对于需要使用对象实例的情况很有用。在很多情况下,导入都可以,但DI会将实例的实例与您的代码解耦。如果您正在进行自动化测试,或者希望组件具有灵活性并接受具有给定签名的任何对象,则这是有益的。

我对DI一些更多的信息在这里如果你有兴趣: http://www.syntaxsuccess.com/viewarticle/dependency-injection-in-angular-2.0

+0

是的,这就是为什么我正在寻找一种比我目前使用的更好的方式来实现这一目标。 Zyzle的答案似乎是一个好的开始。谢谢 – ssougnez

0

我的建议,它的价值。除非你真的需要它来解决问题,否则不要使用依赖注入。

在不需要使用DI的情况下,或者更糟糕的是,为了满足一些过于苛刻的框架而在整个应用程序中系统性使用DI会导致代码难以理解。 (可能适用于任何设计模式)。

Angular的分级DI对我来说似乎特别令人震惊。一旦你的应用程序变得足够大,弄清楚什么是解决一个特定的依赖关系,以及该共享什么样的实例,将是一个渗透你整个代码库的难题。