Bonjour,
(Mon background : j'ai fait pas mal de Qt/C++, et j'ai jeté un oeil à WPF 2j que j'ai trouvé très bien).
Je participe à des projets pros. On commence à commander du WPF auprès de prestataires, pour faire des applis desktop à l'ancienne, sur des petits projets, pour se faire la main.
Je fournis un modèle de classe en C# déjà sérialisable et simple (agglomérats de string,float,int,bool, pas de méthodes). Les requêtes sont peu nombreuses et très simples (afficher tous les objets d'un type, pouvoir changer des valeurs, ajouter/supprimer des objets ...).
Dans les réponses que je reçois, les prestas se sentent obligés de mettre des installations de bases SQL (entity framework etc), alors qu'une contrainte technique est que je voudrais que cela soit ma classe qui soit utilisée comme modèle.
La présence de SQL me paraît absolument pas nécessaire (coût de maintenances..), et même pas bien. J'ai discuté avec les équipes techniques des prestataires, et ils me disent que c'est plus rapide (performances) d'avoir du SQL que des binding direct et plus rapide à mettre en oeuvre. J'ai beaucoup de mal à y croire (en fait j'y crois pas). Les coûts annoncés sont supérieurs à ce qu'on aurait avec du Qt traditionnel en durée, sans toutes les technos de binding, xaml... (aucun doute là dessus). Donc cela me paraît ne pas être un argument.
J'aimerai savoir jusqu'à quel point j'ai tord. Donc : est-ce que SQL c'est vraiment "une meilleure option" en WPF, ou est-ce que des bindings sans SQL (quitte à avoir un MV entre les deux) sont des choses tout à fait acceptables et qui ne présentent pas d'inconvénients particuliers ?
Cordialement,
ElPedro
Partager