conception orientée objet

de choses sur les architectures n-tiers, soa, poa et

autres mais à chaque fois ça reste très théorique, les quelques exemples
developpés deviennent vite complexes avec 15 couches et 25 règles à
respecter,...
Donc si vous connaissez un meilleur endroit pour poster ce genre demande,
si vous avez une adresse de site avec un exemple concret ou si vous avez
une idée sur la question....
.... MERCI

Ben alors, personne ? Ca interresse personne l'architecture ?

Tony, t'es encore là ? Si oui, je tenterais de rediger un truc ce we, pour
tenter de lancer le fil car ca m'interresse aussi.

@ ++

Stef

oui je suis toujours là !

J'avance petit à petit sur mon idée même si je reste prudent et si la mise
en place définitive est loin d'être achevée.
Disons que je me suis fortement interessé au framework de persistance avec
mapping o/r.
Microsoft est complètement à la bourre dans le domaine et après une
tentative dont j'ai oublié le nom, il semble que microsoft devrait inclure
ça dans le framework 3.0, en fait dans winfs.
Sinon il y a beaucoup d'offre de framework payants. Le problème est de
jauger le prix, la qualité et la pérénité du produit !
J'ai par conséquent été faire un tour du coté de Borland qui propose avec
son C# builder un framework de perssitance. J'en suis à la phase de
découverte mais il faut bien avoué que c'est d'une approche assez difficile,
qu'il y a peu d'exemple et qu'il est difficle de dire comment ça se comporte
dans le temps.

Tony

"slambert" <slambertPASDESPAM@vediovis.net> a écrit dans le message de news:
451384da$0$1767$636a55ce@news.free.fr...

de choses sur les architectures n-tiers, soa, poa et

autres mais à chaque fois ça reste très théorique, les quelques exemples
developpés deviennent vite complexes avec 15 couches et 25 règles à
respecter,...
Donc si vous connaissez un meilleur endroit pour poster ce genre demande,
si vous avez une adresse de site avec un exemple concret ou si vous avez
une idée sur la question....
.... MERCI

Ben alors, personne ? Ca interresse personne l'architecture ?

Tony, t'es encore là ? Si oui, je tenterais de rediger un truc ce we, pour
tenter de lancer le fil car ca m'interresse aussi.

@ ++

Stef

Pourquoi tu le fais pas en MVC ? Tu connais le concept ?

Ta couche Layer pour uniquement gerer entre/sortie
Ta couche Business pour tes metiers, tes objets.
Ta couche Data, avec soit tes requetes sql parametrées, soi ton mapping.

Couche presentation:
Si demain tu fais du wap, du Ipod, ou du client lourd, tu n'auras que tes
ecrans à recoder. Tout ce qui est traitement , calcul non lie à ton type de
techo de presntation est delegue qs la couche metiers. Pas de code dans ton
html [aspx] , comme si tu bosais avec un Webmaster et que celui ci ne devait
etre confronté qu'à du HTML ou des tags. Et pas de css ou de html dans ton
code [aspx.cs] pour nme pas avoir à recompilir pour changer la presentaton.

Couche business:
Ce qui est specifique à tes objets. En fait, là, tout est objet, ou phase de
transition pour la couche Data.

LoadNews et SaveNews dans l'objet News et éventuellement dans CollectNews

Moi j'ai fais comme ca. Apres, est ce l'ideal... N'empeche, le jour ou j'ai
voulu descendre mon insert en procedure stocké afin d'y associer des checks
dans la meme transaction [verif login/password par exemple] , j'ai meme pas
eu à toucher à mes objets.

Couche Data:
Perso, je passe par des requetes sql parametrées. Le mapping ne me convient
pas tous le temps, quand tu veux faire une page de statistiques avec des
count , des calculs, etc, je prefere passer par des agregats en sql pour ne
remonter que les valeurs necessaires au lieu de passer toute ma base de
donnee en memoire avant de faire des calculs de tableaux dans mon code. Et
puis le sql, je connais bien. En restant le plus standard, tu peux meme
preparer le coup pour le jour ou tu dois changer de base de donnée. [sauf
que mes choix m'imposeront de rester en base relationelle]. Voir meme,
pondre une petite couche en plus d'encapsulation de SQL server. Et bonne
nouvelle, ADO.net gère les pool de connection lui meme, pas besoin de se
les coder à la mimine. Et puis pour finir, le jour ou tu veux faire un
mapping à la NHibernate, tu touches que à ta couche Data. Et puis tu peux
meme melanger mapping et requetes parametres, c'est pas beaux mais ca
marche, et si tu limite bien tout cela à ta meme couche, tu limites les
risques.

Bon ben voila, c'etait un petit point de depart pour lancer la discussion.
Toute réponse ou propostion sera la bienvenue. Je pense que tu as eu peu de
reponse car en architecture, des qu'il sagit de proposer et d'expliquer, on
est assez peu à vraiment se sentir sur de soi. Ouàa avoir le temps :)

