Arggg, tellement de choses à contredire dans ce que tu dis. Cherches-tu la vérité ou souhaites-tu juste valoriser tes expériences .Net ?
J'veux bien être pédagogue mais c'était pas l'objet de ton topic à l'origine et j'voudrai pas que ça passe pour de la condescendance ou quoi, dis moi si tu veux qu'on creuse cette histoire de .Net > PHP parce que Zend_Db2 et MVVM

Sinon le reformat, d'après la doc c'est Ctrl + Alt +L. Moi j'peux pas dire, j'ai binddé les raccourcis Eclipse (oui, la réduction de ma dépendance commence mal)

Alors, y'a plusieurs choses. Je participe à un logiciel Galette où je n'ai pas choisie la techno qui est grosso modo PHP + Zend_DB2 + Smarty 3.
Autant, PHP + Smarty 3, j'y arrive assez bien et je trouve ça assez confortable et pratique à utiliser, j'aime bien Smarty, il a des fonctions agréables à utiliser pour les foreach, le code Smarty est assez clean et c'est facile de balancer des infos vers Smarty. On a vraiment un code productif PHP d'un côté, et un code HTML de l'autre. Rien à redire la dessus.
Par contre, j'ai eu beaucoup de mal à m'habituer à Zend_DB (qui dans ce cas ne fait que l'interface avec la BDD, et rien d'autre).
Surtout là, je rage parce que je dois passer de Zend_DB1 à Zend_DB2 et que ce qui marchait avant ne marche plus du tout et je dois tout reécrire.

Alors, autant changer un insert ou une mise à jour de :

$add = $zdb->db->insert(PREFIX_DB . LEND_PREFIX . self::TABLE, $values);
$this->_object_id = $zdb->db->lastInsertId();

vers

$insert = $zdb->insert(LEND_PREFIX . self::TABLE)
         ->values($values);
$add = $zdb->execute($insert);
$this->_object_id = $zdb->driver->getLastGeneratedValue();

c'est pas trop compliqué.

Le système de where a changé, avant on enchainait les where et ça faisait du and, maintenant, on doit tout mettre dans un seul where avec une array, ce qui fait qu'avant j'avais cette jolie query:

$select_count = new Zend_Db_Select($zdb->db);
$select_count->from(PREFIX_DB . LEND_PREFIX . LendObject::TABLE, array('count(*)'))
        ->where('is_active = 1')
        ->where(PREFIX_DB . LEND_PREFIX . LendObject::TABLE . '.category_id = ' . PREFIX_DB . LEND_PREFIX . self::TABLE . '.' . self::PK);

$select = new Zend_Db_Select($zdb->db);
$select->from(PREFIX_DB . LEND_PREFIX . self::TABLE, array('*', 'nb' => new Zend_Db_Expr('(' . $select_count . ')')))
        ->where('is_active = 1')
        ->order('name');

et que maintenant elle ressemble à ça:

$select_count = $zdb->select(LEND_PREFIX . LendObject::TABLE)
        ->columns(array(new Zend\Db\Sql\Predicate\Expression('count(*)')))
        ->where(array(
    'is_active' => 1,
    new Zend\Db\Sql\Predicate\Expression(PREFIX_DB . LEND_PREFIX . LendObject::TABLE . '.category_id = ' . PREFIX_DB . LEND_PREFIX . self::TABLE . '.' . self::PK)
));

$select = $zdb->select(LEND_PREFIX . self::TABLE)
        ->columns(array('*', 'nb' => new Zend\Db\Sql\Predicate\Expression('(' . $zdb->sql->getSqlStringForSqlObject($select_count) . ')')))
        ->where(array('is_active' => 1))
        ->order('name');

J'ai réussi, mais j'ai juste galéré pour retrouver le même fonctionnement.

