Discussion :

[Adel13]

Salut à tous je débute en C#.
Tout d'abord je vous explique mon cas :
J'ai pas mal de notions d'objet(Je suis en BTS INFORMATIQUE DE GESTION), et de programmation.
Seulement j'ai toujours programmé en PHP malheureusement (avec tout ce qui va avec, javascript, ajax etc..).
Programmant principalement des applications de gestions, Windows Forms me sera très utile. Et c'est là qu'est tout le problème :
J'ai lus quelque part que les formulaires et les requêtes SQL devaient être séparé. Si c'est vrai comment faire ? Creer des méthodes d'une classe ou une méthode = une requête SQL ? Ne serait-ce pas un peu trop .."lourd" ?

Merci d'avance de votre réponse

[Proteus91]

Et bien en fait je ne sais pas trop qu'elles sont les avis des autres. Mais ce que je te conseil de faire c'est peut être de regarder comment implémenter MVC dans ton application histoire de bien séparer les couches interface, contrôle des données et données.

A coté de ca, je peux te dire que par exemple j'utilise en général 1 objet pour chaque requête. Exemple : Tu as une table dans laquelle tu vas requeter (Sélectionner, Modifier ou Supprimer) et tu crée un objet qui contiendra les champs de la table que tu veux utiliser.

Si tu as besoin de plus de détails n'hésite pas a regarder des tutos il y'en a bcp sur ce site. Si tu veux envoie parle moi en détail de ce que tu veux faire a ton application et nous pourrons en parler. Peut être que je pourrai mieux t'orienter.

Bonne année.

[Adel13]

Merci de ta réponse.
Est-ce difficile d'implanter un MVC en c# ?
Sinon, j'ai un projet assez flou concernant la gestion de Mobil-Home.
Le problème c'est que je ne peux vraiment pas te dire de quoi il est constitué vue que je suis vraiment en phase d'apprentissage et de test de c#.
Pourrait-tu m'expliqué un peu plus précisément ton conseil ?
Merci d'avance je vais au lit, en espérant que demain matin je vois un jolie post

[GuruuMeditation]

Le MVC2 est assez simple. Plus que l'ASP.NET traditionel je trouve. J'avais un peu laissé tombé l'ASP.NET car ca devenait lour (viewstate de la mort, mix presentation et code, les etats de la page,etc...) et le MVC2 résoud tout ça de manière assez élégante. De plus, MVC2 ne lutte pas contre la nature de web, au contraire de l'ASP.NET (ou ils tentent de faire du winform avec du web).

La seule chose c'est que pour un site très simple, tu auras plus vite un résultat avec ASP.NET qu'avec ASP.NET MVC2. Mais avec MVC2 tu auras plus facile pour les unit test, et c'est une base plus saine. Sur un site web plus conséquent, je pense que le MVC2 prendra, in fine, moins de temps que l'ASP.NET

[Proteus91]

En fait je pense que la première chose que tu dois faire c'est réfléchir a ce que tu veux faire de ton application. En effet en fonction des objectifs de ton application il faudra choisir si ce sera un client Léger ou un client lourd, si tu souhaites que les utilisateurs bénéficie d'une interface riche ou pas... Ces questions sont des questions auxquels tu dois répondre avant de te lancer.

Concernant MVC, l'implémenter n'est pas très compliqué, j'ai déjà diriger quelqu'un vers cet Exemple qui l'a trouvé plutôt clair.

N'hésite pas a demander de l'aide si certaines chose ne te paraissent pas clair.

[Nathanael Marchand]

Le MVC2 est assez simple. Plus que l'ASP.NET traditionel je trouve. J'avais un peu laissé tombé l'ASP.NET car ca devenait lour (viewstate de la mort, mix presentation et code, les etats de la page,etc...) et le MVC2 résoud tout ça de manière assez élégante. De plus, MVC2 ne lutte pas contre la nature de web, au contraire de l'ASP.NET (ou ils tentent de faire du winform avec du web).

La seule chose c'est que pour un site très simple, tu auras plus vite un résultat avec ASP.NET qu'avec ASP.NET MVC2. Mais avec MVC2 tu auras plus facile pour les unit test, et c'est une base plus saine. Sur un site web plus conséquent, je pense que le MVC2 prendra, in fine, moins de temps que l'ASP.NET

Je crois que le Monsieur il parlait du MVC dans une appli Winform pas de ASP.NET MVC

[olibara]