Mais c'est mignon le MVC. Et avantage, ca marche avec à peu près toutes les
technologies :)

@ ++

Stef

merci pour ces expliquations.
Je ne connaissais pas le terme de MVC mais effectivement c'est cette
approche que tu décris qui m'interesse. J'aurais plutot appelé ça
architecture 3-tiers mais bon ...
Pour la couche presentation aucun problème, pour la couche objet métiers
même si je ne pratique pas énormement, conceptuellement aucun problème mais
la couche data reste très abstrait dans le sens où j'ai dû mal à pondre un
concept efficace.
D'ailleurs si je crée une fonction SaveNews dans mon objet News avec une
requete sql dedans, je me retrouve avec une couche data et une couche objet
mélangée ? non ? est-ce viable dans le temps ? ...
Le mapping est une approche assez expérimentale pour moi pour le moment ;
J'aimerais que tu m'expliques ce que tu appelles des requetes paramétrées ?!
car je suis assez d'accord que le mapping peut-être une contrainte forte et
en plus je ne suis pas sûr de réussir à faire avaler la couche objet à mes
collègues alors une couche mapping n'en parlons pas ;o)

"slambert" <slambertPASDESPAM@vediovis.net> a écrit dans le message de news:
451ae54c$0$6918$626a54ce@news.free.fr...

Pourquoi tu le fais pas en MVC ? Tu connais le concept ?

Ta couche Layer pour uniquement gerer entre/sortie
Ta couche Business pour tes metiers, tes objets.
Ta couche Data, avec soit tes requetes sql parametrées, soi ton mapping.

Couche presentation:
Si demain tu fais du wap, du Ipod, ou du client lourd, tu n'auras que tes
ecrans à recoder. Tout ce qui est traitement , calcul non lie à ton type
de techo de presntation est delegue qs la couche metiers. Pas de code dans
ton html [aspx] , comme si tu bosais avec un Webmaster et que celui ci ne
devait etre confronté qu'à du HTML ou des tags. Et pas de css ou de html
dans ton code [aspx.cs] pour nme pas avoir à recompilir pour changer la
presentaton.

Couche business:
Ce qui est specifique à tes objets. En fait, là, tout est objet, ou phase
de transition pour la couche Data.

LoadNews et SaveNews dans l'objet News et éventuellement dans CollectNews

Moi j'ai fais comme ca. Apres, est ce l'ideal... N'empeche, le jour ou
j'ai voulu descendre mon insert en procedure stocké afin d'y associer des
checks dans la meme transaction [verif login/password par exemple] , j'ai
meme pas eu à toucher à mes objets.

Couche Data:
Perso, je passe par des requetes sql parametrées. Le mapping ne me
convient pas tous le temps, quand tu veux faire une page de statistiques
avec des count , des calculs, etc, je prefere passer par des agregats en
sql pour ne remonter que les valeurs necessaires au lieu de passer toute
ma base de donnee en memoire avant de faire des calculs de tableaux dans
mon code. Et puis le sql, je connais bien. En restant le plus standard, tu
peux meme preparer le coup pour le jour ou tu dois changer de base de
donnée. [sauf que mes choix m'imposeront de rester en base relationelle].
Voir meme, pondre une petite couche en plus d'encapsulation de SQL server.
Et bonne nouvelle, ADO.net gère les pool de connection lui meme, pas
besoin de se les coder à la mimine. Et puis pour finir, le jour ou tu veux
faire un mapping à la NHibernate, tu touches que à ta couche Data. Et puis
tu peux meme melanger mapping et requetes parametres, c'est pas beaux mais
ca marche, et si tu limite bien tout cela à ta meme couche, tu limites les
risques.

Bon ben voila, c'etait un petit point de depart pour lancer la discussion.
Toute réponse ou propostion sera la bienvenue. Je pense que tu as eu peu
de reponse car en architecture, des qu'il sagit de proposer et
d'expliquer, on est assez peu à vraiment se sentir sur de soi. Ouàa avoir
le temps :)

