Les frameworks c'est génial :

  • en 1 minute on a une application "vierge" super pro qui se connecte à notre base de données
  • en 2 minutes je rajoute un écran sur mon appli
  • en 3 minutes je rajoute un web service
  • en 4 minutes je rajoute un mécanisme d'authentification SSO avec le plugin tartanpion
  • ...

ok ?

On oublie aussi :

  • en 2 mois j'apprends à coder AVEC le framework (i.e. maintenable, performant, ...)
  • en 3 mois je réalise la migration de la v1.9 du framework à la v2.0 (ca fait mal hein ?)
  • au bout de 4 mois je comprends vraiment comment ca marche et que je n'aurais pas développé telle classe comme ça si j'avais su avant :(
  • ...

toujours ok ?

Une erreur (ce n'est que mon point de vue) courante que je rencontre sur "le terrain" (i.e. chez mes clients), est l'inconditionnelle mixage entre du code applicatif (i.e. développé par vous) et du code technique (contraint par le framework).
On se retrouve alors souvent à avoir des classes MyPluginSpecificForZF par ci ou sfMonPluginParLa ... qui contient du code que vous développez qui se connecte à la base de données fait des traitements et renvoie OK ou NOK (exception, boolean, ce que vous voulez).

Une question me vient alors à l'esprit :

Pourquoi diable avez vous créé une classe (ou une fonction) dont le nom est si framework-dependant avec un contenu qui ne l'ai pas forcément toujours, et qui surtout vous est tellement spécifique que vous auriez pu le développer même si vous utilisiez un autre framework ?

Personnellement, j'aurai créé une classe autonome suivant mes conventions avec mes packages, dans mon arborescence, capitalisée dans mon dépôt de code, testé unitairement dans un contexte non framework-isé, c'est à dire beaucoup plus simplement en fait, puis, j'aurais créé la même classe que vous (enfin qu'eux), mais il n'y aurai que quelques lignes (uniquement technique, pas applicative) :

try {
    MyPackage_MyClass::factory()
        ->mySpecificMethod($param1, ...);
} catch (Exception $e) {
    // do something with the exception if this plugin
}

La même remarque me vient à l'esprit pour tous les "adapters" que l'on peut créer pour les différents frameworks.

Tout ça manque "d'illustration" ? Pensez aux centaines de lignes de code que vous (ou les autres) écrivez pour réaliser des plugins Zend Framework, Symfony, Drupal, Magento, eZPublish, Joomla, <WhatEverFrameworkYouWant>et qu'il faut (difficilement) porter à chaque nouvelle version d'un framework ou carrément réécrire quand vous changez de framework...

D'un point de vue maintenance vous y gagneriez, non ? Vous pourriez même faire des tests unitaires sur votre propre code sans devoir mettre en place des pseudo-artifices a base de XXXXControllerTest et autres, puisqu'au final vous n'auriez que votre classe à tester, pas le framework.
Mais si me dites-vous, car moi j'utilises massivement les "features" du framework dans mon code spécifique (par exemple un Mage::singleton('....')->retrouveMoiMagiquementMesProduits(...) donc je ne peux pas extraire mon code de cet endroit la car il est trop "dépendant" au framework, je vous conseillerais alors d'aller faire un tour du côté des adapters et de ne plus utiliser en direct dans votre des méthodes que vous n'avez pas développé vous même, sauf si il s'agit d'une classe dite "adapter", ...

Que les auteurs de frameworks (que j'ai été et que je suis toujours aussi ;)) ne se formalisent pas, ce que je dénonce ce ne sont pas les frameworks, mais l'usage qui en est fait, qui pour moi est le plus important à long terme (surtout quand on voit que la majorité des frameworks sont réécrits au bout de 2 ou 3 ans)

Donc, si je peux me permettre un conseil :

Ne placez jamais de code à vous dans une classe dont on vous contraint le nom ou l'héritage (extends).
Instanciez plutôt dans cette classe, une classe à vous qui est autonome et que vous avez développé par ailleurs.