Conception d'un panier avec des "windows form" sur Visual Studio

Fermé
artanlatifi Messages postés 4 Date d'inscription vendredi 29 mai 2015 Statut Membre Dernière intervention 20 octobre 2015 - 29 mai 2015 à 17:05
ucfoutu Messages postés 18038 Date d'inscription lundi 7 décembre 2009 Statut Modérateur Dernière intervention 11 avril 2018 - 29 mai 2015 à 23:32
Bonjour/Bonsoir,

Je suis débutant en vb.net et cherche à developpé une application concernant une entreprise fictive de smartphone avec mes collègues.

Nous avons donc développé plusieurs fenêtre de navigation. Une fenêtre offre la possibilité de se connecter à l'application (qui possède une base de données), une autre montre les produits que nous vendons. Nous voudrions instaurer un panier qui puisse cumulé les prix liés aux produits que nous proposons et sur lesquelles le clients cliques.

Chose à savoir:

1. les produits sont représenté par des images (et seulement par une image, il n'y a pas encore de code derrière, donc les produits sont présents dans la base de données)

2. pouvoir enregistré les panier à chaque compte qui se connecte (exemple: si la personne remplit son panier et que d'un coup va voir son profil, de pouvoir gardé le panier, pas qu'il aie à le rechargé de nouveau tant que le compte ne se déconnecte pas ou alors le vide de lui même)

Je ne sais pas si j'ai été clair sur ma question, si vous avez besoin de plus amples informations n'hésitez pas. Je ne sais même pas si ce que je demande est actuellement possible à faire sur Visual Studio.

Je vous remercie d'avance de l'attention que vous porterez à ma requête.

Amicalement.

PS: j'ai entendu parler d'un "table adapter" concernant le point 2 des choses à savoir, peut-être que ça pourra en inspirer un de vous. :o)

5 réponses

ucfoutu Messages postés 18038 Date d'inscription lundi 7 décembre 2009 Statut Modérateur Dernière intervention 11 avril 2018 211
Modifié par ucfoutu le 29/05/2015 à 17:17
Bonjour,
Comme tu le sais (relis sinon les règles de ce forum), on ne traite pas ici une application, mais on aide à résoudre une difficulté spécifique, parfaitement isolée et accompagnée du code tenté pour la résoudre, rencontrée dans le cours du
développement
de ton application.
Il se trouve que tes questions relèvent beaucoup plus de la
conception
que du développement.

________________________
Nul ne saurait valablement coder ce qu'il ne saurait exposer clairement.
0
artanlatifi Messages postés 4 Date d'inscription vendredi 29 mai 2015 Statut Membre Dernière intervention 20 octobre 2015
29 mai 2015 à 17:59
Je ne pense pas m'être tourné du côté de la conception de mon application, car mon application est terminée au niveau graphique.

Je demande simplement des pistes qui pourraient m'être utiles, éventuellement des petits conseils en terme de codes, pas qu'on me créée mon application à ma place.

Si cela n'a pas été claire, je m'en excuse.
0
ucfoutu Messages postés 18038 Date d'inscription lundi 7 décembre 2009 Statut Modérateur Dernière intervention 11 avril 2018 211
Modifié par ucfoutu le 29/05/2015 à 21:14
Bien.
1) Quelle est alors (accompagnée du code tenté pour la résoudre) la difficulté technique, spécifique et parfaitement ISOLEE que tu rencontres dans le cours de ton développement ?
2) le "graphisme" n'est que l'interface. On s'en préoccupe peu ou pas du tout ici et il n'est pas du développement.
Je suis vraiment désolé d'avoir à te rappeler ces évidences.