Mais c'est mignon le MVC. Et avantage, ca marche avec à peu près toutes
les technologies :)

@ ++

Stef

Heu excusez moi mais l'architecture MVC n'a rien à voir avec l'architecture
3 tiers

MVC= Model, view , controleur

Le MVC c'est une architecutre dans la couche présentation

Pascal

"Tony" <tony_barret@(no_spam)hotmail.com> a écrit dans le message de news:
uUIcrzi5GHA.4996@TK2MSFTNGP04.phx.gbl...

merci pour ces expliquations.
Je ne connaissais pas le terme de MVC mais effectivement c'est cette
approche que tu décris qui m'interesse. J'aurais plutot appelé ça
architecture 3-tiers mais bon ...
Pour la couche presentation aucun problème, pour la couche objet métiers
même si je ne pratique pas énormement, conceptuellement aucun problème
mais la couche data reste très abstrait dans le sens où j'ai dû mal à
pondre un concept efficace.
D'ailleurs si je crée une fonction SaveNews dans mon objet News avec une
requete sql dedans, je me retrouve avec une couche data et une couche
objet mélangée ? non ? est-ce viable dans le temps ? ...
Le mapping est une approche assez expérimentale pour moi pour le moment ;
J'aimerais que tu m'expliques ce que tu appelles des requetes paramétrées
?! car je suis assez d'accord que le mapping peut-être une contrainte
forte et en plus je ne suis pas sûr de réussir à faire avaler la couche
objet à mes collègues alors une couche mapping n'en parlons pas ;o)

"slambert" <slambertPASDESPAM@vediovis.net> a écrit dans le message de
news: 451ae54c$0$6918$626a54ce@news.free.fr...

Pourquoi tu le fais pas en MVC ? Tu connais le concept ?

Ta couche Layer pour uniquement gerer entre/sortie
Ta couche Business pour tes metiers, tes objets.
Ta couche Data, avec soit tes requetes sql parametrées, soi ton mapping.

Couche presentation:
Si demain tu fais du wap, du Ipod, ou du client lourd, tu n'auras que tes
ecrans à recoder. Tout ce qui est traitement , calcul non lie à ton type
de techo de presntation est delegue qs la couche metiers. Pas de code
dans ton html [aspx] , comme si tu bosais avec un Webmaster et que celui
ci ne devait etre confronté qu'à du HTML ou des tags. Et pas de css ou de
html dans ton code [aspx.cs] pour nme pas avoir à recompilir pour changer
la presentaton.

Couche business:
Ce qui est specifique à tes objets. En fait, là, tout est objet, ou phase
de transition pour la couche Data.

LoadNews et SaveNews dans l'objet News et éventuellement dans CollectNews

Moi j'ai fais comme ca. Apres, est ce l'ideal... N'empeche, le jour ou
j'ai voulu descendre mon insert en procedure stocké afin d'y associer des
checks dans la meme transaction [verif login/password par exemple] , j'ai
meme pas eu à toucher à mes objets.

Couche Data:
Perso, je passe par des requetes sql parametrées. Le mapping ne me
convient pas tous le temps, quand tu veux faire une page de statistiques
avec des count , des calculs, etc, je prefere passer par des agregats en
sql pour ne remonter que les valeurs necessaires au lieu de passer toute
ma base de donnee en memoire avant de faire des calculs de tableaux dans
mon code. Et puis le sql, je connais bien. En restant le plus standard,
tu peux meme preparer le coup pour le jour ou tu dois changer de base de
donnée. [sauf que mes choix m'imposeront de rester en base relationelle].
Voir meme, pondre une petite couche en plus d'encapsulation de SQL
server. Et bonne nouvelle, ADO.net gère les pool de connection lui meme,
pas besoin de se les coder à la mimine. Et puis pour finir, le jour ou tu
veux faire un mapping à la NHibernate, tu touches que à ta couche Data.
Et puis tu peux meme melanger mapping et requetes parametres, c'est pas
beaux mais ca marche, et si tu limite bien tout cela à ta meme couche, tu
limites les risques.

Bon ben voila, c'etait un petit point de depart pour lancer la
discussion. Toute réponse ou propostion sera la bienvenue. Je pense que
tu as eu peu de reponse car en architecture, des qu'il sagit de proposer
et d'expliquer, on est assez peu à vraiment se sentir sur de soi. Ouàa
avoir le temps :)

