Journal MVC avec ASP.NET

Posté par  .
Étiquettes : aucune
0
19
avr.
2006
Bonjour,

J'ai décidé de creusé un peu vers les technologies .NET car c'est quelque chose qui est assez demandé sur le marché du travail actuellement ici en suisse.

J'ai donc essayé de réaliser une petite application bateau avec ASP.NET, non sans peine il faut le dire.

Voilà je livre l'expérience acquise via cet article :

http://dosimple.ch/articles/MVC-ASP.NET/

Les corrections et commentaires sont toujours bienvenue.

Cordialement,
Batiste Bieler
  • # Quelques remarques en vrac

    Posté par  . Évalué à 9.

    Bon, rien de très original, mais comme c'est plus ou moins un tutoriel, autant de pas donner de mauvaises habitudes à tes lecteurs. Apprendre le MVC ne doit pas être une occasion de faire n'importe quoi sur le reste.

    1) Ne JAMAIS gérer les paramètres d'une requête SQL par concaténation
    Quand tu fais un "SELECT * FROM matable WHERE monchamp='" + var + "'", demande-toi ce que fera ton programme si l'utilisateur a saisi "25'; DROP DATABASE system; print 'tu t'es fait eu"...

    2) Essaye de passer des objets à tes méthodes DELETE
    En effet, une méthode avec une signature aussi générique que "mamethode(String id)" ne permet pas au compilateur ou à la VM de contrôler grand chose. Et si tu passes un identifiant de commande à la méthode "DeleteClient()", tu t'exposes à des problèmes...

    La même remarque vaut pour les autres appels à la base.

    En espérant avoir été utile...
    • [^] # Re: Quelques remarques en vrac

      Posté par  (site web personnel) . Évalué à 1.

      J'approuve ces remarques et renvois au site suivant : http://quiz.ngsec.com/

      Mais je me pose quand même la question : sur le point 1, quelle solution de remplacement préconises-tu ? Une vérification sur les champs ?
      • [^] # Re: Quelques remarques en vrac

        Posté par  . Évalué à 1.

        L'utilisation des paramètres dans les SqlCommand:

        http://www.csharp-station.com/Tutorials/AdoDotNet/Lesson06.a(...)

        Au passage quelques commentaires:
        - Pense à la localisation, surtout si tu es en suisse, il est probable que ton application doivent supporter plusieurs langue (et c'est le genre de truc qu'il est souvent pénible d'envisager après).
        - Le MVC c'est la séparation vue/modèle (et un controller pour décoder), un des problèmes de cette approche, c'est la validation: est-ce du modèle? de la vue? les deux? (valider qu'un champs doit être rempli peut être de la vue, valider que le client est connu dans la base de donnée sera du modèle). Ce n'est pas à négliger dans le développement.
        - Pourquoi ne pas utiliser des DataSet typé?
        - Gérer les connections db dans la vue, pas top du tout... ça se comportera comment avec un framework permettant de faire du ajax? un load par appel? etc...
        - enfin petit commentaire perso: arrrghhh du français dans les noms de variables!!!! (quoi que cela permet de punir les développeurs qui ont cassés le repository de source: vous me traduirez 20 pages de code source :p).
        • [^] # Re: Quelques remarques en vrac

          Posté par  . Évalué à 1.

          "Pense à la localisation, surtout si tu es en suisse, il est probable que ton application doivent supporter plusieurs langue (et c'est le genre de truc qu'il est souvent pénible d'envisager après)."

          Je ne sais pas trop comment gérer cela avec ASP.NET/C#.

          "Le MVC c'est la séparation vue/modèle (et un controller pour décoder), un des problèmes de cette approche, c'est la validation: est-ce du modèle? de la vue? les deux? (valider qu'un champs doit être rempli peut être de la vue, valider que le client est connu dans la base de donnée sera du modèle). Ce n'est pas à négliger dans le développement."

          En effet, mais comme la vue peut changer, je préconise la validation dans le contrôle. Certaine validation peuvent être effecutée dans la vue. Dans le cas d'une application web, il y a parfois redondance. Autrement je vois pas ou est le problème.

          "- Pourquoi ne pas utiliser des DataSet typé?"

          Surement parce que je ne sais pas ce que c'est :)

          "- Gérer les connections db dans la vue, pas top du tout... ça se comportera comment avec un framework permettant de faire du ajax? un load par appel? etc..."

          Ce n'est pas vraiment le cas là, je considère qu'il s'agit du contrôleur. Comme la connection doit de toute façon s'établir dans cette page, j'ai décidé de procéder ainsi et de mettre dans Page_Load. En quoi cela est-il géré dans la vue ?

          "enfin petit commentaire perso: arrrghhh du français dans les noms de variables!!!! (quoi que cela permet de punir les développeurs qui ont cassés le repository de source: vous me traduirez 20 pages de code source :p)."

          Bha, ... Si c'est destiné à un public français ...
          • [^] # Re: Quelques remarques en vrac

            Posté par  . Évalué à 1.

            "je préconise la validation dans le contrôle"

            En fait on voit dans cette application que j'ai mis un début de validation dans le contrôle. Il y en a dans le modèle (au niveau de la base données), et il pourrait également en avoir dans la vue ...

            C'est vrai que c'est un "problème" du modèle MVC. Je n'ai aucune idée de comment les autres modèle s'en tirent ...
          • [^] # Re: Quelques remarques en vrac

            Posté par  (site web personnel) . Évalué à 4.

            "Je ne sais pas trop comment gérer cela avec ASP.NET/C#."
            http://msdn2.microsoft.com/en-US/library/c6zyy3s9(VS.80).asp(...)

            c'est la validation: est-ce du modèle? de la vue? les deux?
            Là c'est plus un problème général à la programmation objet. Une pratique courante veut qu'un objet est responsable de son état et des informations qu'il contient.
            Le minimum dans une application est que le modèle métier soit robuste : les informations doivent donc être validées dans le modèle. Y associer un ensemble de tests unitaires pour s'assurer qu'il n'y a pas de régressions.
            Ensuite l'interface (vue/controlleur) doit dans l'idéal n'autoriser la saisie que d'information valides vis-à-vis du modèle. Un mask peut être appliqué par exemple côté client, tu peux également faire des vérifications dans le contrôleur, dans le pire des cas l'information non valide arrivera au modèle qui DOIT te lever une belle exception :)

            Dans tous les cas, si tu veux te protéger de tentatives de hack SQL, c'est la classe manipulant la base de données qui s'occupe de faire la validation : elle est la seule censée connaître la couche d'accès aux données (ici une base de donnée), elle est donc la seule à savoir quels problèmes potentiels peuvent survenir.
        • [^] # Re: Quelques remarques en vrac

          Posté par  . Évalué à 1.

          - enfin petit commentaire perso: arrrghhh du français dans les noms de variables!!!! (quoi que cela permet de punir les développeurs qui ont cassés le repository de source: vous me traduirez 20 pages de code source :p).


          Dans l'ensemble, je fais le contraire : je punis les développeurs qui mettent de l'anglais dans les noms de variables.
          D'abord parqu'il n'y a aucune raison de ne pas en mettre, ensuite parcque les développeurs francophone parlent moyennement bien anglais, et qu'on voit pas mal de conneries dans le source, genre de l'anglicisation de mots français.
          • [^] # Re: Quelques remarques en vrac

            Posté par  (site web personnel) . Évalué à 5.

            genre de l'anglicisation de mots français.
            Bof, ca peut au contraire être une bonne raison pour perfectionner son anglais.
            Et puis on peut faire la remarque inverse, combien de "francisation" de termes anglais rencontre-t-on ? Tu traduis comment "handler" ? "runtime" ? "library" ? "get" ? "set" ?
            Surtout que certains frameworks fournissent des "guidelines" avec notamment des conventions de nommage qui sont systématiquement en anglais. Alors tu fais quoi ? Tu traduits "les lignes de conduites", ce qui revient à ne plus les respecter (puisqu'on ne facilite plus la relecture par d'autres développeurs), ou alors tu mixes anglais et français ?
            A la rigueur je peux concevoir l'utilisation du français dans un composant purement proprio et non destiné à être réutilisé. Mais bon forcé de constater que ce n'est pas le courant conseillé quand on veut promouvoir les logiciels libres (et donc "open-source", pardon "à code source ouvert" ;) )
          • [^] # Re: Quelques remarques en vrac

            Posté par  . Évalué à 4.

            D'abord parqu'il n'y a aucune raison de ne pas en mettre

            Vouloir exporter son source? permettre de le vendre? permettre à des non francophone de le comprendre plus facilement?

            Si ton marché se limite à la France, exclusivement la France et toujours la France, vi prend le risque :p

            ps: c'est bien une attitude de français ça ;) (moinsez moi)
    • [^] # Re: Quelques remarques en vrac

      Posté par  . Évalué à 2.

      Intéressantes remarques.

      Pourrais tu développer un peu d'éventuelles solutions ?

      Pour le point 2 tu préconise la création d'objets de type commande ? ... et par exemple il faudrait faire quoi ?

      ma_commande = new commande(1);
      ma_commande.delete();

      ou encore

      ma_commande = new commande(1);
      Model.delete_commande(ma_commande);

      Cela pourrait effectivement réduire les erreurs mais ça demande plus de travail au niveau du modèle.

      Pour le point 1 je serais heureux que tu développes !
      • [^] # Re: Quelques remarques en vrac

        Posté par  . Évalué à 1.

        Pour le point 2 tu préconises la création d'objets de type commande ?

        En fait, la plupart du temps, les objets sont déjà chargés. Genre, tu as une liste d'objets, tu en as sélectionné un, il suffit de le passer en paramètre à une méthode de ta couche d'accès aux données.

        Pas besoin donc de le recréer ou de le recharger, mais ça suppose que tu conserves en session la liste des objets déjà chargés.
    • [^] # Re: Quelques remarques en vrac

      Posté par  . Évalué à 1.

      Voilà le problème 1 est corrigé :)

      Le point 2 ammène trop de complexité pour un si petit exemple.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.