Je reposte ici car j'aimerais vraiment avoir des avis. En privé si vous
voulez, qu'on ne me souspçonne pas de jouer les troll. Je pense cependant
que ces questions peuvent intéresser tout le monde (dans un esprit
constructif bien sûr ;)
------------------------------------
>> Je serais curieux des avis de la communauté.
>
> et bien voici la mienne.. C'est bien vrai qu'il manque encore quelques
> petites choses que rendrait le Framework généralement plus plaisant. Je
> m'estime toutefois très sastisfait de ce qu'on peut y accomplir pour
> l'instant. La librarie de classe est quand même volumineuse si on compare
> aux quelques fonctions/méthodes que nous offraient VB 6.
C'est un peu le pb justement. Je précise pour éviter les ambiguïté que je
suis convaincu de la puissance de framework. C'est même la 1ère raison pour
laquelle j'ai choisi cette outil pour mon projet. La 2e c'était la
simplicité et l'intuitivité. Et là... La puissance c'est bien mais dans 90%
des cas, on fait des choses très simples. 90% des projets sont triviaux, et
90% des lignes de codes d'un projet complexe sont basiques. Donc je crois
que le plus important ce n'est pas la puissance mais la simplicité
(intuitivité, lisibilité, etc...) pour peu qu'on ait des solutions
alternatives.C'était le cas avec VB6. Pour le simple j'avais VB6. Le
champion du monde undisputed de la lisibilité. Quand ça devenait plus
compliqué (ce qui reste globalement l'exception) j'avais les API. Je n'ai
JAMAIS été bloqué avec cette solution (j'ai pourtant fait des trucs un peu
bas niveau et un peu système). Simplement, je ne me coltinais la difficulté
QUE lorsque j'en avais EFFECTIVEMENT besoin. Et là c'est vrai, la difficulté
était plus grande qu'avec le framework mais au moins, je savais pkoi je
suais. Là, ce qui m'horripile c'est de devoir se poser des questions et se
gratter la tête souvent pour faire des choses basiques (mais je suis peut
être le seul dans ce cas, j'aimerais savoir). Cest effectivement ce type de
doléances qui est à l'origine je crois, de l'apparition de "my" dans VS2005.
Et à côté de cette débauche de puisssance qu'est le framework, on manque de
certaines fonctionnalités élémentaires. Je prends qq exemples et je précise
que je peux me tromper, je débute sous .net. Mais le fait même que je me
gourre montrerait que la bonne solution ne saute pas au yeux (ou que je suis
une bille, c'est possible aussi :), ce qui est un pb en soi (j'ai choisi
cette solution pour aller vite !)
Je prends qques exemples (corrigez moi qd je me trompe):
1 - L'accès aux données : d'un côté j'ai une techno dataset super riche et
de l'autre :
- Les relations entre les tables ne sont pas automatiquement récupérées
de la base (PK, FK). Il faut toutes les créer à la main. C'est très long.
- Les noms par défaut : OLEDataAdaper1,2,3, etc. au lieu de rappeler le
nom des tables. Il faut tout renommer à la main. C'est très long.
- Les relations ne sont pas typées. J'ai une belle techno dataset typée
et les relations ne sont pas typée. Si je me gourre dans le nom d'une
relation sur un get_parent_rows (que j'ai du resaisir à la main je le
rappelle), je m'en rend compte qu'à l'exécution.Et encore, je n'ai même pas
d'erreur d'exécution, juste une erreur de la logique applicative, je peux ne
pas l'en rendre compte du tout ! Quitte à générer du code typé pourquoi
avoir d'un côté un beau type VendeurDataTable et de l'autre ne pas pour
faire MonVendeur.Ventes plutôt que MonVendeur.GetChildRows("Ventes") ?
- Des comportements étonnants.
--> Cf mon post "DefaultView et mise à jour de DataGrid et
databinding" du 09/02. C'est typiquement le genre de truc incompréhensible à
priori pour moi (je n'AI PAS et je NE VEUX PAS rentrer dans le
focntionnement interne des grid et des textbox pour comprendre, je n'ai pas
le temps)
- Impossible de filter uen datable d'un dataset pour son affichage dans
un form via des contrôles bindés (on ne peut que rendre un tableau de row).
Donc, après un bon moment, je finis par comprendre (je crois) qu'il faut
préférer binder sur des vues. Résultat : pour l'heure je n'arrive pas à
mettre à jour (aucun changement détectés dans le dataset sous-jacent).
Insupportable.
- Les vues ne sont pas typées. Si je travaille sur les vues, je perds
l'avantage du typage. En gros, tout àa mis bout à bout, pour moi ça fiche
par terre, l'intérêt des dataset typés. Dommage quand même...
- Le pire (pour moi). Pas de mapping O/R. Je sais, ça y travaille. Mais
quand on sort une plateforme qui met à ce point en avant l'orientation
objet, je trouve ça limite. En tout cas, moi ça me coûte du temps (et les
bon outils tiers sont chers). Enfin je sais que c'est pas un sujet simple...
2 - Un langage très verbeux. C'est lié à la richesse fonctionnelle mais voir
ma 1ère remarque sur le sujet. C'est poluant dans la pluspart des cas
puisque dans la plupart des cas on fait simple. Résultat, il faut wrapper
soit même les fonctionnalité riches/complexes pour ne pas se trimballer
systématiquement un tank pour écraser une mouche. C'est ce que fait par
exemple le Data Access Block. Donc à mon avis MS en est conscient.
Voir mon post "Re: Objet performance drawing.image." du 17/01 : VB6 : 7
lignes, 133 carcatères / VB.Net : 8 l, 296 c. Dans cet exemple, le pire
c'est que c'est même pas VB.Net Vs VB6, c'est VB.Net Vs VB6 + API Win32 !
Vainqueur lisibilité, concision : VB6.
ou encore (trouvé sur un ng) :
------------------------
Whereas in VB6 you might see.
TreeView1.Nodes.Add 1, 1, "Key", "text", 2, 3
the equivalent in VB.Net might be.
Dim oNode As New System.Windows.Form.TreeNode
oNode.Text = "Text"
oNode.ImageIndex = 2
oNode.SelectedImageIndex = 3
TreeView1.nodes.add oNode
------------------------
3 - Pleins de petites autres choses (souvent de petites régressions, l'aide
en ligne insuffisante voir indigente dans certains cas, pas de Nested child
en XML, etc...) que je veux bien mettre sur le compte de défauts de jeunesse
mais qd mm énervantes parceque demandant toujours un petit effort
supplémentaire. En gros, on passe 5 ou 10 mn là où on pensait en passer 1
(exemple Key sur le treenode). Multiplier par X sur un projet....
Je serais ravi qu'on m'explique que je me gourre sur la plupart des points.
Avis à tous.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Sebastien
Salut,
personnellement je suis passer de vb6 a vb.net et je ne le regrette pas. (a par qq probleme avec des api, mais on ma toujours donnée une reponse ou une solution, c'etait plutot mon manque de connaissance du language qui est en cause.)
pour ce qui est de l'acces au donnée j'ai developper mes propre générateur de class qui ce base sur celle de .net, j'ai donc tous ce que je veux, l'intelisens sur les table et champs, les relation géré , pas sur les noms de champs(comme c le cas) mais sur les relation effectivement créé ...
et tous sa sans toute les complexiter des DataSet.
pour le reste je trouve que beaucoup de chose on ete rajouter et facilite le developpement, avec qq habitude a change (les index des composant qui n'existe plus, les onglet que l'on ne peu pas cacher,..) mais en contrepartie on a la possibiliter de fair des chose qui etait tres compliquer avans et qui sont toute simple maintenans (encrage des objects, plus de code pour le resize des form ...)
pour les picturesbox, il ne gere plus le systeme scalaire (enfin je me trompe peut etre mais je voie plus les scalWidth, ... existe t'il une autre methode ?)
et les key dans le teeview c claire que sa manque ...
voila y a du pour et du contre, mais dans l'ensemble j'ai gagné plus de temps que j'en est perdu, ... et je trouve le language tellement plus sympa ! ;-)
a++ sebastien
"Patrice Ongla" a écrit dans le message de news: 420c9174$0$631$
Je reposte ici car j'aimerais vraiment avoir des avis. En privé si vous voulez, qu'on ne me souspçonne pas de jouer les troll. Je pense cependant que ces questions peuvent intéresser tout le monde (dans un esprit constructif bien sûr ;)
------------------------------------
Je serais curieux des avis de la communauté.
et bien voici la mienne.. C'est bien vrai qu'il manque encore quelques petites choses que rendrait le Framework généralement plus plaisant. Je m'estime toutefois très sastisfait de ce qu'on peut y accomplir pour l'instant. La librarie de classe est quand même volumineuse si on compare aux quelques fonctions/méthodes que nous offraient VB 6.
C'est un peu le pb justement. Je précise pour éviter les ambiguïté que je suis convaincu de la puissance de framework. C'est même la 1ère raison pour laquelle j'ai choisi cette outil pour mon projet. La 2e c'était la simplicité et l'intuitivité. Et là... La puissance c'est bien mais dans 90% des cas, on fait des choses très simples. 90% des projets sont triviaux, et 90% des lignes de codes d'un projet complexe sont basiques. Donc je crois que le plus important ce n'est pas la puissance mais la simplicité (intuitivité, lisibilité, etc...) pour peu qu'on ait des solutions alternatives.C'était le cas avec VB6. Pour le simple j'avais VB6. Le champion du monde undisputed de la lisibilité. Quand ça devenait plus compliqué (ce qui reste globalement l'exception) j'avais les API. Je n'ai JAMAIS été bloqué avec cette solution (j'ai pourtant fait des trucs un peu bas niveau et un peu système). Simplement, je ne me coltinais la difficulté QUE lorsque j'en avais EFFECTIVEMENT besoin. Et là c'est vrai, la difficulté était plus grande qu'avec le framework mais au moins, je savais pkoi je suais. Là, ce qui m'horripile c'est de devoir se poser des questions et se gratter la tête souvent pour faire des choses basiques (mais je suis peut être le seul dans ce cas, j'aimerais savoir). Cest effectivement ce type de doléances qui est à l'origine je crois, de l'apparition de "my" dans VS2005. Et à côté de cette débauche de puisssance qu'est le framework, on manque de certaines fonctionnalités élémentaires. Je prends qq exemples et je précise que je peux me tromper, je débute sous .net. Mais le fait même que je me gourre montrerait que la bonne solution ne saute pas au yeux (ou que je suis une bille, c'est possible aussi :), ce qui est un pb en soi (j'ai choisi cette solution pour aller vite !) Je prends qques exemples (corrigez moi qd je me trompe):
1 - L'accès aux données : d'un côté j'ai une techno dataset super riche et de l'autre : - Les relations entre les tables ne sont pas automatiquement récupérées de la base (PK, FK). Il faut toutes les créer à la main. C'est très long. - Les noms par défaut : OLEDataAdaper1,2,3, etc. au lieu de rappeler le nom des tables. Il faut tout renommer à la main. C'est très long. - Les relations ne sont pas typées. J'ai une belle techno dataset typée et les relations ne sont pas typée. Si je me gourre dans le nom d'une relation sur un get_parent_rows (que j'ai du resaisir à la main je le rappelle), je m'en rend compte qu'à l'exécution.Et encore, je n'ai même pas d'erreur d'exécution, juste une erreur de la logique applicative, je peux ne pas l'en rendre compte du tout ! Quitte à générer du code typé pourquoi avoir d'un côté un beau type VendeurDataTable et de l'autre ne pas pour faire MonVendeur.Ventes plutôt que MonVendeur.GetChildRows("Ventes") ? - Des comportements étonnants. --> Cf mon post "DefaultView et mise à jour de DataGrid et databinding" du 09/02. C'est typiquement le genre de truc incompréhensible à priori pour moi (je n'AI PAS et je NE VEUX PAS rentrer dans le focntionnement interne des grid et des textbox pour comprendre, je n'ai pas le temps) - Impossible de filter uen datable d'un dataset pour son affichage dans un form via des contrôles bindés (on ne peut que rendre un tableau de row). Donc, après un bon moment, je finis par comprendre (je crois) qu'il faut préférer binder sur des vues. Résultat : pour l'heure je n'arrive pas à mettre à jour (aucun changement détectés dans le dataset sous-jacent). Insupportable. - Les vues ne sont pas typées. Si je travaille sur les vues, je perds l'avantage du typage. En gros, tout àa mis bout à bout, pour moi ça fiche par terre, l'intérêt des dataset typés. Dommage quand même... - Le pire (pour moi). Pas de mapping O/R. Je sais, ça y travaille. Mais quand on sort une plateforme qui met à ce point en avant l'orientation objet, je trouve ça limite. En tout cas, moi ça me coûte du temps (et les bon outils tiers sont chers). Enfin je sais que c'est pas un sujet simple...
2 - Un langage très verbeux. C'est lié à la richesse fonctionnelle mais voir ma 1ère remarque sur le sujet. C'est poluant dans la pluspart des cas puisque dans la plupart des cas on fait simple. Résultat, il faut wrapper soit même les fonctionnalité riches/complexes pour ne pas se trimballer systématiquement un tank pour écraser une mouche. C'est ce que fait par exemple le Data Access Block. Donc à mon avis MS en est conscient.
Voir mon post "Re: Objet performance drawing.image." du 17/01 : VB6 : 7 lignes, 133 carcatères / VB.Net : 8 l, 296 c. Dans cet exemple, le pire c'est que c'est même pas VB.Net Vs VB6, c'est VB.Net Vs VB6 + API Win32 ! Vainqueur lisibilité, concision : VB6.
ou encore (trouvé sur un ng) : ------------------------ Whereas in VB6 you might see. TreeView1.Nodes.Add 1, 1, "Key", "text", 2, 3
the equivalent in VB.Net might be. Dim oNode As New System.Windows.Form.TreeNode oNode.Text = "Text" oNode.ImageIndex = 2 oNode.SelectedImageIndex = 3 TreeView1.nodes.add oNode ------------------------
3 - Pleins de petites autres choses (souvent de petites régressions, l'aide en ligne insuffisante voir indigente dans certains cas, pas de Nested child en XML, etc...) que je veux bien mettre sur le compte de défauts de jeunesse mais qd mm énervantes parceque demandant toujours un petit effort supplémentaire. En gros, on passe 5 ou 10 mn là où on pensait en passer 1 (exemple Key sur le treenode). Multiplier par X sur un projet....
Je serais ravi qu'on m'explique que je me gourre sur la plupart des points. Avis à tous.
Salut,
personnellement je suis passer de vb6 a vb.net et je ne le regrette pas. (a
par qq probleme avec des api, mais on ma toujours donnée une reponse ou une
solution, c'etait plutot mon manque de connaissance du language qui est en
cause.)
pour ce qui est de l'acces au donnée j'ai developper mes propre générateur
de class qui ce base sur celle de .net, j'ai donc tous ce que je veux,
l'intelisens sur les table et champs, les relation géré , pas sur les noms
de champs(comme c le cas) mais sur les relation effectivement créé ...
et tous sa sans toute les complexiter des DataSet.
pour le reste je trouve que beaucoup de chose on ete rajouter et facilite le
developpement, avec qq habitude a change (les index des composant qui
n'existe plus, les onglet que l'on ne peu pas cacher,..) mais en
contrepartie on a la possibiliter de fair des chose qui etait tres
compliquer avans et qui sont toute simple maintenans (encrage des objects,
plus de code pour le resize des form ...)
pour les picturesbox, il ne gere plus le systeme scalaire (enfin je me
trompe peut etre mais je voie plus les scalWidth, ... existe t'il une autre
methode ?)
et les key dans le teeview c claire que sa manque ...
voila y a du pour et du contre, mais dans l'ensemble j'ai gagné plus de
temps que j'en est perdu, ... et je trouve le language tellement plus sympa
! ;-)
a++
sebastien
"Patrice Ongla" <ongla@free.fr> a écrit dans le message de news:
420c9174$0$631$636a15ce@news.free.fr...
Je reposte ici car j'aimerais vraiment avoir des avis. En privé si vous
voulez, qu'on ne me souspçonne pas de jouer les troll. Je pense cependant
que ces questions peuvent intéresser tout le monde (dans un esprit
constructif bien sûr ;)
------------------------------------
Je serais curieux des avis de la communauté.
et bien voici la mienne.. C'est bien vrai qu'il manque encore quelques
petites choses que rendrait le Framework généralement plus plaisant. Je
m'estime toutefois très sastisfait de ce qu'on peut y accomplir pour
l'instant. La librarie de classe est quand même volumineuse si on compare
aux quelques fonctions/méthodes que nous offraient VB 6.
C'est un peu le pb justement. Je précise pour éviter les ambiguïté que je
suis convaincu de la puissance de framework. C'est même la 1ère raison
pour
laquelle j'ai choisi cette outil pour mon projet. La 2e c'était la
simplicité et l'intuitivité. Et là... La puissance c'est bien mais dans
90%
des cas, on fait des choses très simples. 90% des projets sont triviaux,
et
90% des lignes de codes d'un projet complexe sont basiques. Donc je crois
que le plus important ce n'est pas la puissance mais la simplicité
(intuitivité, lisibilité, etc...) pour peu qu'on ait des solutions
alternatives.C'était le cas avec VB6. Pour le simple j'avais VB6. Le
champion du monde undisputed de la lisibilité. Quand ça devenait plus
compliqué (ce qui reste globalement l'exception) j'avais les API. Je n'ai
JAMAIS été bloqué avec cette solution (j'ai pourtant fait des trucs un peu
bas niveau et un peu système). Simplement, je ne me coltinais la
difficulté
QUE lorsque j'en avais EFFECTIVEMENT besoin. Et là c'est vrai, la
difficulté
était plus grande qu'avec le framework mais au moins, je savais pkoi je
suais. Là, ce qui m'horripile c'est de devoir se poser des questions et se
gratter la tête souvent pour faire des choses basiques (mais je suis peut
être le seul dans ce cas, j'aimerais savoir). Cest effectivement ce type
de
doléances qui est à l'origine je crois, de l'apparition de "my" dans
VS2005.
Et à côté de cette débauche de puisssance qu'est le framework, on manque
de
certaines fonctionnalités élémentaires. Je prends qq exemples et je
précise
que je peux me tromper, je débute sous .net. Mais le fait même que je me
gourre montrerait que la bonne solution ne saute pas au yeux (ou que je
suis
une bille, c'est possible aussi :), ce qui est un pb en soi (j'ai choisi
cette solution pour aller vite !)
Je prends qques exemples (corrigez moi qd je me trompe):
1 - L'accès aux données : d'un côté j'ai une techno dataset super riche et
de l'autre :
- Les relations entre les tables ne sont pas automatiquement récupérées
de la base (PK, FK). Il faut toutes les créer à la main. C'est très long.
- Les noms par défaut : OLEDataAdaper1,2,3, etc. au lieu de rappeler le
nom des tables. Il faut tout renommer à la main. C'est très long.
- Les relations ne sont pas typées. J'ai une belle techno dataset typée
et les relations ne sont pas typée. Si je me gourre dans le nom d'une
relation sur un get_parent_rows (que j'ai du resaisir à la main je le
rappelle), je m'en rend compte qu'à l'exécution.Et encore, je n'ai même
pas
d'erreur d'exécution, juste une erreur de la logique applicative, je peux
ne
pas l'en rendre compte du tout ! Quitte à générer du code typé pourquoi
avoir d'un côté un beau type VendeurDataTable et de l'autre ne pas pour
faire MonVendeur.Ventes plutôt que MonVendeur.GetChildRows("Ventes") ?
- Des comportements étonnants.
--> Cf mon post "DefaultView et mise à jour de DataGrid et
databinding" du 09/02. C'est typiquement le genre de truc incompréhensible
à
priori pour moi (je n'AI PAS et je NE VEUX PAS rentrer dans le
focntionnement interne des grid et des textbox pour comprendre, je n'ai
pas
le temps)
- Impossible de filter uen datable d'un dataset pour son affichage dans
un form via des contrôles bindés (on ne peut que rendre un tableau de
row).
Donc, après un bon moment, je finis par comprendre (je crois) qu'il faut
préférer binder sur des vues. Résultat : pour l'heure je n'arrive pas à
mettre à jour (aucun changement détectés dans le dataset sous-jacent).
Insupportable.
- Les vues ne sont pas typées. Si je travaille sur les vues, je perds
l'avantage du typage. En gros, tout àa mis bout à bout, pour moi ça fiche
par terre, l'intérêt des dataset typés. Dommage quand même...
- Le pire (pour moi). Pas de mapping O/R. Je sais, ça y travaille. Mais
quand on sort une plateforme qui met à ce point en avant l'orientation
objet, je trouve ça limite. En tout cas, moi ça me coûte du temps (et les
bon outils tiers sont chers). Enfin je sais que c'est pas un sujet
simple...
2 - Un langage très verbeux. C'est lié à la richesse fonctionnelle mais
voir
ma 1ère remarque sur le sujet. C'est poluant dans la pluspart des cas
puisque dans la plupart des cas on fait simple. Résultat, il faut wrapper
soit même les fonctionnalité riches/complexes pour ne pas se trimballer
systématiquement un tank pour écraser une mouche. C'est ce que fait par
exemple le Data Access Block. Donc à mon avis MS en est conscient.
Voir mon post "Re: Objet performance drawing.image." du 17/01 : VB6 : 7
lignes, 133 carcatères / VB.Net : 8 l, 296 c. Dans cet exemple, le pire
c'est que c'est même pas VB.Net Vs VB6, c'est VB.Net Vs VB6 + API Win32 !
Vainqueur lisibilité, concision : VB6.
ou encore (trouvé sur un ng) :
------------------------
Whereas in VB6 you might see.
TreeView1.Nodes.Add 1, 1, "Key", "text", 2, 3
the equivalent in VB.Net might be.
Dim oNode As New System.Windows.Form.TreeNode
oNode.Text = "Text"
oNode.ImageIndex = 2
oNode.SelectedImageIndex = 3
TreeView1.nodes.add oNode
------------------------
3 - Pleins de petites autres choses (souvent de petites régressions,
l'aide
en ligne insuffisante voir indigente dans certains cas, pas de Nested
child
en XML, etc...) que je veux bien mettre sur le compte de défauts de
jeunesse
mais qd mm énervantes parceque demandant toujours un petit effort
supplémentaire. En gros, on passe 5 ou 10 mn là où on pensait en passer 1
(exemple Key sur le treenode). Multiplier par X sur un projet....
Je serais ravi qu'on m'explique que je me gourre sur la plupart des
points.
Avis à tous.
personnellement je suis passer de vb6 a vb.net et je ne le regrette pas. (a par qq probleme avec des api, mais on ma toujours donnée une reponse ou une solution, c'etait plutot mon manque de connaissance du language qui est en cause.)
pour ce qui est de l'acces au donnée j'ai developper mes propre générateur de class qui ce base sur celle de .net, j'ai donc tous ce que je veux, l'intelisens sur les table et champs, les relation géré , pas sur les noms de champs(comme c le cas) mais sur les relation effectivement créé ...
et tous sa sans toute les complexiter des DataSet.
pour le reste je trouve que beaucoup de chose on ete rajouter et facilite le developpement, avec qq habitude a change (les index des composant qui n'existe plus, les onglet que l'on ne peu pas cacher,..) mais en contrepartie on a la possibiliter de fair des chose qui etait tres compliquer avans et qui sont toute simple maintenans (encrage des objects, plus de code pour le resize des form ...)
pour les picturesbox, il ne gere plus le systeme scalaire (enfin je me trompe peut etre mais je voie plus les scalWidth, ... existe t'il une autre methode ?)
et les key dans le teeview c claire que sa manque ...
voila y a du pour et du contre, mais dans l'ensemble j'ai gagné plus de temps que j'en est perdu, ... et je trouve le language tellement plus sympa ! ;-)
a++ sebastien
"Patrice Ongla" a écrit dans le message de news: 420c9174$0$631$
Je reposte ici car j'aimerais vraiment avoir des avis. En privé si vous voulez, qu'on ne me souspçonne pas de jouer les troll. Je pense cependant que ces questions peuvent intéresser tout le monde (dans un esprit constructif bien sûr ;)
------------------------------------
Je serais curieux des avis de la communauté.
et bien voici la mienne.. C'est bien vrai qu'il manque encore quelques petites choses que rendrait le Framework généralement plus plaisant. Je m'estime toutefois très sastisfait de ce qu'on peut y accomplir pour l'instant. La librarie de classe est quand même volumineuse si on compare aux quelques fonctions/méthodes que nous offraient VB 6.
C'est un peu le pb justement. Je précise pour éviter les ambiguïté que je suis convaincu de la puissance de framework. C'est même la 1ère raison pour laquelle j'ai choisi cette outil pour mon projet. La 2e c'était la simplicité et l'intuitivité. Et là... La puissance c'est bien mais dans 90% des cas, on fait des choses très simples. 90% des projets sont triviaux, et 90% des lignes de codes d'un projet complexe sont basiques. Donc je crois que le plus important ce n'est pas la puissance mais la simplicité (intuitivité, lisibilité, etc...) pour peu qu'on ait des solutions alternatives.C'était le cas avec VB6. Pour le simple j'avais VB6. Le champion du monde undisputed de la lisibilité. Quand ça devenait plus compliqué (ce qui reste globalement l'exception) j'avais les API. Je n'ai JAMAIS été bloqué avec cette solution (j'ai pourtant fait des trucs un peu bas niveau et un peu système). Simplement, je ne me coltinais la difficulté QUE lorsque j'en avais EFFECTIVEMENT besoin. Et là c'est vrai, la difficulté était plus grande qu'avec le framework mais au moins, je savais pkoi je suais. Là, ce qui m'horripile c'est de devoir se poser des questions et se gratter la tête souvent pour faire des choses basiques (mais je suis peut être le seul dans ce cas, j'aimerais savoir). Cest effectivement ce type de doléances qui est à l'origine je crois, de l'apparition de "my" dans VS2005. Et à côté de cette débauche de puisssance qu'est le framework, on manque de certaines fonctionnalités élémentaires. Je prends qq exemples et je précise que je peux me tromper, je débute sous .net. Mais le fait même que je me gourre montrerait que la bonne solution ne saute pas au yeux (ou que je suis une bille, c'est possible aussi :), ce qui est un pb en soi (j'ai choisi cette solution pour aller vite !) Je prends qques exemples (corrigez moi qd je me trompe):
1 - L'accès aux données : d'un côté j'ai une techno dataset super riche et de l'autre : - Les relations entre les tables ne sont pas automatiquement récupérées de la base (PK, FK). Il faut toutes les créer à la main. C'est très long. - Les noms par défaut : OLEDataAdaper1,2,3, etc. au lieu de rappeler le nom des tables. Il faut tout renommer à la main. C'est très long. - Les relations ne sont pas typées. J'ai une belle techno dataset typée et les relations ne sont pas typée. Si je me gourre dans le nom d'une relation sur un get_parent_rows (que j'ai du resaisir à la main je le rappelle), je m'en rend compte qu'à l'exécution.Et encore, je n'ai même pas d'erreur d'exécution, juste une erreur de la logique applicative, je peux ne pas l'en rendre compte du tout ! Quitte à générer du code typé pourquoi avoir d'un côté un beau type VendeurDataTable et de l'autre ne pas pour faire MonVendeur.Ventes plutôt que MonVendeur.GetChildRows("Ventes") ? - Des comportements étonnants. --> Cf mon post "DefaultView et mise à jour de DataGrid et databinding" du 09/02. C'est typiquement le genre de truc incompréhensible à priori pour moi (je n'AI PAS et je NE VEUX PAS rentrer dans le focntionnement interne des grid et des textbox pour comprendre, je n'ai pas le temps) - Impossible de filter uen datable d'un dataset pour son affichage dans un form via des contrôles bindés (on ne peut que rendre un tableau de row). Donc, après un bon moment, je finis par comprendre (je crois) qu'il faut préférer binder sur des vues. Résultat : pour l'heure je n'arrive pas à mettre à jour (aucun changement détectés dans le dataset sous-jacent). Insupportable. - Les vues ne sont pas typées. Si je travaille sur les vues, je perds l'avantage du typage. En gros, tout àa mis bout à bout, pour moi ça fiche par terre, l'intérêt des dataset typés. Dommage quand même... - Le pire (pour moi). Pas de mapping O/R. Je sais, ça y travaille. Mais quand on sort une plateforme qui met à ce point en avant l'orientation objet, je trouve ça limite. En tout cas, moi ça me coûte du temps (et les bon outils tiers sont chers). Enfin je sais que c'est pas un sujet simple...
2 - Un langage très verbeux. C'est lié à la richesse fonctionnelle mais voir ma 1ère remarque sur le sujet. C'est poluant dans la pluspart des cas puisque dans la plupart des cas on fait simple. Résultat, il faut wrapper soit même les fonctionnalité riches/complexes pour ne pas se trimballer systématiquement un tank pour écraser une mouche. C'est ce que fait par exemple le Data Access Block. Donc à mon avis MS en est conscient.
Voir mon post "Re: Objet performance drawing.image." du 17/01 : VB6 : 7 lignes, 133 carcatères / VB.Net : 8 l, 296 c. Dans cet exemple, le pire c'est que c'est même pas VB.Net Vs VB6, c'est VB.Net Vs VB6 + API Win32 ! Vainqueur lisibilité, concision : VB6.
ou encore (trouvé sur un ng) : ------------------------ Whereas in VB6 you might see. TreeView1.Nodes.Add 1, 1, "Key", "text", 2, 3
the equivalent in VB.Net might be. Dim oNode As New System.Windows.Form.TreeNode oNode.Text = "Text" oNode.ImageIndex = 2 oNode.SelectedImageIndex = 3 TreeView1.nodes.add oNode ------------------------
3 - Pleins de petites autres choses (souvent de petites régressions, l'aide en ligne insuffisante voir indigente dans certains cas, pas de Nested child en XML, etc...) que je veux bien mettre sur le compte de défauts de jeunesse mais qd mm énervantes parceque demandant toujours un petit effort supplémentaire. En gros, on passe 5 ou 10 mn là où on pensait en passer 1 (exemple Key sur le treenode). Multiplier par X sur un projet....
Je serais ravi qu'on m'explique que je me gourre sur la plupart des points. Avis à tous.