Mais c'est mignon le MVC. Et avantage, ca marche avec à peu près toutes
les technologies :)

@ ++

Stef

> Je ne connaissais pas le terme de MVC mais effectivement c'est cette
approche que tu décris qui m'interesse. J'aurais plutot appelé ça
architecture 3-tiers mais bon ...

hmm.... non, pas exactement.

T'as un bon exemple ici: et google saura te donner moult schema si besoin
est :)
http://fr.wikipedia.org/wiki/Architecture_trois_tiers
avec un rapide schema ici:
http://www.bd.enst.fr/~talel/cours/bdl/wwwbd/Cours/Applications/3tiers/index.html

Dans le n tiers, tu englobe tous les espaces memoires depuis ta source de
donnee juqu'à l'affichage. Tu inclue donc ton client, lourd ou legers, et
donc potentiellement ton client web. A noter qu'en Java, on adore decouper
la couche du milieu en deux espaces memoires distincts qui s'appellent via
du corba. Bien souvent, ces deux espaces memoires sont sur la meme machine
et l'utilite du decoupage est donc discutable mais bon, cela n'est pas le
debat.

Dans le cas du 3 tiers, on conseille l'usage du Design Patern MVC, afin de
manager entre autres des changement possibles de source d'accès aux données
ou de type de technologie de display final d'ecran [tes ecrans finaux.]

la couche data reste très abstrait dans le sens où j'ai dû mal à pondre un
concept efficace.

C'est là que tu vas ecrire ton sql en fonction des parametres que tu vas
recevoir par exemple.... Il vont remonter des ArrayList à ta coche metiers
qui se debrouillera pour pouvoir envoyer tput ca sous forme d'objet à la
couche presentation.

D'ailleurs si je crée une fonction SaveNews dans mon objet News avec une
requete sql dedans,

Ben non :) Pas de sql dans ta couche metiers, le sql est dans ta couche
Data.

News ns = new News();
ns.titreNews="titre;"
ns.textNews="mon texte";
ns.dateNews="05/05/2005"
ns.idNews= ns.SaveNews();

dans ton objet News, t'a une methode
protected int saveNews()
{
return BusinessCouche.ClasseAppelle.MagicMethode(titreNews, texteNews,
dateNews)
}

Dans ta couche Data, tu vas avoir dans la classe correspondate:

protected int saveNewsQuery(string titreNews, string texteNews, Datetime
dateNews)
{
query = "insert into News (titreNews, texteNews, dateNews) VALUES
("+titreNews+", "+texteNews+", "+dateNews+)"
select @@id from machin truc
return newIdGenere
}


Bon apres, tu mets tes stringBuilder, tes tests, ta gestion de connecttion,
tes try catch, etc......

Mais l'esprit general est là.

Pareil pour tes select : news.loadNews(24) est cense te loader la news 24
dans ton objet. Dans ton objet, tu appelles ta requete sql en lui passant
ton idNews 24 . Et tu recup tes valeurs en retour, et dans ta couche layer,
tu joues aved ton objet et ses propriétés.

Etc, etc....

Si ou jour tu fais du mapping, ce sera la couche data qui fonctionnera
differement3. Mai ton objet continuera d'appeler un truc qui lui renverras
un DataSet en retour que tu transformera soit en objet soit en ArrayList
d'objet.

Apres, pour fignoler, tu te fais des fichiers properties dans ta couche
Business voir dans ta couche Data avec des valeures en static pour tes
parametres d'application ou toutes les valeurs à ecrire en dur susceptible
de changer un jour. Et là, le jour ou tu devras aller vers le multilangue
par exemple, tu vas apprécier :)

en plus je ne suis pas sûr de réussir à faire avaler la couche objet à mes
collègues alors une couche mapping n'en parlons pas ;o)

L'objet n'est pas tout le temps la panacé. Je sais, au début, ca surprend.
Mais en mode debug, quand tu place un break point juste avant le call final
à la base de donnee et que tu realises que la pile d'appel a explosé les 20
methodes intermedaires entre la saisie dans le form et l'envoit à ta base
Oracle, tu commence à t'interroger sur les bienfait de l'usine à gaz et les
raisons evetuelles du ralentissement general constaté. Mais bon, en meme
temps, quand on fait du c#, il vaut mieux faire de l'objet :)

