Hello,
 
j'ai une appli à maintenir ou plutot a refondre.
 
Le code de base etait totu ce qu'il y a de plus montolithique.
 
Donc moi je factorise tout ca, corrige les bugs et essai de le rendre maintenable.
 
j'interroge une bd et du ldap.
 
cote bd tout a ete ecrit en oracleClient, donc pas génial niveau portabilite, surtout qu'oracle est utilise comme ungros tampon, donc on peut tres bien mettre ca sur des bases bcp moins grosses.
 
toutes les interrogations etaient faites dans l'asp, ce qui rend le code vraiment chiant a lire.
 
j'ai sorti tout le code oracle des pages asp, pour n'avoir qu'une classe statique contenant toutes les methodes d'interrogation oracles et renvoyant a l asp des structures remplies, et l asp se charge de l affichage, ainsi pu d'oracle ou autre dans l'asp.
Avantage si demain je veux passser en oledb ou odbc ou autre je n'ai qu'un fichier a changer, et pareil pour les requetes elles se trouvent toutes au meme endroit ce qui facilite la maintenance en cas de changement de base.
 
Le probleme se pose pour les requetes LDAP, j'ai aussi fait un package mais n'ai pas sorti complètement le cote requete de l'asp, c'est a dire que j'ai une methode ou je passe les params de la requete (filtre et propriete) et je recupere un objet directoryEntry un objet LDAP on va dire.
 
Le cote pas génial c'est que l'asp ne s'occupe pas que de l affihage du resultat mais aussi de la requete et de la lecture du resultat de la requete.
De plus la requete elle meme est dans l asp, enfin a quelque chose pret, filtre et propriete a chargé y sont ce qui fait une bonne partie variable de la requete, si un jour les gars decident de depressie une propriete ou la renome bein modifier tous les fichiers pour ca c'est assez con.
Perso moi ca me plait pas trop.
 
Solutions:
-faire un package avec des fonctions génériques pour LDAP => c'est fait, mais ca n'enleve pas le fait qu'une partie de la requete est dans l'asp et c'est a l asp d'interprete le resultat.
 
- faire une classe statique intermediaire qui serait appeller par l'asp qui lui aurait une methode specifique avec les filtres et proprietes a charger necessaire, dans cette classe on mettrait donc une methode par matheode appellante de l asp et chaune aurait ses filtres et ses propres propietes, ces methodes appelleraient la classe statique ayant les methodes generiques, et le tout retournerai un tableau de string, et l'asp n'aurait plus qu a se charger de l'affichage.
 
Probleme, cela rajoute une indirection, ce qui est pas tres grave, mais il faut recoder bcp de chose, et parfois changer certains comportements de l'appli. Des plus cette nouvelle classe ne serait vraiment pas réutilisable, elle serait plus considérer comme une aide à l'évolution ou sa configuration (bien qu'il ne s'agisse pas vraiment de configuration, car tout cela n'estpas sensé changer, ce ne sont normalement pas des params variables).
 
Avantage, un seul endroit ou se trouve les requêtes LDAP, et un autre seul endroit ou se trouve l'interrogation de LDAP, l asp ne chargeant uniquement QUE de l affichage, ce qui est un véritable plus niveau maintenance, chaque chose serait dissocié et pour modifier une chose, un seul fichier serait à modifier.
 
Je parle de classe statique, car je ne fais pas de l'objet pur, j'utilise les classes statiques comme des pakage en C ou ADA, l'application n'a pas lieu d'être objet et surtout que celle ci n'a pas été pensé pour ... je ne fais que la maintenir ou tout du moins la corriger, cétait une usine à bug, et surtout mal programmé, pas performante, et pb de sécurité, donc la première étape et d'avoir un truc propre qui tourne bien, une version objet existera peut être, mais la encore si ce que je fais fonctionne, ca sera très simple de repasser tout ca en objet, après le penser objet le code lui sera deja quasi écrit et retrouvable facilement et suffira de l'organiser en objet .
 
Alors qu'en pensez vous ?