Discussion :

[dream_moon]

bonjour

Zend_Db_Table_Abstract exige que les tables aient une clé primaire,
ce qui n'est pas le cas des vues (de données)

mais les vues sont nécessaires pour optimiser le modèle,
séparer la logique, et surtout éviter les jointures, ce qui simplifie l'écriture des classes
à condition de pouvoir les manipuler dans Zend
cela ferait alors gagner du temps dans le développement, en ne faisant que des classes avec des select simples, la compléxité des jointures étant masquée par les vues

mais évidemment sans clé primaire j'ai toujours des exceptions
comment faites vous pour utiliser les views avec zend ?

j'ai bien cherché sur gogol mais je tombe toujours sur la view du modèle et non de la base

faut il utiliser une autre classe que Zend_Db_Table_Abstract ?
ou faut il utiliser le POO de base ? sad
on ne va quand meme pas renoncer aux vues juste pour utiliser le framework smile
déjà que je trouve limite de devoir "bidouiller" avec setIntegrityCheck(false) sur les jointures

merci d'avance !

[oranocha]

Salut,

Je t'avoue que je chipote aussi pas mal en ce moment avec Zend pour tenter de m'y mettre sérieusement :-)

Je me pose un peu la même question que toi et voici où j'en suis dans ma réflexion :

+ définir une class / table en faisant un extend de Zend_Db_Table_Abstract me semble une bonne idée afin de mettre en place la logique métier faisant appel à des INSERT, UPDATE et DELETE

En effet, cela permet de mettre en place le système de cascade et de s'assurer de l'intégrité des données sauvées dans la table en surchargeant les fonctions insert et update en y spécifiant des check sur les données.

+ simplement utiliser les fonctions de Zend pour faire des recherches sur des tables avec beaucoup de relation, ça me semble être assez compliqué et surtout très long ...

+ utiliser les vues avec Zend_Db_Table_Abstract : c'est impossible, selon les infos de la doc officielle ...

CE QUE JE CROIS DONC
>> je vais continuer à créer une classe / table pour la logique métier INSERT, UPDATE et DELETE.
>> je vais continuer à créer les vues nécessaires à mon application en MySQL.
>> je vais créer des classes métiers non-attachées à Zend_Db_Table_* mais faisant un extend de Zend_Db_Select et définissant des fonctions de recherche spécifiques.

Ca me semble être un moyen assez rapide à mettre en place, tout en conservant les bienfaits de la MVC.

Bien entendu, ceci est ma propre réflexion ... si d'autres ont des idées :-)

++
Olivier

[dream_moon]

hey, salut Olivier, content de te lire, je me sens moins seul !

et bien écoute, moi j'aime bien les fonctions zend de recherche pour ne pas avoir à passer du temps à écrire des classes d'accès aux données
un peu comme pour hibernate en java, je veux pouvoir me concentrer sur la logique métier
par contre c'est clair que les jointures en zend ne sont pas hyper évidentes à gérer avec les dépendances entre classes, et surtout problèmes de performances pour multijointures
d'où l'intéret des views !

et oui, non seulement c'est impossible, mais ils ne marquent aucune solution de contournement
un peu bizarre que ca ne les gène pas, étant donné que zend a l'air concu pour les gros projets

effectivement, attaquer directement les vues avec Zend_Db_Select en construisant les requetes

mais est ce que ce n'est pas génant de les rattacher comme des classes métier ?
alors qu'elles servent juste à accéder aux données, je pense il faudrait les garder dans le modèle meme si on ne se sert pas de Zend_Db_Table_Abstract
sinon on commence à casser la logique MVC et ca ne me semble pas très bon
enfin ce n'est que mon opinion

on se tient au courant de nos essais, et si on trouve des liens

à toute

[dream_moon]

bon j'ai testé une classe heritant de Zend_Db_Select pour les views ca marche tres bien
et en la mettant dans le modele je pense qu'on respecte bien l'archi

j'utilise à l'intérieur des méthodes buildRequete comme :