Bon courage

@ ++

Stef

> Heu excusez moi mais l'architecture MVC n'a rien à voir avec
l'architecture 3 tiers

Euh....

MVC= Model, view , controleur
Le MVC c'est une architecutre dans la couche présentation

Le MVC, c'est un Design Pattern permettant de gerer la couche presentation,
et la couche d'acces aux donnés. Generaleemnt sur le serveur du milieu en
cas de 3 tiers :)

Enfin je crois:
http://fr.wikipedia.org/wiki/Architecture_trois_tiers

Mais bon, des fois, tu as le n tiers, les mecs de Java par exemple decoupe
ce serveur du milieux en deux, avec des EJB voir du SOAP [ou meme du RMI],
pour theoriquement pouvoir proposer un serveur d'objet sur une machine
appelé par des machines clientes, qui a leurs tour vont aller s'occuper des
couches presentation qu'elles ont à manager.

Là où on se marre, c'est quand tout cela, du serveur de base de donnee au
client web, est deployé sur la MEME machine. Mouarf. Mais c'est encore un
autre problème. : ))))

@ ++

Stef

Ok ça éclaire ma lanterne :o)

2 autres questions très concrètes :

1. Si je remplace mon mapping o/r actuel sur lequel j'ai très peu de
maitrise par une couche data de type Query comme dans les exemples que tu me
fournis, comment t'organises tu pour le découpage dans les fichiers : une
bibliothèque de classe (dll) NewsObjet et une bilbiotheque de classe
NewsData ? où finalement tout est dans la même dll et c'est la structure
même des méthodes et des appels à ces méthodes qui font qu'au final on a une
certaine indépendance entre les couches ?

2. Je reviens sur la validation des données. J'ai donné l'exemple dans mon
1er post d'une méthode de suppression. Si dans certaines conditions je ne
peux pas supprimer une news comment je fais communiquer l'info d'une couche
à l'autre ?
J'aurais tendance à dire que cette partie se gère au niveau métiers du genre
:

protected int SuppNews(){
if (SuppPossible(this.idnews)){
return SuppNews(this;idnews)
}
else{
return ????
}
}

Dans le cas où la suppression n'est pas possible ? comment je fais remonter
intelligemment l'info ? d'autant plus que si je fais remonter un message
précis en français j'aurais des soucis lorsque je voudrais passer en
multilangues ?


Voilà je sais je pose beaucoup de question :o) après c'est promis je me
jette dans l'expérimentation peut-être que certaines réponses s'imposeront
d'elle même.

Merci pour toutes tes réponses.

"slambert" <slambertPASDESPAM@vediovis.net> a écrit dans le message de news:
45215768$0$13544$426a74cc@news.free.fr...

Je ne connaissais pas le terme de MVC mais effectivement c'est cette
approche que tu décris qui m'interesse. J'aurais plutot appelé ça
architecture 3-tiers mais bon ...

hmm.... non, pas exactement.

T'as un bon exemple ici: et google saura te donner moult schema si besoin
est :)
http://fr.wikipedia.org/wiki/Architecture_trois_tiers
avec un rapide schema ici:
http://www.bd.enst.fr/~talel/cours/bdl/wwwbd/Cours/Applications/3tiers/index.html

Dans le n tiers, tu englobe tous les espaces memoires depuis ta source de
donnee juqu'à l'affichage. Tu inclue donc ton client, lourd ou legers, et
donc potentiellement ton client web. A noter qu'en Java, on adore decouper
la couche du milieu en deux espaces memoires distincts qui s'appellent via
du corba. Bien souvent, ces deux espaces memoires sont sur la meme machine
et l'utilite du decoupage est donc discutable mais bon, cela n'est pas le
debat.

Dans le cas du 3 tiers, on conseille l'usage du Design Patern MVC, afin de
manager entre autres des changement possibles de source d'accès aux
données ou de type de technologie de display final d'ecran [tes ecrans
finaux.]

la couche data reste très abstrait dans le sens où j'ai dû mal à pondre
un concept efficace.

C'est là que tu vas ecrire ton sql en fonction des parametres que tu vas
recevoir par exemple.... Il vont remonter des ArrayList à ta coche metiers
qui se debrouillera pour pouvoir envoyer tput ca sous forme d'objet à la
couche presentation.

D'ailleurs si je crée une fonction SaveNews dans mon objet News avec une
requete sql dedans,

