Discussion :

[Jeterh]

Bonjour à tous,

A 49 balais, et me remettant à développer pour mon plaisir après 20 ans 'd'autres choses', je me suis heurté au Vieillot du Windows Forms en VB. J'ai rangé mon projet de gestion de planning 1.0, et j'ai basculé sur WPF.

Je me suis dis bêtement que WPF était moderne, et qu'un Datagrid allait juste être une question de Drag and Drop et Hop (copyright rime déposée^^).

Hélas, que Nenni...

Donc deux questions métaphysique :
- Suis-je seul dans mon coin à peiner à quoi mettre dans le XAML et le Code Behind?, pour simplement gérer Un enregistrement Maître en Textbox et une table détail en datagrid???
- Ce choix WPF + VB est-il définitivement Has-been, au regard du faible nombre de tutoriels disponibles dans la langue de Molière??? Dois-je passer le Cap du C#???

Par avance merci pour vous pistes et/ou conseils, pour le boulet/Noob que je suis au final!

[Pol63]

je pense que tu n'es pas seul à lutter sur wpf ^^

wpf n'ayant rien à voir avec windows forms, ca demande un temps d'adaptation qui peut etre long
en c# il y a plus de tutos, mais ce n'est pas une obligation de passer en c#, on peut faire la même chose en vb.net
déjà il y a convertisseurs c#/vb.net, et avec un peu de temps on arrive à lire le c#

je ne pense pas que wpf soit fait pour utiliser des datasets
si tu veux développer rapidement, tu peux tenter entity framework (pas dispo sur la version express je crois)
sinon le but est d'avoir des observable collection et des classes

il y a plusieurs concepts à comprendre avant de coder, les datatemplates et le binding, puis éventuellement le mvvm
pour le mvvm taper galasoft dans google, c'est une dll pratique pour faire du mvvm, et le gars a fait quelques vidéos qui explique plutot bien
sur les datatemplates il y a des bons webcast aussi, sur les techdays d'il y a quelques année je crois

[Jeterh]

Merci Pol, parfois on doute sur nos choix. Google est notre ami, mais parfois, on le trouve rengaine : à toujours nous proposer les même soluces à côté de la plaque. Je vais explorer toutes tes pistes, notamment le mvvm que j'ai croisé au cours de mes recherches sans comprendre les initiales.

Encore Merci,
Jet

[Pol63]

Model : les classes métiers (correspondantes aux tables en général)
View : la window, le xaml, les datatemplaces
View Model : classe intermédiaire qui sert à faire le lien entre les 2, le view a une instance du viewmodel en datacontext, et des propriétés dont certaines permettent de pas galérer avec le rendu, genre visibility qui est une enum en xaml et un booléen en data, donc faire une propriété as visibility dans le viewmodel qui return selon le view (oui le viewmodel contient la ou les instances de model qui sont utilisées dans l'interface)
on peut aussi faire un converter pour les booléen to visibility

il faut aussi utiliser la classe relaycommand qui se trouve sur le net, ca permet de dire en xaml qu'un bouton appelle une sub sur une instance (en gros), pratique dans un datatemplate

donc il n'y a normalement pas ou peu de code dans le window du coup

enfin il faut prendr le temps de tester plusieurs choses avant de prendre des décisions sur l'architecture ... il n'y a pas que du bon dans wpf ...

sinon tu peux peut etre aller demander des avis sur la partie wpf du forum

[Jeterh]

A ce stade, j'ai stoppé depuis plus de 2 semaines tout avancement...
J'ai du créer 20 projets essais (lol).
- Du WPF, Du Silverlight, en ce moment du Lightswitch... J'ai testé les versions démos des Addons (ComponentOne, Telerik), ..., j'ai donc re testé même du Winform.

Ma conclusion : j'ai des grosses limites
Autant si je gère tout à base de textbox, et même des sortes de Datagrid maisons avec ces textbox assemblées, avec du bon vieux SQL à la mano derrière sur une base locale, je m'en sors. Dès que je veux rentrer dans les nimbes du Databinding, voire commencer à penser à des accès concurrents sur ma BDD et donc la sortir du projet, je me casse les dents menus. Pas assez Bilingue pour bien piger les sources d'aides du Net, pas assez calé en concepts modernes.

L'idée de base du MVVM me plaît beaucoup, mais ça demande des bases en XAML et binding que j'ai pas.

Encore merci Pol, tes mots restent un peu touffus, mais chargés de soutien!

[Nathanael Marchand]

TADA! http://nathanaelmarchand.developpez....t-silverlight/

[Immobilis]

Salut

L'idée de base du MVVM me plaît beaucoup, mais ça demande des bases en XAML et binding que j'ai pas.

Pour autant que je sache, pas trop de rapport en fait. Comme dit plus haut, si la vue et le model ne devrait pas poser de problème de compréhension:

View Model : classe intermédiaire qui sert à faire le lien entre les 2, le view a une instance du viewmodel en datacontext

Le ViewModel est un manager qui met à la disposition de la vue des propriétés et des méthodes. Le ViewModel est non spécialisé pour une interface en particulier. C'est l'équivalent d'un manager dans une business logic. Si je comprend bien le pattern, la différence fondamentale réside dans les commandes. Les évènements traditionnels disparaissent.