Bonjour,

Je suis développeur web, j'utilise principalement PHP et JavaScript dans mon métier. Je consacre habituellement mes projets personnels (donc mon temps libre) sur des projets en rapport avec la vie artificielle, exception faite de ce projet.
Je vous présente donc mon nouveau projet Casterlith.

Genèse

J'utilise Symfony pour mes applications PHP et celui-ci m'a été très utile, mais aujourd'hui l'usage de mes services est tel que Symfony commence à être contraignant à plus d'un point. Je veux notamment ne plus utiliser de cache dans mes applications.

J'ai donc développé un framework qui fournit les principales fonctionnalités que fournit Symfony. Il me manquait un ORM pour pouvoir réellement coder de façon fluide et ergonomique. C'est là où Casterlith rentre en jeu.

Généralités et avancement

Cet ORM permet de mapper tout ou partie de votre base de données afin de pouvoir "caster" vos tables de votre base de donnée en objets PHP qui seront automatiquement associés entre eux.

Je ne réinvente pas la roue ici, j'utilise Doctrine/DBAL pour composer mes requêtes. DBAL permet une compatibilité avec de nombreux types de bdds. Casterlith est prévu pour fonctionner en PHP 5.3 ou supérieur (testé que sous PHP 5.6 pour l'instant). Point important, il ne nécessite pas de framework particulier, vous pouvez l'intégrer à vos propres outils.

Objectifs

Casterlith en l'état est fonctionnel. Certaines améliorations pourraient être intéressantes dont notamment la possibilité d'utiliser des propriétés avec des noms différents des champs des tables.
Je ne sais pas aujourd'hui si je souhaite le faire évoluer. C'est l'usage qui le dira.

Le projet et son originalité

Mon souhait initial était de trouver un ORM simplifié, qui s'occuperait du casting automatique sans introduire de lazy loading ou de mapping magique. J'avais trouvé SPOT ORM qui semblait faire le taff, malheureusement celui ne gère pas les jointures ... en gros il fait tout sauf la seule chose qu'il est censé faire. Ah et j'avais aussi une contrainte de PHP 5.3 (voilà voilà).

Github du projet

https://github.com/merry-goblin/casterlith

-
Edité par loacast 17 janvier 2019 à 14:36:14

Salut !

Je réagis à ton projet car en tant que développeur Symfonyje me pose plusieurs questions:

- Pourquoi ne pas vouloir du cache de Symfony ? Il est qui plus est largement configurable pour le customiser selon tes besoins, le composant Cache est fait pour être adaptable selon tes besoins, et s'utilise même en dehors de Symfony, comme de nombreux composants.

- Symfony est justement devenu, particulièrement depuis sa quatrième version, très malléable, et permet notamment de n'installer que les composants dont on a besoin en s'affranchissant des surcouches inutiles. Je me demande donc quelles contraintes seraient suffisamment élevées pour nécessiter de redévelopper un nouveau framework ? Et dans ce cas, pourquoi ne pas regarder du côté de Silex ou Laravel ?

- Pour l'ORM, je ne comprends pas ce que Casterlith ferait de plus ou de mieux que Doctrine ORM, qui est découplé de Symfony et peut s'utiliser dans n'importe quel projet. Quelle est la plus-value de Casterlith ?

Je pose ces questions simplement pour éclaircir ces ponts-là, car d'un premier coup d'oeil effectivement tu vas te donner beaucoup de peine pour reproduire des choses déjà existantes. Après ça reste tout de même un super exercice et une bonne expérience !

Bon courage !

Salut Axel,

Se sont des questions légitimes que tu t es posé là et je me suis posé précisément les mêmes questions.

1. Pourquoi ne pas vouloir du cache de Symfony ? Il est qui plus est largement configurable pour le customiser selon tes besoins, le composant Cache est fait pour être adaptable selon tes besoins, et s'utilise même en dehors de Symfony, comme de nombreux composants.

C'est en rapport à mes déploiements prod. En effet, je déploie, puis juste après je vide le cache suivi d un reload apache (pour opcache). Or, entre le déploiement et le reload, des méthodes manquantes peuvent générer des erreurs php. C'est d autant plus accentué que j utilise efs, c'est le disque partagé d Amazon, il est très lent, rendant cette procédure longue.

2. Et dans ce cas, pourquoi ne pas regarder du côté de Silex ou Laravel ?

Quand j'ai développé mes applis sous symfony c'était justement pour ne pas réinventer la roue. Ce que j'utilise vraiment dans symfony c'est :

- les services

- les templates

- le routing

- l orm

- la sécurité

- le validator (oui je n'utilise pas les formulaires symfony juste le composant validator)

- les commandes

Et c'est tout ... Et tout ça je l ai récupéré avec d autres bibliothèques ou je l ai redéveloppé en peu de temps.

Sinon j avais un collègue qui avait testé silex  sur un projet. Je ne sait pas si ça venait de silex ou de l implémentation du collègue mais c était tout sauf satisfaisant.

3. Pour l'ORM, je ne comprends pas ce que Casterlith ferait de plus ou de mieux que Doctrine ORM, qui est découplé de Symfony et peut s'utiliser dans n'importe quel projet.

Casterlith fait moins que doctrine, beaucoup moins d'ailleurs.  la seule chose qu'il fait c'est le casting de la base en objets php (Avec les relations demandées bien sur). Par contre, et c'est très important pour moi comme vu précédemment, il ne fait pas de magie comme doctrine et donc pas de cache. En effet, le mapping doit être fait à la main.

4. Je pose ces questions simplement pour éclaircir ces ponts-là, car d'un premier coup d'oeil effectivement tu vas te donner beaucoup de peine pour reproduire des choses déjà existantes.

J'ai du mal m'exprimer, tout ça est déjà codé, testé et éprouvé sur des projets annexes. Franchement je ne regrette pas de m'être affranchi d'un framework.

Je ne renie pas les framework dans le sens où ils donnent une structure bien pensée et éprouvée par d'autres mais il y a aussi le petit lots d inconvénients avec lesquels il faut faire avec.

Cdt,

-
Edité par loacast 12 mars 2019 à 10:58:59

Merci pour tes réponses !

Par rapport au problème de déploiement que tu évoques, je pense que la solution doit venir de l'infra, par exemple avec des images Docker qui pourraient embarquer ton code et éviter ce genre de problème.

Bon courage en tout cas !