protected function buildFind() {
$this->reset();
$this->from('requete'')
->order('requete');
}
protected function buildFindByParam($param) {
$this->reset();
$this->buildFind();
$this->where($param);
}

ce qui permet de réutiliser les requetes dans

public function find() {
$this->buildFind();
return Zend_Registry::get("db")->fetchAll($this);
}
public function findByParam($param) {
$this->buildFindByParam($param);
return Zend_Registry::get("db")->fetchAll($this);
}

au final comme ca reste des lectures les requetes restent simples
(une fois la jointure de view ecrite )

mais si quelqu'un trouve d'autres idées pour utiliser les views (données) ca m'intéresse

[oranocha]

Bon, beh à mon tour de proposer ma façon de faire :-)

Tout comme j'ai des classes Table_Data_* (sauvées dans models/Table/Data/) où * correspond à "une classe / table", j'ai des classes Table_View_* (sauvées dans models/Table/Data/) où * correspond à "une classe par vue".

Voici à quoi ressemble ma classe Table_View_Constante qui attaque la vue constante_v :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
class Table_View_Constante extends Table_Select {	
 
	function getActiveByLang($lang) {		
		$sql = $this->getConnect()->query('SELECT * FROM constante_v WHERE constante_statut = :statut AND constante_c_langue_code = :langue',
		array('statut' => 'OK', 'langue' => $lang));
 
		return $sql->fetchAll();
	}
 
}

Le principe est assez simple ... Vous aurez remarqué que cette classe étend Table_Select qui correspond à ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
class Table_Select {
 
	private $_connect;
 
	function __construct() {
		try {
			$this->_connect = Zend_Registry::get('dbAdapter');
			return $this->_connect->getConnection();
		} catch (Zend_Db_Adapter_Exception $e){
			echo $e->getMessage();
		}
	}
 
	function getConnect() {
		return $this->_connect;
	}
 
}

Ceci me permet de sortir le système de connexion à la DB de mes classes vues ...

Bonne journée,
Olivier

[Invité]

De mon coté j'ai forcé une clé primaire avec $_primary = 'clé-primaire', et ca fonctionne très bien, sauf en enregistrement (logique).
Cette solution suffit largement aux problèmes que j'ai jusqu'alors rencontrés.

[GrandFather]

De mon coté j'ai forcé une clé primaire avec $_primary = 'clé-primaire', et ca fonctionne très bien, sauf en enregistrement (logique).
Cette solution suffit largement aux problèmes que j'ai jusqu'alors rencontrés.

C'est ce que je fais aussi, j'utilise énormément les vues avec PostgreSQL, et ça n'a jamais posé de soucis.

La clé primaire définie dans une classe modèle ne doit pas forcément correspondre à un champ déclaré comme tel dans la base de données (PRIMARY KEY en SQL), cela peut être n'importe quel champ (ou combinaison de champs) qui permette d'identifier un tuple de manière unique. Il suffit donc d'inclure dans la vue un champ qui peut remplir cette fonction, ce qui ne pose généralement aucune difficulté.

Sur le reste je te rejoins dream_moon, je trouve plus pratique de gérer directement mes jointures dans des vues plutôt que dans les classes modèles, mais les deux pratiques ont chacune leurs avantages et leurs inconvénients.

[dream_moon]

merci pour vos réponses d'experts

effectivement en forcant une clé primaire dans la classe de vue cela marche tres bien, pourquoi faire compliqué

GrandFather quels sont pour toi les inconveniants des jointures dans les vues ?
quand vaut il mieux utiliser directement les classes modeles ?

bonne continuation à tous

[k o D]

C'est ce que je fais aussi, j'utilise énormément les vues avec PostgreSQL, et ça n'a jamais posé de soucis.

La clé primaire définie dans une classe modèle ne doit pas forcément correspondre à un champ déclaré comme tel dans la base de données (PRIMARY KEY en SQL), cela peut être n'importe quel champ (ou combinaison de champs) qui permette d'identifier un tuple de manière unique. Il suffit donc d'inclure dans la vue un champ qui peut remplir cette fonction, ce qui ne pose généralement aucune difficulté.

Sur le reste je te rejoins dream_moon, je trouve plus pratique de gérer directement mes jointures dans des vues plutôt que dans les classes modèles, mais les deux pratiques ont chacune leurs avantages et leurs inconvénients.

C'est exactement ce que j'ai réalisé.
Je définis un champ ou un ensemble de champs permettant d'identifier clairement l'enregistrement. C'est tout.