Discussion :

[star]

Pourriez-vous m'expliquer comment Microsoft procède à la diffusion des correctifs de bugs du .NET Framework ?
Est-ce effectué au fil de l'eau intégré aux Windows Update au fur et à mesure des mises à jour ?
Ou faut-il attendre les nouvelles releases du Framework 4.7.x ?
Merci
.

[Pol63]

Un programme .net cible un framework (genre 4.6)
Et quand ils ont une mise à jour de celui ci c'est genre 4.6.1 et windows update fait le reste
Et j'ose imaginer que c'est automatiquement le nouveau qui est utilisé.

Mais il y a très peu de bugs dans le Framework conventionnel

[star]

Sauf que le peu de bugs qu'il puisse y avoir est dans certains cas très bloquant... Comme ici : https://www.developpez.net/forums/d1...a/#post9450831

[DotNetMatt]

Yes, avec Core ca risque de changer un peu car la plupart des assembly "systeme" sont disponibles via NuGet, donc il suffira de mettre a jour ses packages. A voir ce qui va se passer de ce cote !

Sinon pour ton probleme, vu que tu n'as receuilli aucun vote sur ton bug, je doute que ca soit la priorite de Microsoft En effet plus il y a de votes, plus c'est considere comme genant et impactant pour la communaute.

Comme indique sur ton autre post, pourquoi ne pas changer de technique et utiliser MVVM ?

- Les DataTables, DataSet, etc. ca fait partie de la prehistoire de .NET. C'etait utile a l'epoque ou les listes (IEnumerable, ICollection, IList, etc.) n'existaient pas. Ces classes viennent avec un certain overhead du a toutes les fonctionnalites embarquees par defaut et que tu n'utilises probablement pas (je dis bien, probablement, car je ne connais pas ton projet).
- WPF s'utilise avec des patterns, comme MVVM ou encore Prism. Il peut etre hasardeux de vouloir reproduire exactement du code WinForms en WPF...

Bref, pour ton bug, la patience surement sera ton meilleur allie.

[star]

Merci DotNetMatt pour ta contribution à ce post.

Tu as sans doute raison en disant que ADO.NET est d'un autre temps, sans doute un peu comme moi. Pour tout te dire, je me suis réellement adonné au .NET à partir de l'année dernière, bien que ma première approche remonte en 2012 avec VS2008 après les MFC. Si l'on reprend l'historique du .NET Framework et du C#, sa mise sur le marché date de l'année 2000, donc il y a 16 ans. Pas si préhistorique que cela à comparer à d'autres technos, comme par exemple, le langage Cobol utilisé avec le moniteur transactionnel DTF qui tournait sous GCOS6 - Bull DPS6000. On parle alors d'y a 30 ans avant même l'invention de l'IBM PC. Le grand frère, le BULL DPS8000 sous GCOS8 est toujours en exploitation, me semble-t-il.

Non, à mon goût ADO.NET est une bonne API pour la gestion des données, efficace et complète, qui épargne l'écriture de code par le développeur. Je ne connait pas encore assez bien le pattern MVVM, mais c'est ce que je compte aborder assez rapidement maintenant. Toi qui manifestement maitrise ce pattern ainsi que ADO.NET, peux-tu dire lequel des deux demande plus d'écriture de code pour des fonctionnalités minimalistes identiques ?

Sur ta dernière remarque "Il peut etre hasardeux de vouloir reproduire exactement du code WinForms en WPF", je ne suis pas tout à fait d'accord avec toi. Mon projet de test qui reproduit une interface utilisateur de type Maitre/Détails avec l'utilisation de contrôles DataGrid WPF en lieu et place de contrôles DataGridView WinForms, et d'ADO.NET pour l'accès aux données, reste assez simple à réaliser et pas du tout hasardeux. Toutes les fonctionnalités d'affichage, de mise à jour CRUD, de validation et d'interface avec la source de données sont reproduites avec très peu de différences dans l'écriture du code. Je ne sais pas encore si avec le pattern MVVM on peut très bien en faire autant et aussi facilement. J'ai juste ce bug avec l'API WPF (voir mon autre post pour une présentation du bug) et qui ne concerne nullement ADO.NET, je tiens à le préciser.

Pour ceux que cela intéresse, un lien sur mon projet de test : https://drive.google.com/file/d/0B64...ew?usp=sharing
Mon feedback au Support Microsoft : https://connect.microsoft.com/Visual...wupdated-event
Le compteur commence à grimper. Allez-y voter (:

J'en profite pour te demander s'il te serait possible de me suggérer un lien sur un bon tutorial portant sur le pattern MVVM et une référence de livre sur le sujet ? Que veux-tu difficile de changer passer un certain âge. De mon époque Internet n'existait pas (il n'y avait que le minitel rose) et nous n'avions alors que la documentation officielle en langue anglaise, s'il vous plait.
.