J'ai lus quelque part que les formulaires et les requêtes SQL devaient être séparé. Si c'est vrai comment faire ? Creer des méthodes d'une classe ou une méthode = une requête SQL ? Ne serait-ce pas un peu trop .."lourd" ?

Pas du tout au contraire ton code sera plus lisible et facilement réutilisable

Pour ma part j'ai
- une classe Wrapper qui effectue tous les dialogue ADO
- Une classe par table (object) de la DB qui gere les insertions, update, etc..
- Des classe metiers qui gerent les les requetes specifiques

Ce qui fait que ta vue n'a qu'a gerer le binding comme tu l'entends mais elle ne contiendra aucune commande SQL ni manipulation "metier"
Apres a toi de gerer le binding avec tes vues comme tu l'entends

[GuruuMeditation]

Je crois que le Monsieur il parlait du MVC dans une appli Winform pas de ASP.NET MVC

oups. Moi qui etait tout content de donner mon avis.

Alors MVC en Winform, pourquoi ne pas passer en MVVM WPF?

[B.AF]

Salut à tous je débute en C#.
Tout d'abord je vous explique mon cas :
J'ai pas mal de notions d'objet(Je suis en BTS INFORMATIQUE DE GESTION), et de programmation.
Seulement j'ai toujours programmé en PHP malheureusement (avec tout ce qui va avec, javascript, ajax etc..).
Programmant principalement des applications de gestions, Windows Forms me sera très utile. Et c'est là qu'est tout le problème :
J'ai lus quelque part que les formulaires et les requêtes SQL devaient être séparé. Si c'est vrai comment faire ? Creer des méthodes d'une classe ou une méthode = une requête SQL ? Ne serait-ce pas un peu trop .."lourd" ?

Merci d'avance de votre réponse

En fait, c'est une pratique de programmation dont tu entends parler.
Le principe c'est que ce soit maintenable au maximum et surtout clair.

Dans le principe, si tu veux faire du Winforms connecté à une base SQL; le modéle par défaut est dit "modéle vue".

Après, ce n'est pas une obligation : il vaut mieux une forme bien développée qu'un découpage avec de la tuyauterie tellement lourde que tout devient illisible.

Si tu entreprends de faire des écrans nombreux et lourds, typiquement, la réutilisation des composants et des requêtes te seront utiles.
Si tu entreprends de faire une application avec 3 écrans, ca ne sera pas obligatoirement utile.

En revanche, apprendre à structure du code et à utiliser la bonne architecture pour faire la bon travail, c'est toujours intéressant.

[olibara]

Pour repondre a Adel13 (qui debute en C#) et à B.AF

Personellement je suis loin d'etre un adepte des principes academique d'architecture et je considere qu'une application qui tourne et qui fait ce qu'on attends d'elle est beaucoup plus respectable qu'une application qui respecte toutes les regle de design mais qui oublie de respecter avant tout ce qu'on attends d'elle

Cela etant je suis convaincu que meme pour une petite a application a deux forms et surtout quand on est débutant c'est le moment ou jamais de se casser un peu la tete pour essayer de mettre le moins de code possible dans la form quitte a concentrer toute la logique metier et l'acces aux données dans une seule classe a part
Faire cet effort au début apporte tres vite un beaucoup plus grand confort de design et de conceptualisation par après.

[Proteus91]

Bonsoir Oli. Je suis plutôt d accord avec ton propos. Trop respecter les règles tue la créativité. Cependant il faut appeler un chat un chat. Une classe pour accéder aux données, une ou plusieurs vues et gérer la logique métier (le contrôle) c déjà du mvc. On est foutu même si on veut pas en faire on est formatté design pattern =).

[B.AF]

Bonsoir Oli. Je suis plutôt d accord avec ton propos. Trop respecter les règles tue la créativité. Cependant il faut appeler un chat un chat. Une classe pour accéder aux données, une ou plusieurs vues et gérer la logique métier (le contrôle) c déjà du mvc. On est foutu même si on veut pas en faire on est formatté design pattern =).

Winforms, c'est déjà du modéle vue tout court. :-)
Moi ce que je dis c'est que se poser la question de faire un code très propre est intéressant. Après, c'est souvent que cette volonté prend le pas sur tout et que l'application devient un fourre tout qui contient 90% de plomberie et 10% de business logic; qui pour le coup devient elle difficile à maintenir.
Après, qui à apprendre, autant en profiter pour apprendre un peu de bonnes pratiques