Discussion :

[-={-_-}=-]

Bonjour à tous,

j'ai lu quelques posts sur ce forum concernant la conception mais je n'ai pas trouvé toutes mes reponses. C'est pour ca que j'ai créée cette discussion.

Je souhaitais tout d'abord vous dire que c'est ma premiere vrai appli, donc il est possible que je pose des questions idiotes.

Bon passons au descriptif de mon projet:

J'aimerais créée une appli avec des forms (pas d'asp).

l'objectif de l'appli est d'aller sur internet chercher des données et les importer et de les retraiter.
l'application devra ensuite afficher les différents retraitements effectués.

A chaque lancement de l'appli, les données devront être réactualisées pour injecter dans la DB les données manquantes.

Voila en gros le fonctionnement.

Petite contrainte en plus, une fois le dev fini, j'aimerais créer un fichier install qui me permettrai d'installer cette application sur nimporte quel poste de travail et pourquoi pas une dll pour que je puisse taper sur cette appli via excel.

Bon allons pour les questions :
C'est pas trop dur pour une première appli? (J'en ai marre de faire juste quelques prog à l'arrache)
Avez-vous des tutoriels à me conseiller?
Quel systeme je dois utiliser pour les données (mysql, Ms sql server)?
Dois-je mettre ma DB sur un serveur web? si oui, comment je fais?
Par quoi je dois commencer?
Comment m'organiser pour faire quelque chose de clean?

Je suis sur que j'ai d'autres questions mais la c'est tout ce qui me vient.

En tout cas merci de m'avoir lu et merci à tous pour vos réponses.

[tomlev]

C'est pas trop dur pour une première appli?

Ca ne me semble raisonnable... en tous cas c'est un bon projet d'apprentissage, parce que ça couvre différents aspects (communication web, base de données, Windows Forms). Par contre la partie sur la DLL utilisable à partir d'Excel, je suis un peu sceptique... c'est pas évident du tout

Avez-vous des tutoriels à me conseiller?

http://dotnet.developpez.com/cours/

En particulier ceux sur ADO.NET, si tu n'as jamais manipulé de bases de données. En voilà 3 particulièrement intéressants :
http://dotnet.developpez.com/articles/ado1/
http://dotnet.developpez.com/articles/ado2/
http://johannblais.developpez.com/tu...acces-donnees/
Les 2 premiers concernent SQL Server, mais le principe est exactement le même pour les autres bases de données, il y a très peu d'adaptations à faire. D'ailleurs le 3e tuto explique (entre autres) comment écrire un code indépendant de la base de données.

Quel systeme je dois utiliser pour les données (mysql, Ms sql server)?

Ce que tu veux
L'avantage de SQL Server est qu'il est livré avec Visual Studio, et s'intègre très bien dans les assistants et designers.
Par contre, si tu dois déployer l'appli sur plusieurs postes, l'utilisation d'une base de données de type serveur complique un peu les choses... Il y a de très bonnes bases de données de type fichier, qui ne nécessitent pas de serveur, notamment :
- SQL Server Compact Edition (fourni aussi avec Visual Studio)
- SQLite (mon préféré pour les applis qui ont des besoins "légers" en terme de base de données). Il y a un bon provider ADO.NET ici

Dois-je mettre ma DB sur un serveur web? si oui, comment je fais?

Ben ça dépend de ce que tu veux faire avec... si c'est une base de données commune à tous les utilisateurs, il faut effectivement qu'elle soit accessible sur le net. Mais dans ce cas il faudra mettre une couche de communication supplémentaire entre le serveur et l'application : il ne faut pas laisser les clients accéder directement à la base de données, à moins de très bien sécuriser l'accès (VPN par exemple). D'ailleurs si tu utilises un hébergement gratuit, la base de données ne sera pas accessible directement. Bref, là ça complique tout de suite pas mal les choses...
Si tu veux juste que chaque utilisateur ait sa propre copie de la base, inutile de la mettre sur le web...

Par quoi je dois commencer?

Il n'y a pas vraiment de règle... moi je commence souvent par une ébauche d'interface graphique, ça permet de commencer tout de suite à voir ce que ça va donner. Ensuite tu ajoutes progressivement les fonctionnalités, en enrichissant l'interface graphique au fur et à mesure des besoins.

Comment m'organiser pour faire quelque chose de clean?

Là dessus il y aurait de quoi écrire un roman, donc je ne vais pas trop m'étendre... Je te donnerai donc seulement quelques conseils :

