2015-12-21 69 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對我來說似乎特別令人震驚。一旦你的應用程序變得足夠大,弄清楚什麼是解決一個特定的依賴關係,以及該共享什麼樣的實例,將是一個滲透你整個代碼庫的難題。