Auch wenn es gestern Abend in dem Vortrag von Pierre Minnieur bei der Symfony Usergroup Hamburg im wesentlichen um das Thema „Bundles are not Plugins“ ging, hab ich dort für mich einen ganz anderen Aspekt mitgenommen, der meiner Meinung nach häufig von Entwicklern vergessen wird, die sich im wesentlichen in einer Frameworkwelt, sei es Symfony, Zend, Flow3 oder was auch immer, bewegen.
Routiniert packt man seine Funktionen in z.B. Symfony Bundles, nutzt die dort vorgegeben Methoden der Vererbung, Strukturierung, etc. und verwendet bestenfalls diese Bundles sogar in mehr als einem Projekt. Bis hier hin eine schöne Welt! Aber was passiert, wenn ich wesentliche Funktionalitäten aus meinem Bundle nun in einem Zend Projekt verwenden will?
Man merkt, eigentlich haben wesentliche Codebestandteile aber so gar nichts in einem Bundle zu suchen, sondern sind für eine gute Wiederverwendung viel besser in einer eigenständigen Library aufgehoben. Nun ist lediglich ein schlanker „Wrapper“, im Falle Symfony ein Bundle, nötig, welches die Funktionalität der Library in den Kontext des Frameworks hebt. Der Code, der sich an ein spezielles Framework bindet, ist deutlich reduziert und die Library wird hoffentlich häufiger wiederverwendet, da diese mit geringem Aufwand auch in anderen Frameworks einfach eingebunden werden kann.
Wesentlicher Grund gegen so ein Vorgehen mag in der Vergangenheit das Fehlen, bzw. die fehlende Akzeptanz von Werkzeugen wie Composer gewesen sein. Mit Composer und Packagist scheint sich in der PHP Welt so langsam eine Entsprechung von Maven und Apache Commons durchzusetzen, so dass zu hoffen bleibt, dass wir bald alle einfach und schnell tolle Libraries in unseren Lieblingsframeworks benutzen können.