________________________
Nul ne saurait valablement coder ce qu'il ne saurait exposer clairement.
0
ucfoutu Messages postés 18038 Date d'inscription lundi 7 décembre 2009 Statut Modérateur Dernière intervention 11 avril 2018 211
Modifié par ucfoutu le 29/05/2015 à 22:19
Pour être plus sérieux, voici les étapes à franchir avant même de commencer à développer :
1) définition précise des besoins (ceux déjà "cernés", mais souvent également ceux à prévoir) ===>> cela s'appelle la rédaction d'un cahier des charges. Un cahier des charges ne saurait être résumé en quelques phrases. Sa rédaction est en général le fruit de plusieurs études, consultations et discussions. Plusieurs corps de métier sont souvent concernés par ces consultations et discussions (du fait d'implications diverses, dont comptables, fiscales, légales, etc ...) ; leurs différents avis sont nécessaires pour "cerner" d'emblée tous les besoins et éviter une évolution tardive vers une "usine à gaz" résultant de l'ajout de "verrues" diverses.
2) Etablissement de la "liste des propriétés " nécessaires (à partir, donc, du cahier des charges)
3) Etablissement d'un MCD (modèle conceptuel des données). Ce n'est pas là un travail à bâcler. C'est de ce modèle que va dépendre l'agilité de tout le reste
4) Etablissement d'un MLD (modèle logique des données)

Voilà
5) Ce n'est qu'ensuite qu'intervient, dans le langage informatique de son choix, le développement à proprement parler.

Commence par tout cela et ouvre une nouvelle discussion lorsque, dans le cours de ton développement (étape 5), tu rencontreras une difficulté spécifique et parfaitement isolée.
Je ferme maintenant la présente discussion.

________________________
Nul ne saurait valablement coder ce qu'il ne saurait exposer clairement.
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
ucfoutu Messages postés 18038 Date d'inscription lundi 7 décembre 2009 Statut Modérateur Dernière intervention 11 avril 2018 211
Modifié par ucfoutu le 29/05/2015 à 23:50
Je rouvre juste pour te dire ceci (et tu vas voir à quel point il ne s'agit que de conception) ===>>
- Une commande n'en est une que lorsqu'elle est confirmée
- tant qu'elle ne l'est pas, il ne s'agit que d'un projet de commande
- un projet de commande peut se mettre dans un simple fichier texte structuré, dont la structure de chaque élément est à définir comme tu l'entends (date, prix, référence, etc ...). Fichier texte nommé du nom du client et placé dans un répertoire "commandes" commun à tous les clients, à ce stade. Le hic, à ce niveau, est ta phrase assez ambigüe :
les produits sont représenté par des images (et seulement par une image, il n'y a pas encore de code derrière, donc les produits sont présents dans la base de données)

Il faudra bien, comme référence, un idart de l'article commandé et non une "image" ! (çà, c'est la/les table(s) issue(s) de la mise en oeuvre de ton MCD, justement)
- de cette manière
===>>> lecture et exploitation de ce fichier chaque fois que l'utilisateur le désirera. Tu peux même laisser "vivant" chaque fichier de l'espèce pendant une durée de ton choix, de sorte à ce que le client puisse même y retourner, y compris entre sessions, pendant toute cette durée
===>>> lecture et exploitation de ce fichier de projet de commande à la confirmation éventuelle par le client ===>> transfert de ces données dans la base de données réelle des clients (elle doit exister) et destruction du fichier de projet de commande
===>>> listing périodique et destruction des fichiers présents dans le répertoire "commandes" et dont la date/heure est antérieure à la durée décidée de "vie" du projet de commande.
Je referme, maintenant. Et regrette vraiment d'avoir eu à suggérer ce qui n'est que de la conception/imagination (parmi d'autres expressions personnelles possibles de créativité).
Je te promets qu'aucun des pêcheurs que je connais ne pêche la louvine exactement comme les autres. Chacun à ses trucs, ses habitudes, ses manies, etc ... Tous attrapent pourtant des louvines ! Sauf, bien entendu, ceux qui n'ont jamais réellement observé/compris suffisamment ce poisson pour "inventer" le "truc" personnel, apporter la "touche" personnelle, s'adapter à telle ou telle autre situation, fond, etc ... (tu comprends ?)

________________________
Nul ne saurait valablement coder ce qu'il ne saurait exposer clairement.
0
Rejoignez-nous