Discussion :

[sou_dj]

Bonjour,

Je suis en train de concevoir une nouvelle application n-tiers,

je viens de commencer sur çà:

• Couche Base de donnée (C#, Ado.net, SqlServer)
• Couche Métier (C#, Couche Base de données)
• Couche Communication (Web Services, Couche BDD, Couche métiers)
• Couche Utilisateur (WPF basant sur le modèle MVVM, et les Interfaces des couches en dessous)

Jusqu'à présente çà marche bien (sans inclure le temps comme contrainte), mon problème est le suivant:

s'adapter aux futures modifications (nouvel attribut à ajouter à mon interface, qui vas ce terminer par l'ajout de ce dernier dans une table dans la base de données):

• Un interface changeable (Fichiers *.xaml avec leurs *.xaml.cs) dans une application fini, par l'utilisateur final,
  
  • peut être la nécessité d'un pseudo éditeur de ressources de base implémenter avec l'application,
  • j’imagine que les interfaces des différents mouvements de mon application (Fichiers *.xaml) ou bien d'autres fichiers (fichiers xml de paramétrage, ces derniers pilote l'affichage chez l’utilisateur) Sont stockés dans la base de données!,
• Je cherche un conseille à suivre dans l’implémentation des objets qui représentent les tables de la bases de données changées lui aussi
  
  • ici j'imagine que j’implémente des classes avec des propriétés en plus (15 propriété à chaque classe susceptible d’être changé) et je ne les utilises qu'à la demande, activés quant ces derniers reçoivent des valeurs,

Cette idées je l'ai pris de l'interface de Coswin,

Presque c'est tout ce que j'ai besoin pour le moment, quelques conseil est des nouvelles idées,

Merci d'avance,

[DonQuiche]

Bonjour.

Je ne connais pas Coswin mais j'ai trouvé une vidéo sur dailymotion intitulée "Paramétrage Coswin + M.tv", est-ce que ça correspond en ordre de grandeur aux possibilités de personnalisation que tu souhaites fournir ?

Si c'est le cas, pour ma part je me bornerais à stocker la spécification de l'UI (objet du modèle spécifiant la présentation souhaitée, utilisé aussi bien pour générer l'UI que pour l'éditeur permettant de la modfier) sous format XML : si tu devais stocker directement le xaml, en déduire la spécification de l'UI serait fastidieux. Qui plus est, plutôt que de générer du XAML à partir de cet XML, je me tournerais plutôt vers une génération manuelle (via du code C# ou autres) des éléments WPF à partir de la spécification de l'UI : cela me semble plus facile à modifier et déboguer qu'un XSLT. Quant au viewmodel derrière ça, il serait construit par un assemblage de sous-éléments du viewmodel, chacun correspondant à un élément précis du formulaire final.

En termes de performances, c'est également plus efficace : le contenu textuel à analyser (XML) sera moins lourd que du XAML et donc ton code devrait y gagner. Je ne sais pas si cet avantage est pertinent cela dit

Enfin, il est possible que la plomberie à effectuer soit relativement simple : si on prend l'exemple de la vidéo, ça n'a rien d'extraordinaire à faire en WPF : une collection observable de compteurVM (viewmodels des compteurs), un template pour générer un élément visuel pour chacun d'entre eux et voilà tout. C'est typiquement le compteurVM qui se contente de renvoyer la bonne valeur en fonction de la propriété qu'ils est sensé représenter.

[sou_dj]

Bonjour,

Merci pour la réponse,

Concernant Coswin c'est un progiciel de GMAO. Pour la vidéo elle correspond à un autre sujet, mais bon ce n'est pas ma question pour qu'on se dévier pas de l'objective,

je vais présenter le problème d'un autre point de vue:

exemple: j'ai dans mon application un interface correspond à un mouvement stock (ex: entrée stock - d'une pièce quelconque), implémenté en basant sur la méthode MVVM-WPF (un chois),

dans mon cas je cherche à donner à l'utilisateur final, à partir de l'application elle même (avec l'ajout d'un module qui s'occupe de ça), la possibilité de:

• modifier l'emplacement d'un bouton (du gauche vers le milieu ou un peut proche), aussi pour un champ de saisie (ex: Libellé pièce)
• ajouter un nouveau champs de saisie, qui n’existai pas auparavant, (ex: poids de la pièce)

dans le deuxième cas moi je pense à:

1. prévoir l'ajoute dans quelques tables (en cibles) des attribut non utilisés pour la première fois (en réserve),
2. d'ajouter à la suites ces attributs dans les objets correspondants,
3. de stocker les coordonnées de mes éléments du mouvement entrée stock dans la base de données, et je les réstore à chaque démarrage,

ma question est la suivante:

• est ce que cette idée est correcte, sinon, y a i d'autres mieux,
• la mise en œuvre de la troisième étape,

j'espère que j'ai mieux présenter le sujet,

Merci d'avance,

[DonQuiche]

Bonsoir.

Globalement, oui, ça tient debout. Le fait de ne stocker que les attributs ayant une valeur autre que celle par défaut est le choix le plus logique. S'il y a lieu de s'inquiéter pour les performances, j'étudierais tout de même la possibilité d'une table à colonnes variables afin de comparer les deux solutions. Niveau codage le seconde serait sans doute un poil plus simple aussi mais bon... Ce n'est pas sur ce sujet que je suis le plus à l'aise.

Pour l'UI et les données à stocker dans la DB :
* J'insiste sur la nécessité d'utiliser un format canonique ne contenant que le minimum d'informations nécessaires.
* Si tu veux vraiment laisser latitude à tes utilisateurs de déplacer au pixel près chaque élément, tu devras stocker des coordonnées ou des offsets. Cela dit, est-ce vraiment ce que l'utilisateur désire et que se passera t-il quand des utilisateurs accéderont à cette UI depuis des écrans avec des résolutions différentes ? Pour ma part, j'aurais plutôt envisagé un placement automatique des éléments, l'utilisateur pouvant toutefois choisir si ces éléments sont alignés à gauche, à droite, en bas de la page, etc. Une zone de champs de saisie, par exemple, se divise typiquement en lignes. Dans un cas tu t'orientes vers un designer type celui de Windows forms où ton utilisateur devra tout arranger à la mano (et tu devras lui fournir les fonctionnalités pour bien aligner, manipuler une sélection multiple, etc), dans l'autre tu te concentres sur l'ajout ou le retrait rapide de modules sur la page, avec plus d'effort consacré vers l'UI d'éventuels modules complexes (agrégats, etc).