• Essaie de bien séparer le code des traitements de celui de l'interface graphique (par exemple, n'écris pas un énorme traitement dans le code de l'évènement Click d'un bouton... crée une méthode à part, voire une nouvelle classe). Cela permettra de réutiliser facilement le code ailleurs. En fait, pour faire les choses vraiment proprement, l'idéal est de créer une DLL (projet de type "bibliothèque de classes") qui fait tous les traitements, indépendamment de l'interface. Et dans le code de l'application, tu utilises les classes définies dans le DLL
• Ca peut sembler un détail, mais ne laisse pas les noms par défaut des contrôles (button1, label42, listBox15...). Au début ça reste à peu près gérable, mais dès que ton appli va grossir un peu tu vas t'y perdre. Donne des noms explicites qui décrivent à quoi correspond le contrôle
• Mets des commentaires dès qu'un bout de code devient un peu complexe (i.e., quand on ne comprend pas immédiatement à quoi il sert en le lisant). Au début ça ne te servira pas à grand chose, mais si tu reprends le code quelques mois plus tard tu seras content de l'avoir fait...

Après, tu peux te renseigner sur le pattern MVC, et sur les design patterns en général...

[-={-_-}=-]

Dois-je mettre ma DB sur un serveur web? si oui, comment je fais?

Il n'y a pas vraiment de règle... moi je commence souvent par une ébauche d'interface graphique

Ok, je l'ai fait à l'envers. J'ai commencer à réfléchir sur la DB (nb de tables, colonnes,...) je pensais ensuite faire mes classes qui permettraient de la manipuler pour finalement faire le plus fun a la fin la form.

Dois-je mettre ma DB sur un serveur web? si oui, comment je fais

Si tu veux juste que chaque utilisateur ait sa propre copie de la base, inutile de la mettre sur le web...

Je pense que c'est exactement ca que je vais faire car les utilisateurs peuvent étendre à volonté la DB en terme de table et perso je préfère tout stocker en local sur le poste de l'utilisateur.

Quel systeme je dois utiliser pour les données (mysql, Ms sql server)?

- SQL Server Compact Edition (fourni aussi avec Visual Studio)

Je vais faire ca je pense. Une base fichier me semble adaptée.

Comment m'organiser pour faire quelque chose de clean?

Essaie de bien séparer le code des traitements de celui de l'interface graphique (par exemple, n'écris pas un énorme traitement dans le code de l'évènement Click d'un bouton... crée une méthode à part, voire une nouvelle classe). Cela permettra de réutiliser facilement le code ailleurs. En fait, pour faire les choses vraiment proprement, l'idéal est de créer une DLL (projet de type "bibliothèque de classes") qui fait tous les traitements, indépendamment de l'interface. Et dans le code de l'application, tu utilises les classes définies dans le DLL

C'est exactement ce que je pensais faire. Une couche DB, une couche classe et une chouche form avec la la couche form qui tape dans la couche classe et la couche classe qui tape vers la couche DB.
Quand tu parles de dll, je dois effectivement en faire une ou simplement coder et considérer que ma couche classe en est une?

Par contre la partie sur la DLL utilisable à partir d'Excel, je suis un peu sceptique... c'est pas évident du tout

Moi je pensais que c'etait pas trop cho. Si je fais une dll pour que ma form tape dedans ben c'est pareil non? La ce sera l'interface excel ou vba qui intègre ma DLL et grace à cette dernière je requete ma DB. C'est pas ca? J'ai oublié un truc?

Ca peut sembler un détail, mais ne laisse pas les noms par défaut des contrôles (button1, label42, listBox15...). Au début ça reste à peu près gérable, mais dès que ton appli va grossir un peu tu vas t'y perdre. Donne des noms explicites qui décrivent à quoi correspond le contrôle
Mets des commentaires dès qu'un bout de code devient un peu complexe (i.e., quand on ne comprend pas immédiatement à quoi il sert en le lisant). Au début ça ne te servira pas à grand chose, mais si tu reprends le code quelques mois plus tard tu seras content de l'avoir fait...

Pas de soucis avec tout ca, mon métier est de passer derrière les autres developpeurs pour faire évoluer leurs trucs ou comprendre comment les outils fonctionnent. Tinquiete donc pas je sais quelle galère ca peut être d'être de ne pas être rigoureux dans les comentaires et dans les noms des classes, des attributs, des méthodes,...


Merci pour ton poste tomlev et pour ton aide

[tomlev]

Ok, je l'ai fait à l'envers. J'ai commencer à réfléchir sur la DB (nb de tables, colonnes,...) je pensais ensuite faire mes classes qui permettraient de la manipuler pour finalement faire le plus fun a la fin la form.

Tu ne l'as pas "fait à l'envers"... comme je l'ai dit, il n'y a pas vraiment de règle, et commencer par la base de données est une approche tout aussi valable, voire plus selon les cas...

C'est exactement ce que je pensais faire. Une couche DB, une couche classe et une chouche form avec la la couche form qui tape dans la couche classe et la couche classe qui tape vers la couche DB.

Euh... une "couche classe", ça n'a pas vraiment de sens, vu que tout est fait avec des classes en C#... Je pense que tu veux parler de ce qu'on appelle habituellement la "couche métier" (ou BLL pour Business Logic Layer).
Il y a un tuto sur le développement en couches qui pourrait t'intéresser
http://morpheus.developpez.com/architecture/

Quand tu parles de dll, je dois effectivement en faire une ou simplement coder et considérer que ma couche classe en est une?

Je suis pas sûr de bien comprendre ce que tu veux dire...
Il faut que tu ajoutes à ta solution un nouveau projet de type "bibliothèque de classes", dans lequel tu vas mettre le code métier. Quand ce projet sera compilé, ça produira une DLL et non un exe. Dans l'application, il faudra que tu ajoutes une référence au projet DLL pour pouvoir l'utiliser (clic droit sur le projet, ajouter une référence, onglet projets)

Moi je pensais que c'etait pas trop cho. Si je fais une dll pour que ma form tape dedans ben c'est pareil non? La ce sera l'interface excel ou vba qui intègre ma DLL et grace à cette dernière je requete ma DB. C'est pas ca? J'ai oublié un truc?

Excel ne connait pas ta DLL, et ne sait pas l'utiliser... D'autre part, VBA, ce n'est pas du .NET. Si tu veux utiliser ta DLL à partir de VBA, il faut gérer l'interopérabilité COM, et c'est un peu coton...

Pas de soucis avec tout ca, mon métier est de passer derrière les autres developpeurs pour faire évoluer leurs trucs ou comprendre comment les outils fonctionnent. Tinquiete donc pas je sais quelle galère ca peut être d'être de ne pas être rigoureux dans les comentaires et dans les noms des classes, des attributs, des méthodes,...

Ah OK, j'avais cru comprendre que tu débutais, donc je voulais te faire éviter des erreurs de débutant

[-={-_-}=-]

Euh... une "couche classe", ça n'a pas vraiment de sens, vu que tout est fait avec des classes en C#... Je pense que tu veux parler de ce qu'on appelle habituellement la "couche métier" (ou BLL pour Business Logic Layer).

Ouais je suis débutant sur C# (je fais du vb) et je n'ai pas fait de formations en informatique ou très peu. Je ne suis donc pas rigoureux dans les mots que j'utilises. Désolé pour la confusion, mais tu as compris ce que je voulais dire.

Il faut que tu ajoutes à ta solution un nouveau projet de type "bibliothèque de classes", dans lequel tu vas mettre le code métier. Quand ce projet sera compilé, ça produira une DLL et non un exe. Dans l'application, il faudra que tu ajoutes une référence au projet DLL pour pouvoir l'utiliser (clic droit sur le projet, ajouter une référence, onglet projets)

Je débute en .NET ainsi que sous visual studio. Je n'ai jamais fait de projet c# donc tout ce que tu dis la je ne le savais pas.
Ce post a été créé lorsque mon projet était a peu près clair sur le papier. Mais ouais je n'ai jamais fait un truc aussi vaste.
Encore désolé pout toutes ces bétises d'ignorants.

Excel ne connait pas ta DLL, et ne sait pas l'utiliser... D'autre part, VBA, ce n'est pas du .NET. Si tu veux utiliser ta DLL à partir de VBA, il faut gérer l'interopérabilité COM, et c'est un peu coton...

Je savais bien que j'avais oublier une étape

Ah OK, j'avais cru comprendre que tu débutais, donc je voulais te faire éviter des erreurs de débutant

Pas de souci.Je me considère comme débutant car je n'ai jamais participer à la création d'un projet informatique, je n'ai été qu'au bout de la chaine en mode debug