Dans le projet indiqué, les classes sont écrites de telles manières, qu'il y a une variable privée $_machin sans membre public et que l'accès/écriture sur la variable se fait via les super fonctions __get($name) / __set($name), et moi comme un idiot, j'ai repris le système dans mes classes car je découvrais le système de classe dans PHP et l'autocomplétion, tu peux te la mettre bien profond, parce qu'elle ne voit pas la variable privée $_machin (logique) et donc ne te propose pas $objet->machin. Et ça me gonfle royalement, pour chaque membre de la classe, tu dois aller voir dans la classe si tu t'es pas gouré. Et pour couronner le bazar, l'auteur du logiciel a transformé les noms des membres par rapport à la table SQL, donc au lieu d'avoir un $adherent->nom_adh (nom_adh étant la colonne SQL), tu dois mettre un $adherent->name (la vraie variable, c'est une privée $_name).

Ensuite le problème d'architecture de PHP c'est que les variables ne sont pas fortement typées, tu peux avoir une variable $n à qui tu vas affecté un chiffre, puis une string, puis un objet, puis un bool, il ne va jamais râler. Tu sais jamais à l'avance ce que tu vas avoir

Et pour terminer sur ma comparaison .Net, forcément elle est biaisée, parce que ce que je fais, c'est de l'applicatif lourd, c'est pas du Web.

Marrant que tu participes à galette, je l'utilise pour mon asso :)

Attention dans tes comparaisons tout de même entre PHP et Zend.
Et bon courage pour ta migration (si elle est encore en cours).

Yaug, plus Symfony que Zend

PetitCalgonAutant, PHP + Smarty 3, j'y arrive assez bien et je trouve ça assez confortable et pratique à utiliser, j'aime bien Smarty, il a des fonctions agréables à utiliser pour les foreach, le code Smarty est assez clean et c'est facile de balancer des infos vers Smarty. On a vraiment un code productif PHP d'un côté, et un code HTML de l'autre. Rien à redire la dessus.
Par contre, j'ai eu beaucoup de mal à m'habituer à Zend_DB (qui dans ce cas ne fait que l'interface avec la BDD, et rien d'autre).
Surtout là, je rage parce que je dois passer de Zend_DB1 à Zend_DB2 et que ce qui marchait avant ne marche plus du tout et je dois tout reécrire.

Alors du coup là tu parles de l'architecture de ton appli en particulier et non pas des qualités inhérentes des langages. Il faut savoir pour qui n'est pas habitué à PHP que toute appli uniquement basée sur Zend Framework a de bonnes chances d'avoir 5 ans de retard sur une architecture à l'état de l'art.
En particulier, Zend DB qui n'est pas un framework de persistance mais un composant d'abstraction de BDD (et un pas terrible, en plus ). Du coup je peux pas te contredire, Zend DB c'est moyen, mais ça n'a rien à voir avec ce que tu disais dans les messages du dessus.
En PHP aujourd'hui, il y a en gros un seul framework de persistance en pattern Entity Manager qui vaut le coup à mes yeux, c'est Doctrine. Les autres ne sont pas matures ou sont de l'Active Record (Zend DB, Propel) ce qui est très discutable en matière de conception orientée objet.

PetitCalgonDans le projet indiqué, les classes sont écrites de telles manières, qu'il y a une variable privée $_machin sans membre public et que l'accès/écriture sur la variable se fait via les super fonctions __get($name) / __set($name), et moi comme un idiot, j'ai repris le système dans mes classes car je découvrais le système de classe dans PHP et l'autocomplétion, tu peux te la mettre bien profond, parce qu'elle ne voit pas la variable privée $_machin (logique) et donc ne te propose pas $objet->machin. Et ça me gonfle royalement, pour chaque membre de la classe, tu dois aller voir dans la classe si tu t'es pas gouré. Et pour couronner le bazar, l'auteur du logiciel a transformé les noms des membres par rapport à la table SQL, donc au lieu d'avoir un $adherent->nom_adh (nom_adh étant la colonne SQL), tu dois mettre un $adherent->name (la vraie variable, c'est une privée $_name).

Encore une fois, tout ça est issu des choix du développeur de ton appli qui a choisi les magic methods. Défini donc des getters/setters explicites dans tes entités, ça prend trois clics dans ton IDE et ça fera plaisir à l'autocomplete et à la phpDoc
Je sais bien que ça sera syntaxiquement pas aussi joli que les properties de C# mais ça fait le boulot tout aussi bien

PetitCalgonEnsuite le problème d'architecture de PHP c'est que les variables ne sont pas fortement typées, tu peux avoir une variable $n à qui tu vas affecté un chiffre, puis une string, puis un objet, puis un bool, il ne va jamais râler. Tu sais jamais à l'avance ce que tu vas avoir

Tu parles du typage dynamique qui n'est pas directement lié à PHP mais qu'on retrouve dans tous les langages de script. Python fait pareil et même les très hypes Ruby et Scala. On a aussi souvent reproché le typage faible (additionner une chaîne et un entier) à PHP alors que c'est l'une des principales raisons qui ont fait son succès en diminuant les barrières à l'apprentissage de la programmation. Il est clair que quand on prend du skill le typage faible est loin d'être un avantage.
En revanche si tu fait du PHP orienté objet ce n'est pas tellement un problème, car les opérations entre deux objets sont rarement définies et car on peut (on doit) utiliser le type hinting dans la déclaration des méthodes, ce qui permet de sécuriser ton code à la manière des langages "managés" Java/C#.

PetitCalgonEt pour terminer sur ma comparaison .Net, forcément elle est biaisée, parce que ce que je fais, c'est de l'applicatif lourd, c'est pas du Web.

PHP a un nombre de défauts historiques incalculable. En revanche je l'utilise, moi aussi, pour faire de "l'applicatif lourd", tout comme j'utilise Java EE et parfois (mais moins souvent, j'avoue) C#. C'est pas une question d'IDE ou de conception du langage, c'est une question de comment le développeur utilise les outils qu'on lui met à disposition. En PHP on peut faire de l'entity manager, de l'injection de dépendances (coucou Yaug, moi aussi j'fais du Symfony ), de l'architecture n-tiers, il me faut rien d'autre pour pondre une architecture qui tient debout et qui restera maintenable sur des années, même dans une "application lourde" qui implique des dizaines de composants orientés services.

En revanche je t'accorde qu'à cause de sa permissivité il est plus simple de faire de la m*rde en PHP que dans de nombreux autres langages, mais pour éviter ça il vaut mieux former les développeurs : c'est pas la faute de l'IDE

Belle réponse :)

Pour aller plus loin, la facilité d'apprentissage de PHP, c'est ce qui fait que "tout le monde" en fait. Et que tu coup il y a beaucoup de mauvais développeurs sur le marché. Trouver un cador, c'est tout de même bien compliqué :)
Après, on a tous débuté avec du code sale, moi le premier ! (comment ça je continue ? ...) il faut juste apprendre à aller plus loin, et à se servir des bons outils. Clairement, dans galette, j'ai trouvé le code pas terrible mais fonctionnel, tout est une questions de choix des outils.

Avec la dernière génération de framework (j'aurais tendance à dire Symfony en tête, mais je ne suis pas forcément objectif), et les dernières versions de PHP, on arrive quand même à quelque chose qui commence à être bien costaud et permet d'aller de plus en plus loin niveau technicité.
C'est pour ça que quand j'entends des adeptes de Java ou de .NET entrer en mode blague facile sur PHP, ça me fait doucement rire de voir des mecs qui restent sur des à prioris vieux de 5 ou 10 ans.

Et pong Fabe le symfoniste !

Je suis bien d'accord, c'est au contact d'autres développeurs, en faisant des codes-reviews, etc. qu'on devient meilleur dans son langage.
Effectivement, j'ai commencé surement comme beaucoup de monde sur PHP parce qu'il était simple et facile à utiliser. Je codais mes requêtes SQL comme un porc, puis j'ai découvert qu'on pouvait faire de bien belles choses avec des index, des group by, des join left, etc.
Puis un jour je suis passé sur Galette et j'ai naïvement pensé que la façon d'utiliser/d’implémenter l'objet en PHP n'était pas forcément mauvaise (vu que j'avais mon expérience C# mais zéro en PHP) et j'ai commencé à implémenter ainsi sans trop me poser de questions.
Il me manque encore et toujours des codes-reviews pour m'améliorer et apprendre de mes erreurs. Là, je galère de temps à autres et lire la doc de Zend DB 2 ne me passionne pas et ne me permet pas de trouver ma réponse
Et oui, on doit surement pouvoir être un sacré goret avec le C#, c'est une évidence
Merci

Fabe Défini donc des getters/setters explicites dans tes entités, ça prend trois clics dans ton IDE et ça fera plaisir à l'autocomplete et à la phpDoc

J'en reviens à ce point: how ?

private $_name;
/**
 * Gets or sets the name
 **/
public property Name {
     get { return $this->_name; }
     set { $this->_name = $value; }
}

PetitCalgonJ'en reviens à ce point: how ?

private $_name;
/**
 * Gets or sets the name
 **/
public property Name {
     get { return $this->_name; }
     set { $this->_name = $value; }
}

/** @var string */
private $name;

public function getName() {
    return $this->name;
}

public function setName($name) {
    $this->name = $name;
}

What else ?

Et dans PHPStorm (par exemple) : Clic droit > Generate > Getters and Setters...

Ben oui, mais ça marche avec smarty ça?
Dans mon code Smarty, je met {$membre->getName()} ?
Je trouve ça très verbeux, je préfère la version "courte" {$membre->Name} (ou {$membre->name}. Is that possibeul?

PetitCalgonBen oui, mais ça marche avec smarty ça?
Dans mon code Smarty, je met {$membre->getName()} ?
Je trouve ça très verbeux, je préfère la version "courte" {$membre->Name} (ou {$membre->name}. Is that possibeul?

Je connais pas Smarty, mais on m'a dit qu'il était devenu moderne. Si il fonctionne comme la plupart des moteurs de templating, tu devrais pouvoir utiliser "membre.name", afin qu'il retombe naturellement sur le getter getName() (par convention de nommage).
En revanche, le "$" dans ton code semble indiquer que Smarty te laisse écrire directement du code PHP dans ses templates (beurk), ce qui signifierai que tu sois bien obligé d'utiliser le getter explicitement.

Plus qu'à RTFM !

Non, smarty ne permet pas de caler du php dedans ... ! Je déteste smarty !

Oui, oui, séparation controller et vue, oui, mais dans certains cas c'est pas fait tout à fait comme ça (coucou ma personnalisation sur une base de piwigo), et j'ai juste haï les contraintes ubuesques et la syntaxe imbitable de smarty quand j'avais les mains dedans. Bon, après, je ne sais pas la version de smarty qu'utilise piwigo et de quand date le système (probablement d'a long time ago), mais c'était juste chiant et ressemblant à une bataille contre des moulins à vents quand je m'y suis frotté.

En ce moment, je suis sur un projet laravel, je découvre le framework ce faisant, et le système de template (blade) est quand même un (gros) cran au dessus ... et bien plus lisible je pense même pour un non-dev' qui devrai modifier le template.