My system currently runs in differents environments.
I got a Environment enum on my system, something like this
public enum Environment {
[UsePayPal(false)]
[ServerInstallDir("InstallPathOnServer")]
[IntegrationSystemURI("localhost/someFakeURI")]
[UpdateSomeInfo(true)]
[QueuePrefix("DEV")]
[UseCache(false)]
[AnotherSystemURI("localhost/anotherFakeURI")]
Development = 0,
[UsePayPal(false)]
[ServerInstallDir("InstallPathOnBUILDServer")]
[IntegrationSystemURI("build-server/someFakeURI")]
[UpdateSomeInfo(true)]
[QueuePrefix("QA")]
[UseCache(false)]
[AnotherSystemURI("build-server/anotherFakeURI")]
QA = 1,
[UsePayPal(true)]
[ServerInstallDir("InstallPathOnServer")]
[IntegrationSystemURI("someservice.com/URI")]
[UpdateSomeInfo(true)]
[QueuePrefix("PRD")]
[UseCache(true)]
[AnotherSystemURI("anotherservice/URI")]
Production = 2,
}
I’m working like this, because I dont like code like
if(CURRENT_ENVIRONMENT == Environment.QA || CURRENT_ENVIRONMENT == Environment.DEV)
EnableCache()
or
if(CURRENT_ENVIRONMENT == Environment.QA || CURRENT_ENVIRONMENT == Environment.DEV){
DoSomeStuff();
}
because I think that’s scatter my logic all over the system, and not on a single point.
If some day I add another Test Enviroment, I dont need to go all over my code to see if I work like on Development, QA or Production enviroment.
Ok, but, with all that config I may end up with too maby attributes on my Enum, lets say, in 3 years each enum value will have 15~20 attributes, and that looks weird.
What do you guys think? How do you usually handle this situation? Its really too many attributes, or thats ok?
Create an
Environmentclass with aprivateconstructor and as many properties as you need to describe the environment, and exposestatic readonlyinstances as public properties. You can also have anEnvironment.Currentproperty that points to one of these instances.Example code:
Use it like: