At some point your configuration just becomes code in a domain specific language. They talk about a new employee picking things up pretty quickly - it's not because they used configuration instead of code, it's because they have a sensible architecture.
If your "configuration" is powerful enough to do everything you need then it's Turing-complete and is just "code" by another name. If it's not powerful enough then you'll need to drop down into the code layer pretty frequently anyway.
This notion gradually descended my team into hell back when I was on a project using Spring.NET, which actually does have a Turing-complete config DSL. But that wasn't the main problem, the main problem was how much configuration was needed to do absolutely anything. Mountains of it.
Create a component, then tell the framework how to instantiate it, then tell the framework to instantiate one and give it a name, then pass that name into anything that needs one.... blech.
Comments
At some point your configuration just becomes code in a domain specific language. They talk about a new employee picking things up pretty quickly - it's not because they used configuration instead of code, it's because they have a sensible architecture.
If your "configuration" is powerful enough to do everything you need then it's Turing-complete and is just "code" by another name. If it's not powerful enough then you'll need to drop down into the code layer pretty frequently anyway.
This notion gradually descended my team into hell back when I was on a project using Spring.NET, which actually does have a Turing-complete config DSL. But that wasn't the main problem, the main problem was how much configuration was needed to do absolutely anything. Mountains of it.
Create a component, then tell the framework how to instantiate it, then tell the framework to instantiate one and give it a name, then pass that name into anything that needs one.... blech.