[DotNetMatt]

Tu as sans doute raison en disant que ADO.NET est d'un autre temps, sans doute un peu comme moi.

Attention je n'ai pas dit qu'ADO.NET etait d'un autre temps, je parle juste des classes DataSet, DataTable, etc. ADO.NET est toujours utilise aujourd'hui et je confirme que c'est une tres bonne API, pas de souci de ce cote-la. Les classes Dataxxx sont juste des "modules" qui utilisent l'API ADO.NET sous le capot.

Ce qu'il faut retenir c'est qu'a l'epoque ou .NET est sorti (on parle des annees 2000 comme tu l'as indique), les listes d'objets n'existaient pas. Pour pemettre de gerer cela, Microsoft avait alors mis au point ces fameuses classes DataSet, DataTable, DataView... Mais depuis, Microsoft a publie d'autres mecanismes de gestion de listes d'objets plus simples a utiliser et sans tout l'overhead genere par les vieilles classes. On peut utiliser LinQ sur ces listes d'objets pour les manipuler. LinQ equivaut a un pseudo SQL en C# / VB.NET.

Ces nouvelles classes sont basees sur les interfaces IEnumerable, ICollection, IList, etc. On pourrait les comparer a des Array mais avec des fonctionnalites un poil plus evoluees, mais en restant tres light compare aux classes Dataxxx. Avec ces nouvelles classes, c'est a toi d'utiliser l'API ADO.NET, l'avantage etant que tu controles finement ce que tu fais, et que tu ne codes que ce dont tu as besoin.

Pour tout te dire, je me suis réellement adonné au .NET à partir de l'année dernière, bien que ma première approche remonte en 2012 avec VS2008 après les MFC. Si l'on reprend l'historique du .NET Framework et du C#, sa mise sur le marché date de l'année 2000, donc il y a 16 ans. Pas si préhistorique que cela à comparer à d'autres technos, comme par exemple, le langage Cobol utilisé avec le moniteur transactionnel DTF qui tournait sous GCOS6 - Bull DPS6000. On parle alors d'y a 30 ans avant même l'invention de l'IBM PC. Le grand frère, le BULL DPS8000 sous GCOS8 est toujours en exploitation, me semble-t-il.

Effectivement je devrais mesurer mes propos par rapport a l'histoire de l'informatique

Non, à mon goût ADO.NET est une bonne API pour la gestion des données, efficace et complète, qui épargne l'écriture de code par le développeur. Je ne connait pas encore assez bien le pattern MVVM, mais c'est ce que je compte aborder assez rapidement maintenant. Toi qui manifestement maitrise ce pattern ainsi que ADO.NET, peux-tu dire lequel des deux demande plus d'écriture de code pour des fonctionnalités minimalistes identiques ?

C'est probablement MVVM qui va te demander un peu plus travail, mais au final tu auras une application mieux structuree et decoupee. Apres, vaut-il mieux avoir une application "brouillon" (je met les guillemets) ou une application plus professionnelle, ca depend de ton projet, du budget, des delais, de la strategie IT, etc.

Au final pour resoudre le genre de probleme que tu rencontres, tu finiras peut-etre par ecrire autant de code, ou par perdre enormement de temps pour trouver un paliatif. Tu es le seul et meilleur juge pour determiner ce qu'il faut faire.

Sur ta dernière remarque "Il peut etre hasardeux de vouloir reproduire exactement du code WinForms en WPF", je ne suis pas tout à fait d'accord avec toi. Mon projet de test qui reproduit une interface utilisateur de type Maitre/Détails avec l'utilisation de contrôles DataGrid WPF en lieu et place de contrôles DataGridView WinForms, et d'ADO.NET pour l'accès aux données, reste assez simple à réaliser et pas du tout hasardeux. Toutes les fonctionnalités d'affichage, de mise à jour CRUD, de validation et d'interface avec la source de données sont reproduites avec très peu de différences dans l'écriture du code. Je ne sais pas encore si avec le pattern MVVM on peut très bien en faire autant et aussi facilement. J'ai juste ce bug avec l'API WPF (voir mon autre post pour une présentation du bug) et qui ne concerne nullement ADO.NET, il faut le préciser.

En effet, le bug concerne le WPF j'en ai bien conscience, mais il peut etre induit par l'utilisation des classes Dataxxx, qui je le repete ne sont pas l'API ADO.NET elle-meme.

Pour ceux que cela intéresse, un lien sur mon projet de test : https://drive.google.com/file/d/0B64...ew?usp=sharing
J'ai le compteur qui commence à grimper. Allez-y voter (:

Merci de partager ca ! Si tu ne connais pas, tu peux utiliser GitHub pour heberger gratuitement tes projets en ligne en Open Source (differentes licenses sont disponibles). L'avantage c'est que ca te permet de beneficier d'un gestionnaire de code source gratuitement, tout en t'offrant de la visibilite dans la communaute. Voici un exemple de projet heberge : https://github.com/joeaudette/clouds...Web.Navigation

J'en profite pour te demander s'il te serait possible de me suggérer un lien sur un bon tutorial portant sur le pattern MVVM et une référence de livre sur le sujet ? Que veux-tu difficile de changer passer un certain âge. De mon époque Internet n'existait pas (il n'y avait que le minitel rose) et nous n'avions alors que la documentation officielle en langue anglaise, s'il vous plait..

