Comment ajouter ORM à un projet hérité de PHP?

Question

Nous travaillons sur un projet PHP, en développement depuis plus de 2 ans. L’équipe est à présent prête et se sent prête à passer du développement à un ORM. Parce que cela accélère vraiment le développement et vous permet de faire fonctionner par Objets sans penser en termes de code SQL et de tables de base de données la plupart du temps.

Nous avons décidé de choisir la Doctrine , car elle contient YAML. les données chargées chargent - nous en avons beaucoup besoin pour nos tests unitaires.

La principale crainte que j'ai, c’est que l’utilisation d’un nouveau framework ORM puisse ralentir les performances du site. Nous ne pouvons pas établir de connexion partagée entre la couche d'abstraction de base de données actuelle (qui utilise la syntaxe pg_connect , et non PDO - compatible). Le mécanisme de connexion à la base de données ne peut pas être basculé sur PDO-compatible, car de nombreux codes SQL sont incompatibles avec la syntaxe PDO_SQLITE.

Donc, si je comprends bien, si nous commençons à l’utiliser, le nombre de connexions à la base de données sera doublé. Je ne suis pas sûr que le serveur de base de données sera capable de gérer cela.

Que recommanderiez-vous que nous fassions dans cette situation?

Answer 1

Quelle est la pertinence de PDO_SQLITE?

Sauf si vous envisagez réellement d'utiliser le pilote SQLite, la compatibilité n'est pas requise par PDO.

Si vous n'allez pas utiliser SQLite, alors je rendrais la PDO de la couche de base de données existante compatible et je réutiliserais les connexions jusqu'à ce que vous puissiez migrer complètement vers Doctrine.

Cela dit, le niveau de connexion ne sera pas votre seul souci de performance lors du passage à un ORM. Ils sont intrinsèquement inefficaces. Je m'attendrais donc à des requêtes plus lentes, à une utilisation plus importante de la bande passante entre les serveurs d'applications et aux serveurs de base de données et à une utilisation plus importante de la mémoire au niveau de l'application en raison de la redondance des données. En fonction de votre configuration actuelle, les problèmes ci-dessus peuvent ou non être des problèmes.

Vous devriez probablement prendre ce dernier paragraphe avec une pincée de sel, car ce ne sont que des traits de caractère de ORM en général et non de Doctrine en particulier, avec lesquels je n’ai aucune expérience.

Answer 2

La chose évidente à faire est de ne pas ouvrir une connexion à une base de données avant d’en avoir besoin. Personnellement, j'utilise un code comme celui-ci:

public function connect() {
  if (!defined('CONNECT')) {
    mysql_connect(...);
  }
}

public function db_query($query) {
  connect();
  $ret = mysql_query($query);
  if (!$ret) {
    die(mysql_error());
    error_log(mysql_error() . ' - ' . $query);
  }
  return $ret;
}

pour réduire le nombre de répétitions et pour ouvrir une connexion uniquement lorsque vous en avez besoin.

Dans votre cas, vous devez commencer par casser le plus petit morceau possible. Idéalement, il doit s'agir d'une tranche verticale , ce qui signifie que cette tranche effectuera la quasi-totalité de son travail de base de données avec le nouveau code et très peu avec l'ancien. De cette façon, vous pouvez réduire au minimum le double des connexions à la base de données, ce qui vous permet d’acquérir des compétences et d’acquérir de l’expérience.

Attention, ORM n’est en aucun cas une panacée. Vous pouvez détester SQL et le trouver fastidieux et sujet aux erreurs, mais vous négociez pour la plupart simplement un ensemble de problèmes pour un autre. Personnellement, je pense que si ORM peut être utile, il a fait l’objet d’une overhyped et est davantage une fausse économie que beaucoup ne le réalisent ou ne l’admettent. J'ai écrit plus à ce sujet dans Utiliser un ORM ou un SQL pur?

Je ne dis pas que vous ne devriez pas le faire. Ne croyez pas que cela résoudra tous vos problèmes. De plus, étant donné que cette réécriture ne modifiera pas réellement la fonctionnalité (par rapport à ce que vous avez décrit), je ne suis pas sûr que le coût en résultant se compare avantageusement à la correction de ce qui existe déjà. Trop d’inconnues pour dire dans quel sens ira votre situation.

Answer 3

Eh bien, oui et non, vos connexions à la base de données ne seront doublées que si vous avez une connexion non-PDO et une connexion PDO.

Je ne suis pas sûr de comprendre ce que vous entendez par la référence à PDO_SQLITE, puisque SQLite est une base de données totalement différente de celle de PostgreSQL, il semble que vous l'utilisiez maintenant.

Vous devriez pouvoir exécuter vos requêtes actuelles avec PDO :: query exactement comme vous le faites aujourd'hui, à moins que vous ne fassiez quelque chose de très faux:)