J'essaie de récupérer par un evenement les donneés d'une balise "Label"n
venant d'un datalist, en cliquant sur un imagebutton.
En faisant un findcontrol je n'y arrive pas ...:
> Tout dépend de comment tu veux structurer tes pages... C'est vrai que l'avantage du SqlDataSource, c'est le gain de temps énorme à realiser les pages et de tout faire à la souris... Cela évite beaucoup de code et de bug !
L'inconvénient d'un tel procédé c'est que (par exemple) tu ancres toutes les requêtes SQL directement les pages ASP... Tu n'as donc plus une architecture classique couches (Métier, Accès aux données et IHM) ! Il suffit qu'un jour tu changes de SGBD (ou un renomage de table par exemple) pour te rendre compte que c'est un vrai bazarre à modifier (sur 5 pages ça va encore... Mais sur 50 c'est horrible)
Personellement, pour les développements ASP .NET, je (nous) utilise uniquement l'ObjectDataSource car : - il est possible avec celui-ci d'avoir un rendu visuel en Mode Design des tes colonnes,...etc - d'appeler des méthodes qui se chargeront de récupérer les données... - de réduire un peu le codage en passant les paramètres des pages GET, POST,...etc directement dans les méthodes sans avoir à les traiter dans le Page_Load() - On a des pages qui sont ancrés directement via la couche métier et non via à un SGBD (ou à une source de données) quelconque !
Si tu veux utiliser l'objet ObjectDataSource je pourrais te donner quelques conseils concernant l'organisation de ton code...
Intéressant! Cela me paraît bien pertinent. Avec ObjectDataSource je passerai donc par des dataset pour accéder à mes données et leur traitement? Mais si le traitement dans page_load n'est plus nécessaire je peux donc passer des parametres à mes requetes directement via ObjectDataSource comme je le fais avec SqlDataSource?
Je vais me lancer sur cette voie, donc evidemment tes conseils sont les bienvenus!
merci encore
> Tout dépend de comment tu veux structurer tes pages...
C'est vrai que l'avantage du SqlDataSource, c'est le gain de temps énorme
à realiser les pages et de tout faire à la souris...
Cela évite beaucoup de code et de bug !
L'inconvénient d'un tel procédé c'est que (par exemple) tu ancres toutes
les requêtes SQL directement les pages ASP...
Tu n'as donc plus une architecture classique couches (Métier, Accès aux
données et IHM) ! Il suffit qu'un jour tu changes de SGBD (ou un renomage
de table par exemple) pour te rendre compte que c'est un vrai bazarre à
modifier (sur 5 pages ça va encore... Mais sur 50 c'est horrible)
Personellement, pour les développements ASP .NET, je (nous) utilise
uniquement l'ObjectDataSource car :
- il est possible avec celui-ci d'avoir un rendu visuel en Mode Design des
tes colonnes,...etc
- d'appeler des méthodes qui se chargeront de récupérer les données...
- de réduire un peu le codage en passant les paramètres des pages GET,
POST,...etc directement dans les méthodes sans avoir à les traiter dans le
Page_Load()
- On a des pages qui sont ancrés directement via la couche métier et non
via à un SGBD (ou à une source de données) quelconque !
Si tu veux utiliser l'objet ObjectDataSource je pourrais te donner
quelques conseils concernant l'organisation de ton code...
Intéressant!
Cela me paraît bien pertinent. Avec ObjectDataSource je passerai donc par
des dataset pour accéder à mes données et leur traitement?
Mais si le traitement dans page_load n'est plus nécessaire je peux donc
passer des parametres à mes requetes directement via ObjectDataSource comme
je le fais avec SqlDataSource?
Je vais me lancer sur cette voie, donc evidemment tes conseils sont les
bienvenus!
> Tout dépend de comment tu veux structurer tes pages... C'est vrai que l'avantage du SqlDataSource, c'est le gain de temps énorme à realiser les pages et de tout faire à la souris... Cela évite beaucoup de code et de bug !
L'inconvénient d'un tel procédé c'est que (par exemple) tu ancres toutes les requêtes SQL directement les pages ASP... Tu n'as donc plus une architecture classique couches (Métier, Accès aux données et IHM) ! Il suffit qu'un jour tu changes de SGBD (ou un renomage de table par exemple) pour te rendre compte que c'est un vrai bazarre à modifier (sur 5 pages ça va encore... Mais sur 50 c'est horrible)
Personellement, pour les développements ASP .NET, je (nous) utilise uniquement l'ObjectDataSource car : - il est possible avec celui-ci d'avoir un rendu visuel en Mode Design des tes colonnes,...etc - d'appeler des méthodes qui se chargeront de récupérer les données... - de réduire un peu le codage en passant les paramètres des pages GET, POST,...etc directement dans les méthodes sans avoir à les traiter dans le Page_Load() - On a des pages qui sont ancrés directement via la couche métier et non via à un SGBD (ou à une source de données) quelconque !
Si tu veux utiliser l'objet ObjectDataSource je pourrais te donner quelques conseils concernant l'organisation de ton code...
Intéressant! Cela me paraît bien pertinent. Avec ObjectDataSource je passerai donc par des dataset pour accéder à mes données et leur traitement? Mais si le traitement dans page_load n'est plus nécessaire je peux donc passer des parametres à mes requetes directement via ObjectDataSource comme je le fais avec SqlDataSource?
Je vais me lancer sur cette voie, donc evidemment tes conseils sont les bienvenus!
merci encore
Gilles TOURREAU
Le Tue, 31 Jul 2007 17:55:45 +0200, Dolten Altgor a écrit:
Intéressant! Cela me paraît bien pertinent. Avec ObjectDataSource je passerai donc par des dataset pour accéder à mes données et leur traitement? Mais si le traitement dans page_load n'est plus nécessaire je peux donc passer des parametres à mes requetes directement via ObjectDataSource comme je le fais avec SqlDataSource?
Oui, car avec ObjectDataSource les paramètres de la page que tu passes (GET, POST...etc) sont envoyés à des méthodes d'une classe :
Dans ton ObjectDataSource tu associe : - la classe : MaClasse - La méthode Select : MaMéthode - Le paramètre param1 récupère la valeur du paramètre GET appelé "identifiant" - Le paramètre param2 récupère la valeur du paramètre POST appelé "toto" ...etc
Voici le code de la méthode que tu devras mettre dans la classe MaMéthode
public void MaMéthode(int param1, string param2,...etc) { ... }
Je vais me lancer sur cette voie, donc evidemment tes conseils sont les bienvenus!
merci encore
Un exemple d'une bonne organisation que je te recommande (au niveau couche métier/IHM)
On suppose que tu as dans ta couche métier 3 objets comme ceci :
La classe Chien comporte que des propriété Get/Set (Nombre de papattes, race,...etc) Le DataSet Voiture contient une table Voiture, Marque avec des champs adéquats...etc
Et ta classe BusinessManager contient 2 méthodes par exemple :
public Chien[] GetToutoux(string race); public Voiture GetVoitures_A_LaCasse(int numéroSérie);
Du coté de ton projet ASP .NET on suppose une page appelé Altgor.aspx, je te conseille de créer une classe (soit incluse dans le code Behind, soit à part mais dans le même projet) appelé AltgorDataManager (par exemple).
Dans cette classe tu créer 2 méthodes (statiques ou non) :
public Chien[] GetToutoux(string race) { BusinessManager b; Chien[] toutoux;
b = new BusinessManager(); toutoux = b.GetToutoux(race);
//Inverser l'ordre des toutoux Array.Inverse(toutoux);
return toutoux; }
public Voiture GetVoitures_A_LaCasse(string numéroSérie) { //Formater le n° de série int temp; temp = Formater(numéroSérie); if (temp == null) //Mauvais format return null;
BusinessManager b; b = new BusinessManager(); return b.GetVoitures_A_LaCasse(numéroSérie); }
Tu n'a plus qu'assocer les DataObjectSource à ces méthodes...
Cela peut te sembler lourd en voyant un tel code qui "repetent" les appels à la couche métier, mais cela permet au développeur de la partie IHM de contrôler les saisies utilisateurs, d'ordonner différements les données (cf. Array.Inverse(toutoux)) avant d'afficher les données... C'est ici qu'il faut aussi contrôler les risques de faille dû à la saisie de l'utilisateur...
Du coté graphique, l'infographiste n'a aucune idée de comment sont récupérés les toutoux, il sait juste qu'il appelle une méthode qui récupère des toutoux et qu'il devra les afficher dans des colonnes avec tel couleur... etc.
Tu remarquera que la création de la classe AltgorDataManager sépare le codage de l'accès aux données, et le codage qui manipule les objets (par ex : "MonControl.Color = ...")
Tu remarquera aussi qu'au niveau de la classe AltgorDataManager il n'y aucun accès physique à une source de données, on ne sait pas d'où viennent les données ! WebService ? SGBD ? Fichier XML ? C'est le développeur de la couche métier/accès aux données qui s'arrachera les cheveux pour çà !
Tu peux créer une classe de base regroupant des méthodes communes pour chaque DataManager de chaque page...
Regardes bien la doc du ObjectDataSource, car Microsoft explique très clairement comment ASP .NET instancie la classe associée (ici AltgorDataManager)? Tu peux personnaliser l'instanciation de la classe AltgorDataManager.
ATTENTION : En utilisant un ObjectDataSource associé à la AltgorDataManager, à chaque appel d'une méthode Select, Insert,...etc, il réinstancie ta classe ! Ce qui signifie que si l'allocation des ressources de ton BusinessManager coûte cher cela peut poser des problèmes... Il faut isoler garder quelque part ton BusinessManager instancié afin qu'il puisse être utilisé durant toute la requête HTTP.
Tu peux te passer de cette classe intermédiaire et appeler ton BusinessManager directement, cependant tu n'auras pas le contrôle des paramètres récupérer sur la page ASP, ni des données exploitée...
Si tu as encore des questions...
Cordialement
-- Gilles TOURREAU
S.A.R.L. P.O.S Le spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
Le Tue, 31 Jul 2007 17:55:45 +0200, Dolten Altgor <dolten@xxx.com> a écrit:
Intéressant!
Cela me paraît bien pertinent. Avec ObjectDataSource je passerai donc par
des dataset pour accéder à mes données et leur traitement?
Mais si le traitement dans page_load n'est plus nécessaire je peux donc
passer des parametres à mes requetes directement via ObjectDataSource
comme
je le fais avec SqlDataSource?
Oui, car avec ObjectDataSource les paramètres de la page que tu passes
(GET, POST...etc) sont envoyés à des méthodes d'une classe :
Dans ton ObjectDataSource tu associe :
- la classe : MaClasse
- La méthode Select : MaMéthode
- Le paramètre param1 récupère la valeur du paramètre GET appelé
"identifiant"
- Le paramètre param2 récupère la valeur du paramètre POST appelé "toto"
...etc
Voici le code de la méthode que tu devras mettre dans la classe MaMéthode
public void MaMéthode(int param1, string param2,...etc)
{
...
}
Je vais me lancer sur cette voie, donc evidemment tes conseils sont les
bienvenus!
merci encore
Un exemple d'une bonne organisation que je te recommande (au niveau couche
métier/IHM)
On suppose que tu as dans ta couche métier 3 objets comme ceci :
La classe Chien comporte que des propriété Get/Set (Nombre de papattes,
race,...etc)
Le DataSet Voiture contient une table Voiture, Marque avec des champs
adéquats...etc
Et ta classe BusinessManager contient 2 méthodes par exemple :
public Chien[] GetToutoux(string race);
public Voiture GetVoitures_A_LaCasse(int numéroSérie);
Du coté de ton projet ASP .NET on suppose une page appelé Altgor.aspx, je
te conseille de créer une classe (soit incluse dans le code Behind, soit à
part mais dans le même projet) appelé AltgorDataManager (par exemple).
Dans cette classe tu créer 2 méthodes (statiques ou non) :
public Chien[] GetToutoux(string race)
{
BusinessManager b;
Chien[] toutoux;
b = new BusinessManager();
toutoux = b.GetToutoux(race);
//Inverser l'ordre des toutoux
Array.Inverse(toutoux);
return toutoux;
}
public Voiture GetVoitures_A_LaCasse(string numéroSérie)
{
//Formater le n° de série
int temp;
temp = Formater(numéroSérie);
if (temp == null) //Mauvais format
return null;
BusinessManager b;
b = new BusinessManager();
return b.GetVoitures_A_LaCasse(numéroSérie);
}
Tu n'a plus qu'assocer les DataObjectSource à ces méthodes...
Cela peut te sembler lourd en voyant un tel code qui "repetent" les appels
à la couche métier, mais cela permet au développeur de la partie IHM de
contrôler les saisies utilisateurs, d'ordonner différements les données
(cf. Array.Inverse(toutoux)) avant d'afficher les données... C'est ici
qu'il faut aussi contrôler les risques de faille dû à la saisie de
l'utilisateur...
Du coté graphique, l'infographiste n'a aucune idée de comment sont
récupérés les toutoux, il sait juste qu'il appelle une méthode qui
récupère des toutoux et qu'il devra les afficher dans des colonnes avec
tel couleur... etc.
Tu remarquera que la création de la classe AltgorDataManager sépare le
codage de l'accès aux données, et le codage qui manipule les objets (par
ex : "MonControl.Color = ...")
Tu remarquera aussi qu'au niveau de la classe AltgorDataManager il n'y
aucun accès physique à une source de données, on ne sait pas d'où viennent
les données ! WebService ? SGBD ? Fichier XML ? C'est le développeur de la
couche métier/accès aux données qui s'arrachera les cheveux pour çà !
Tu peux créer une classe de base regroupant des méthodes communes pour
chaque DataManager de chaque page...
Regardes bien la doc du ObjectDataSource, car Microsoft explique très
clairement comment ASP .NET instancie la classe associée (ici
AltgorDataManager)? Tu peux personnaliser l'instanciation de la classe
AltgorDataManager.
ATTENTION : En utilisant un ObjectDataSource associé à la
AltgorDataManager, à chaque appel d'une méthode Select, Insert,...etc, il
réinstancie ta classe ! Ce qui signifie que si l'allocation des ressources
de ton BusinessManager coûte cher cela peut poser des problèmes... Il faut
isoler garder quelque part ton BusinessManager instancié afin qu'il puisse
être utilisé durant toute la requête HTTP.
Tu peux te passer de cette classe intermédiaire et appeler ton
BusinessManager directement, cependant tu n'auras pas le contrôle des
paramètres récupérer sur la page ASP, ni des données exploitée...
Si tu as encore des questions...
Cordialement
--
Gilles TOURREAU
gilles.tourreau@pos.fr
S.A.R.L. P.O.S
Le spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
Le Tue, 31 Jul 2007 17:55:45 +0200, Dolten Altgor a écrit:
Intéressant! Cela me paraît bien pertinent. Avec ObjectDataSource je passerai donc par des dataset pour accéder à mes données et leur traitement? Mais si le traitement dans page_load n'est plus nécessaire je peux donc passer des parametres à mes requetes directement via ObjectDataSource comme je le fais avec SqlDataSource?
Oui, car avec ObjectDataSource les paramètres de la page que tu passes (GET, POST...etc) sont envoyés à des méthodes d'une classe :
Dans ton ObjectDataSource tu associe : - la classe : MaClasse - La méthode Select : MaMéthode - Le paramètre param1 récupère la valeur du paramètre GET appelé "identifiant" - Le paramètre param2 récupère la valeur du paramètre POST appelé "toto" ...etc
Voici le code de la méthode que tu devras mettre dans la classe MaMéthode
public void MaMéthode(int param1, string param2,...etc) { ... }
Je vais me lancer sur cette voie, donc evidemment tes conseils sont les bienvenus!
merci encore
Un exemple d'une bonne organisation que je te recommande (au niveau couche métier/IHM)
On suppose que tu as dans ta couche métier 3 objets comme ceci :
La classe Chien comporte que des propriété Get/Set (Nombre de papattes, race,...etc) Le DataSet Voiture contient une table Voiture, Marque avec des champs adéquats...etc
Et ta classe BusinessManager contient 2 méthodes par exemple :
public Chien[] GetToutoux(string race); public Voiture GetVoitures_A_LaCasse(int numéroSérie);
Du coté de ton projet ASP .NET on suppose une page appelé Altgor.aspx, je te conseille de créer une classe (soit incluse dans le code Behind, soit à part mais dans le même projet) appelé AltgorDataManager (par exemple).
Dans cette classe tu créer 2 méthodes (statiques ou non) :
public Chien[] GetToutoux(string race) { BusinessManager b; Chien[] toutoux;
b = new BusinessManager(); toutoux = b.GetToutoux(race);
//Inverser l'ordre des toutoux Array.Inverse(toutoux);
return toutoux; }
public Voiture GetVoitures_A_LaCasse(string numéroSérie) { //Formater le n° de série int temp; temp = Formater(numéroSérie); if (temp == null) //Mauvais format return null;
BusinessManager b; b = new BusinessManager(); return b.GetVoitures_A_LaCasse(numéroSérie); }
Tu n'a plus qu'assocer les DataObjectSource à ces méthodes...
Cela peut te sembler lourd en voyant un tel code qui "repetent" les appels à la couche métier, mais cela permet au développeur de la partie IHM de contrôler les saisies utilisateurs, d'ordonner différements les données (cf. Array.Inverse(toutoux)) avant d'afficher les données... C'est ici qu'il faut aussi contrôler les risques de faille dû à la saisie de l'utilisateur...
Du coté graphique, l'infographiste n'a aucune idée de comment sont récupérés les toutoux, il sait juste qu'il appelle une méthode qui récupère des toutoux et qu'il devra les afficher dans des colonnes avec tel couleur... etc.
Tu remarquera que la création de la classe AltgorDataManager sépare le codage de l'accès aux données, et le codage qui manipule les objets (par ex : "MonControl.Color = ...")
Tu remarquera aussi qu'au niveau de la classe AltgorDataManager il n'y aucun accès physique à une source de données, on ne sait pas d'où viennent les données ! WebService ? SGBD ? Fichier XML ? C'est le développeur de la couche métier/accès aux données qui s'arrachera les cheveux pour çà !
Tu peux créer une classe de base regroupant des méthodes communes pour chaque DataManager de chaque page...
Regardes bien la doc du ObjectDataSource, car Microsoft explique très clairement comment ASP .NET instancie la classe associée (ici AltgorDataManager)? Tu peux personnaliser l'instanciation de la classe AltgorDataManager.
ATTENTION : En utilisant un ObjectDataSource associé à la AltgorDataManager, à chaque appel d'une méthode Select, Insert,...etc, il réinstancie ta classe ! Ce qui signifie que si l'allocation des ressources de ton BusinessManager coûte cher cela peut poser des problèmes... Il faut isoler garder quelque part ton BusinessManager instancié afin qu'il puisse être utilisé durant toute la requête HTTP.
Tu peux te passer de cette classe intermédiaire et appeler ton BusinessManager directement, cependant tu n'auras pas le contrôle des paramètres récupérer sur la page ASP, ni des données exploitée...
Si tu as encore des questions...
Cordialement
-- Gilles TOURREAU
S.A.R.L. P.O.S Le spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
Gilles TOURREAU
Le Tue, 31 Jul 2007 18:44:42 +0200, Gilles TOURREAU a écrit:
Est-ce que tu peux me passer ton adresse e-mail à catte adresse :
Cordialement
-- Gilles TOURREAU
S.A.R.L. P.O.S Le spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
Le Tue, 31 Jul 2007 18:44:42 +0200, Gilles TOURREAU
<gilles.tourreau@pos.fr> a écrit:
Est-ce que tu peux me passer ton adresse e-mail à catte adresse :
gilles.tourreau@pos.fr
Cordialement
--
Gilles TOURREAU
gilles.tourreau@pos.fr
S.A.R.L. P.O.S
Le spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr