Odpověď na názor

Protože jednoho krásného dne se může stát, že pro tu tabulku s články budu potřebovat jiné databázové spojení než pro jiné entity aplikace.
Ne, špatně je to z úplně jiného důvodu. Špatně je to z toho důvodu, že třída Article najednou musí dělat dvě věci – 1. řeší to, co má třída Article řešit, tedy asi něco s článkem, ale za 2. řeší, jak sehnat nějaké spojení k databázi.

Problém je v tom, že stále nechápete, co návrhový vzor Dependency Injection znamená. To není žádná svatá kráva, žádné modré a červené čepičky. Problém je jenom to, že nechápete podstatu návrhového vzoru DI, místo toho se snažíte odvodit ji od některých implementací, ale neodvozujete podstatu, jenom některé průvodní jevy těch implementací.

Podstata návrhového vzoru Dependency Injection je v tom, že objekt sám neřeší, kde a jak sehnat závislosti, které potřebuje ke svému fungování. Místo toho jenom deklaruje, které závislosti potřebuje, a jejich vložení nechá na někom jiném. Není to Runtime Dependency Injection, není to Dependency Injection Container, je to jen Dependency Injection.

Mimochodem, u kompilovaných jazyků je běžné, že se dependency injection řeší už v době překladu. Aplikace díky tomu rychleji startuje, protože se při startu neřeší závislosti, ty už jsou vyřešené.

Důvod, proč se DI používá, je ten, abyste dodržel princip jedné zodpovědnosti. Tedy DI nechce předejít tomu, abyste nemusel v budoucnosti řešit problém dynamického získávání závislosti. To by vyřešil třeba návrhový vzor Factory nebo Service Locator. DI chce předejít tomu, že jedné třídě dáte dvě různé zodpovědnosti – zodpovědnost za to, co je jejím hlavním účelem, a vedle toho i zodpovědnost za to sehnat si své závislosti.