Il y a pas mal de tutos sur notre communaute : Windows Presentation Foundation. Si tu remontes tout en haut de la page, tu verras qu'il y a aussi des tutos sur pas mal de sujets autour de C#, incluant un cours complet sur C# : Cours complet pour apprendre C#

[EDIT} Voici un tuto MVVM en Francais : Comment tirer efficacement parti des avantages de WPF tout en gardant une application maintenable et testable ?

A noter, il n'y a pas que MVVM, il existe aussi MVP ou encore Prism, voire meme MVVM Light....

[star]

Les classes Dataxxx sont juste des "modules" qui utilisent l'API ADO.NET sous le capot

Pourtant, Microsoft présente la chose tout autrement. Tout l'intérêt d'ADO.NET se situe justement dans le mode déconnecté incarné par le Dataset, et pas du tout dans les commandes héritées de l'ancêtre ADO tout cours.

Ce qu'il faut retenir c'est qu'a l'epoque ou .NET est sorti (on parle des annees 2000 comme tu l'as indique), les listes d'objets n'existaient pas.

Absolument pas, les collections non typées existaient dès l'origine.

Ces nouvelles classes sont basees sur les interfaces IEnumerable, ICollection, IList, etc. On pourrait les comparer a des Array mais avec des fonctionnalites un poil plus evoluees, mais en restant tres light compare aux classes Dataxxx.

La classe Dataview prend en compte l'interface IBindingList me trompe-je ?

Apres, vaut-il mieux avoir une application "brouillon" (je met les guillemets) ou une application plus professionnelle

On peut très bien faire du "brouillon" (je met les guillemets) en MVVM tout pareil.

En effet, le bug concerne le WPF j'en ai bien conscience, mais il peut etre induit par l'utilisation des classes Dataxxx, qui je le repete ne sont pas l'API ADO.NET elle-meme.

Comme je l'indique plus haut, je ne suis absolument pas d'accord avec ton affirmation concernant les classes Dataxxx.

L'avantage c'est que ca te permet de beneficier d'un gestionnaire de code source gratuitement, tout en t'offrant de la visibilite dans la communaute.

Je n'ai aucune utilité pour ce genre d'outils. Je ne recours déjà pas, mais absolument pas du tout au debugger, aussi je ne vois pas pourquoi j'aurais à m'embarasser avec tous ces outils.

Si tu remontes tout en haut de la page, tu verras qu'il y a aussi des tutos sur pas mal de sujets autour de C#, incluant un cours complet sur C# : Cours complet pour apprendre C#

C'est bon, j'ai déjà tout lu de manière transversale.

A noter, il n'y a pas que MVVM, il existe aussi MVP ou encore Prism, voire meme MVVM Light....

Je vais déjà commencer par MVVM en particulier, puis je verrais le reste quand j'aurais le temps et la volonté. Parce que s'il faut se taper toute la panoplie des 23 patterns de conception avant de bouger le petit doigt, cela risque de prends un temps certain. Et j'ai malheureusement d'autres choses à faire.

Voici un tuto MVVM en Francais : Comment tirer efficacement parti des avantages de WPF tout en gardant une application maintenable et testable ?

Merci beaucoup pour ce lien

Et une référence de livre, est-ce possible ?
Merci

PS Tu devrais changer de clavier et passer à de l'AZERTY, c'est beaucoup mieux pour la lecture (;
.

[DotNetMatt]

Absolument pas, les collections non typées existaient dès l'origine.

Tu auras probablement compris que je parlais des collections typees. Travailler avec des collections non typees est une galere que le DataSet permettait de contourner.

La classe Dataview prend en compte l'interface IBindingList me trompe-je ?

C'est implemente par la classe DataView, mais IBindingList reste non typee donc tres peu pratique. La classe generique BindingList<T> est sortie avec le .NET Framework 2.0, donc elle n'existait pas aux debuts de .NET.

On peut très bien faire du "brouillon" (je met les guillemets) en MVVM tout pareil.

Bien sur, mais ton architecture sera plus propre et tu pourras repartir tes problemes sur plusieurs couches. Si quelqu'un passe derriere toi sur une application WPF, il y a aussi de fortes chances pour qu'il s'attende a utiliser MVVM. Apres je le redis, selon ton contexte MVVM peut entrainer une surcharge de travail qui ne fait pas reellement de sens. Toi seul peut juger s'il faut l'utiliser ou non.

Comme je l'indique plus haut, je ne suis absolument pas d'accord avec ton affirmation concernant les classes Dataxxx.

Libre a toi d'avoir ton opinion, ca reste un debat au sein de la communaute .NET.

Et une référence de livre, est-ce possible ?

J'en vois deux en Francais, mais il y en a peut-etre d'autres :
- Maîtrisez vos développements .NET (WPF, Silverlight, Windows Phone...)
- Développez des applications structurées (MVVM, XAML...) (Nouvelle édition)

PS Tu devrais changer de clavier et passer à de l'AZERTY, c'est beaucoup mieux pour la lecture (;
.

Je me doute mais malheureusement c'est complique car je vis et travaille aux US, et avant ca j'etais en Allemagne et a Londres donc ca fait un moment que j'ai laisse tomber l'AZERTY

[Pol63]

Lu en diagonale, mais je confirme que dataset et autres sont orientés débutant, qu'ils sont moins performants que d'autres trucs, et qu'ils n'ont à mon sens rien à faire dans une appli wpf

Un contrôleur de code source meme privé c'est un peu la base pour travailler (moi je suis plus visualstudio.com, gratuit aussi)
Et ne pas utiliser un debugger je ne comprends pas non plus...

[star]

Merci beaucoup DotNetMatt pour tes conseils avisés. Ils confortent ma démarche du développement en WPF avec l'adoption du pattern MVVM. Que penses-tu des cours proposés sur le site Pluralsight ? serait-ce un bon moyen d'acquisition des connaissances ? De plus, ils donnent accès aux codes sources des exemples utilisés.
Merci aussi pour les références de livres. Lequel me conseilles-tu de lire en premier ?
Le coup du clavier, j'avais bien compris. Moi-même suis hors métropole mais toujours dans un contexte AZERTY (:

Merci à toi aussi Pol63 pour ta contribution.

je confirme que dataset et autres sont orientés débutant

Peux-tu développer ?

qu'ils sont moins performants que d'autres trucs

Idem

qu'ils n'ont à mon sens rien à faire dans une appli wpf

Pourquoi ?

.

[Pol63]

débutant car c'est simple à mettre en oeuvre, jusque là c'est pas très péjoratif certes
mais c'est trop encapsulé, on a pas accès à tout ce qui est fait derrière, et les gens se retrouvent parfois bloqués pour aller plus loin

moins performant car en utilisant un datareader (donc bien ado.net) et une collection d'objet tu gagnes facilement 20 à 30% (selon mes tests de l'époque en 2008)
déjà pour bien utiliser le datareader il faut utiliser readobjects (ou un truc dans le genre) qui lit toute la ligne d'un coup dans un tableau plutot que de faire un read par colonne qui ralentit fortement

pas pour wpf car wpf c'est fait pour utiliser le pattern observer, donc des observablecollections (event collectionchanged bien pratique qui fait que l'interface se met à jour automatiquement avec les bindings) de classes (dependencyobject ou inotifypropertychanged, bien pratiques aussi car l'interface se met à jour automatiquement avec les bindings ^^)


par contre le mieux est que tu te fasses un genre de dataadapter, à savoir une classe qui remplit cet observablecollection à partir d'une requete, ca évite d'avoir toujours le même code
et encore mieux si tu arrives à gérer le reste du crud dedans
reste à voir si tu es connecté directement à la base ou si tu passes par du tcp/ip

je ne saurais conseiller entity framework qui reste quand même plus lent, surtout via WCF

le mvvm scolaire je suis pas totalement fan, quand je peux j'utilise l'instance du window/usercontrol en tant que VM ca permet de mixer avec les events pour des choses plus complexes sans vouloir écrire trop de xaml

[star]

c'est trop encapsulé, on a pas accès à tout ce qui est fait derrière

C'est aussi le cas des SGBDR, on les utilise pour ce qu'ils savent faire et on ne cherche pas forcément à reproduire le tigre caché dans le moteur. Ce qui est un peu le cas du Dataset ADO.NET conçu pour servir de BD inligne assaisonnée à la sauce Microsoft.

qui fait que l'interface se met à jour automatiquement avec les bindings

On arrive tout aussi bien à faire du binding avec comme source de liaison la classe DataView.

encore mieux si tu arrives à gérer le reste du crud dedans

+1

j'utilise l'instance du window/usercontrol en tant que VM ca permet de mixer avec les events pour des choses plus complexes sans vouloir écrire trop de xaml

Merci pour l'astus.

.