Ben non :) Pas de sql dans ta couche metiers, le sql est dans ta couche
Data.

News ns = new News();
ns.titreNews="titre;"
ns.textNews="mon texte";
ns.dateNews="05/05/2005"
ns.idNews= ns.SaveNews();

dans ton objet News, t'a une methode
protected int saveNews()
{
return BusinessCouche.ClasseAppelle.MagicMethode(titreNews, texteNews,
dateNews)
}

Dans ta couche Data, tu vas avoir dans la classe correspondate:

protected int saveNewsQuery(string titreNews, string texteNews, Datetime
dateNews)
{
query = "insert into News (titreNews, texteNews, dateNews) VALUES
("+titreNews+", "+texteNews+", "+dateNews+)"
select @@id from machin truc
return newIdGenere
}


Bon apres, tu mets tes stringBuilder, tes tests, ta gestion de
connecttion, tes try catch, etc......

Mais l'esprit general est là.

Pareil pour tes select : news.loadNews(24) est cense te loader la news 24
dans ton objet. Dans ton objet, tu appelles ta requete sql en lui passant
ton idNews 24 . Et tu recup tes valeurs en retour, et dans ta couche
layer, tu joues aved ton objet et ses propriétés.

Etc, etc....

Si ou jour tu fais du mapping, ce sera la couche data qui fonctionnera
differement3. Mai ton objet continuera d'appeler un truc qui lui renverras
un DataSet en retour que tu transformera soit en objet soit en ArrayList
d'objet.

Apres, pour fignoler, tu te fais des fichiers properties dans ta couche
Business voir dans ta couche Data avec des valeures en static pour tes
parametres d'application ou toutes les valeurs à ecrire en dur susceptible
de changer un jour. Et là, le jour ou tu devras aller vers le multilangue
par exemple, tu vas apprécier :)

en plus je ne suis pas sûr de réussir à faire avaler la couche objet à
mes collègues alors une couche mapping n'en parlons pas ;o)

L'objet n'est pas tout le temps la panacé. Je sais, au début, ca surprend.
Mais en mode debug, quand tu place un break point juste avant le call
final à la base de donnee et que tu realises que la pile d'appel a explosé
les 20 methodes intermedaires entre la saisie dans le form et l'envoit à
ta base Oracle, tu commence à t'interroger sur les bienfait de l'usine à
gaz et les raisons evetuelles du ralentissement general constaté. Mais
bon, en meme temps, quand on fait du c#, il vaut mieux faire de l'objet :)

Bon courage

@ ++

Stef

> 1. Si je remplace mon mapping o/r actuel sur lequel j'ai très peu de
maitrise par une couche data de type Query comme dans les exemples que tu
me fournis, comment t'organises tu pour le découpage dans les fichiers :
une bibliothèque de classe (dll) NewsObjet et une bilbiotheque de classe
NewsData ? où finalement tout est dans la même dll et c'est la structure
même des méthodes et des appels à ces méthodes qui font qu'au final on a
une certaine indépendance entre les couches ?

Bah, tu crees bien deux truce tres differents. Pour bien t'obliger à passer
par la couche business pour aller taper dans la couche Data. Car sinon, la
tentation sera là, et..... tsssss tsssss...... : )))))

2. Je reviens sur la validation des données. J'ai donné l'exemple dans mon
1er post d'une méthode de suppression. Si dans certaines conditions je ne
peux pas supprimer une news comment je fais communiquer l'info d'une
couche à l'autre ?

ben ta methode de la couche data te tenvoit soit in int [nombre de rows
affectrés par le delete ou l'update] , soit un string [tes recherches de
idMachin, tes count(idTruc) ] , soit un dataset pour tes select a plusieurs
colonnes....

si tes tests sont metiers, tu les mets dams la couche metiers. Si ils sont
lies à ta technologie actuelle de diplay, tu les mets dans tes aspx.cs .
Apres, depuis ta couche business, tu lances ou non ta methode de Delete. Et
tu regarde ce qu'elle te renvoit pour voir si tu as reussi. Bon après, moi
je tente de passer par le moins d'intermediare possible, histoire de ne pas
provoquer trop de ralentissement non plus. Quitte à utiliser parfois des
librairies de statiques pour aller chercher mes infos, mais j'ai toujours
eté un peu bourrin.

Merci pour toutes tes réponses.

you're welcome :)

Stef