Discussion :

[javalhoussain]

Bonjour,

J'ai commencé a programmer en ASP.NET et je trouve des tuto utilisant code aspx et autre travail avec code behind.par exemple la connexion a la base je trouve comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
Sub Page_Load(sender As Object,e As EventArgs)
Dim myConnection As SqlConnection
Dim myReader As SqlDataReader
Dim myCommand As SqlCommand
myConnection = CType(Session("myConnection"),SqlConnection)
myCommand = new SqlCommand("HistoriqueStock",myConnection)
myCommand.CommandType = CommandType.StoredProcedure
myCommand.Parameters.Add("@ProduitID",SqlDbType.Int).
myCommand.Parameters("@ProduitID").Value = Request.Params("id")
myReader = myCommand.ExecuteReader()
myReader.Read()
NomProduit.Text = myReader.GetString(4)
myReader.Close()

et dans autre tuto je trouve comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
<asp:SqlDataSource ID="SqlDataSource1" runat="server" 
        ConnectionString="<%$ ConnectionStrings:basedossierConnectionString %>" 
         InsertCommand="INSERT INTO dossier(num_dossier, num_envoi_commune, num_arrivee_agence, date_arrivee_agence, observation, petitionaire, date_envoi_commun, idautre_avis, date_envoi_agance, num_envoi_agence, id_commune, code_projet, reference_fonciere, id_Archetecte, id_topographe)
          VALUES (@num_dossier, @num_envoi_commune, @num_arrivee_agence, @date_arrivee_agence, @observation, @petitionaire, @date_envoi_commun, @idautre_avis, @date_envoi_agance, @num_envoi_agence, @id_commune, @code_projet, @reference_fonciere, @id_Archetecte, @id_topographe)" 
 
 
        SelectCommand="SELECT * FROM [dossier]" 
 
        ProviderName="<%$ ConnectionStrings:basedossierConnectionString.ProviderName %>">

Je sais laquelle des deux méthodes a suivre coder en code ASPX dans les page aspx ou coder en page du code behind ??

Merci de fournir d'aide.

[Nathanael Marchand]

Les deux fonctionnent. Cependant attention lorsqu'on met de la logique dans la page ASPX: c'est horrible pour la maintenance.
C'est donc préferable de passer par le code behind.
Ta page ASPX ne doit contenir qu'une description de ton interface utilisateur (textbox, case à cocher, etc)

[EMC51]

Tout à fait d'accord.

Le code behind permet de clairement séparer la partie "IHM" du code et c'est bien plus facile à maintenir ainsi.

Au passage, le morceau que tu montres n'est pas du code mais les requêtes d'un SqlDatasource qui elles font automatiquement partie de l'ASPX quand elles sont statiques comme ici.

[ced600]

Le code behind permet de clairement séparer la partie "IHM" du code

Je ne suis pas vraiment d'accord avec vous. L'asp.net ne respecte pas la norme MVC car sur les pages ASP il n'y a pas de réelle séparation entre la vue et le modèle.
C'est d'ailleurs pour cela que MS c'est amusé à sortice asp.net mvc2, histoire de respecter le modèle MVC.

Si je suis votre logique : Il vaut mieux séparer la vue du modèle et du controlleur, alors il faut remettre en cause l'asp.net mvc et uniquement développez en asp.net mcv2.
Ce serait en soit une hérésie, le développement en asp.net mvc2 est beaucoup plus long qu'en asp.net et nécessite de meilleur connaissance en html.
En fait cela dépend avant tout des délais pour le projet, de la compléxité du site web, des besoins du client (une forte ou faible maintenabilité peut être un des besoins du client), de l'équipe de développeur, du profit qu'apportera ce développement, ...
Bref, il y a des cas où il vaut mieux être plus rapide, moins optimisé, et moins maintenable que propre, ultra optimisé, et très maintenable.

Donc pour en revenir à l'aps.net mvc uniquement, il peut s'avérer utile certaine fois de développez coté aspx, même si cela a un coût au niveau maintenabilité, pour être plus rapide dans le développement et si le niveau du ou des développeurs ne permet de faire mieux coté code behind.
Bien sûr cela aura ses limites lorsqu'il y a besoin de faire de répondre à des besoins assez complexe au niveau technique sur des gridview ou datagrid par exemple.

[Er3van]

J'aimerai bien que tu me détailles les cas où c'est plus rapide, ou même plus facile de développer côté ASP que code behind.

Et sans parler de MVC, c'est clairement plus propre et plus logique d'avoir une séparation entre l'aspect graphique et le process qui est derrière, sans même parler de contrôleur.

[ced600]

Très simple, l'année dernière sur une mission j'ai repris la maintenance d'un site en temps que MOE et avec comme MOA le développeur originel de ce site.

C'est un simple site qui permet de parcourir le contenu de x catalogues stockés en base de données, avec peu d'utilisateur à la journée et utilisé que quelque fois dans le mois, mais site indispensable pour les services qui ont renseignés leurs catalogues.
Ce développeur a réalisé ce site pour simplifier la réalisation de ses propres taches sans aucune réelle qualification en dév, sans aucun moyen, et avec des délais très court car à coté il devait faire son travail normal.
Donc cas d'une équipe réduite, peu qualifié et avec un délais court.
Il a réalisé le site pour un premier service et il lui a été plus rapide et plus sur de le faire sur les pages aspx. Il est plus facile d'écrire dans un langage balise une gridview connecté à une source de donnée sql que de faire la même chose en code behind.
De plus au niveau évolution, et création de nouvelles pages similaires pour la consultation d'autres catalogues pour d'autres services, cela ne lui posait pas de problème car il faisait du "copié-collé-adaptation" des pages crées pour le premier service.

Au vu de son niveau je suis persuadé qu'il a été plus rapide et s'est évité pas mal de bug en le faisant coté aspx.

Quand il a eu une équipe de dév à ses ordres pour "fiabiliser" l'outil, il a accepté des demandes d'évolutions entrainant plus d'éffort technique.
Alors j'ai pu constaté le manque de maintenabilité de sa méthode lorsque que l'on sort des modèles simple proposés par l'écriture sous forme de balise coté aspx.

Et sans parler de MVC, c'est clairement plus propre et plus logique d'avoir une séparation entre l'aspect graphique et le process qui est derrière, sans même parler de contrôleur.

On s'en fou que cela soit plus propre, plus logique, plus beau, ...
Si tu mets trois mois pour faire ton super site et moi 1 mois pour un site moyen, et que la différence de rendu n'est pas perceptible par les utilisateurs il vaut peut être mieux y passer un seul mois.
Après cela dépend de tes contraintes au niveau déploiement, maintenabilité, délais, ...

Bref, le mieux n'est pas toujours le plus adapté dans le monde de l'entreprise.
Il vaut mieux des fois faire moins bien mais économiser au niveau temps et argent tant que l'on respecte les exigences clients.

[Er3van]

Voici les critères que tu avais cité dans un premier temps.

En fait cela dépend avant tout des délais pour le projet, de la compléxité du site web, des besoins du client (une forte ou faible maintenabilité peut être un des besoins du client), de l'équipe de développeur, du profit qu'apportera ce développement

Voici maintenant les critères que tu évoques que tu précises la situation dans laquelle c'est plus avantageux :

Donc cas d'une équipe réduite, peu qualifié et avec un délais court.
Il a réalisé le site pour un premier service et il lui a été plus rapide et plus sur de le faire sur les pages aspx

Du coup, effectivement, si on fait faire une application par des non-informaticiens ou non-développeur, faut pas s'étonner d'avoir une qualité médiocre en sortie.
Mais on est bien d'accord que c'est quand même rare que les besoin du client, la complexité du projet ou la maintenabilité amènent à un développement de ce type.

Au vu de son niveau je suis persuadé qu'il a été plus rapide et s'est évité pas mal de bug en le faisant coté aspx.

On est donc bien d'accord que c'est le cas pour un non-informaticien.
Mais est-ce donc pour autant voué à servir d'exemple ?

Il est plus facile d'écrire dans un langage balise une gridview connecté à une source de donnée sql que de faire la même chose en code behind.

Quand on n'est pas développeur, sans doute. Encore que la MSDN (pour peu qu'on sache qu'elle existe, et Visual Studio 2010 offrent tous deux des moyens à portée du premier venu pour faire des actions élémentaires, voire plus.
Quand on est développeur, je ne vois pas en quoi. Je pense même mettre moins de temps en code behind

On s'en fou que cela soit plus propre, plus logique, plus beau, ...

Toi peut-être, mais le type qui reprend l'application derrière toi il préfère quand c'est lisible et qu'il peut comprendre facilement, surtout si jamais il n'y a pas de documentation et/ou que personne n'a eu le temps de lui faire un transfert de compétences.

Bref, le mieux n'est pas toujours le plus adapté dans le monde de l'entreprise.

En effet, c'est même généralement le plus simple qui marche le mieux.
Pour autant, il ne faut pas confondre simplicité et facilité.

[Nathanael Marchand]

Oula attention! Ne me faites pas dire ce que je n'ai pas dit!
Je ne parle pas de faire du MVC...
Je parle de surtout pas mettre de datasource avec les requêtes SQL dans la page ASPX...

Ca coute pas plus cher de faire une DAL+BL que de coder crado. Effectivement, ca demande un minimum de connaissance.

Parcequ'après on se retrouve avec des enormes bouses qui ont pris des proportions incroyables. La petite appli qu'un MOA a fait à l'arrache sur Access + Winform et qui devait être confidentielle et pour une durée limitée se retrouve industrialisée. C'est une plaie à entretenir et aucun décideur ne voudra donner du budget pour refondre l'appli sur une archi propre.

Je parle pas de faire une appli référence avec toutes les best practices mais il y'a un nécessaire vital (le kit de survie...).

[Er3van]

On est bien d'accord.

Ca coute pas plus cher de faire une DAL+BL que de coder crado. Effectivement, ca demande un minimum de connaissance.

Apparemment ça peut-être la raison qui pousse dans la voie contraire, mais là je ne vois pas ce qu'on peut y faire...

[Nathanael Marchand]

En même temps c'est pas le boulot de la MOA de faire de la MOE... C'est pour ca que dans nos équipes, la MOA ne doit pas être ancien IT. Ou si ancien IT, interdit de faire de la bidouille via macro Excel, Access, etc.

[hwoarang]

Mouais, c'est pas parce que c'est autorisé par l'IDE que c'est simple a maintenir. Mettre ce genre de code dans la page aspx rend le code illisible et la maintenance plus difficile.

Ca me rappelle le C. On peut declarer des variables et tout ce qu'on veut dans le header. Mais apres, pour maintenir, le programme... Bah c'est poubelle et on recommence tout. Surtout que dans ce cas, ca coute pas plus cher de faire la connexion en code behind... (comme les autres, je ne parle pas de MVC mais simplement de mettre le code dans le fichier .cs plutot que dans le .aspx)

[ced600]

Je pense que l'on est assez d'accord.
Je voulais juste dire qu'il n'y a pas de situation vrais qui est toujours mieux adapté.
Selon les besoins du clients, la politique de ta société, les moyens humains et techniques mis à disposition, les délais de réalisation, il peut être envisagé de faire moins propre, moins maintenable, mais plus rapide tout en restant fonctionnelle.
Et bien souvent c'est un problème de compétence je suis d'accord.
Si on prend l'exemple d'autre langage comme le C++, si tu parles à un spécialiste de la conception d'IHM il te dira qu'il vaut mieux tout faire à la main sans l'aide d'outil facilitant la création d'IHM.
Si j'ai en charge une équipe de débutant en C++, je préférerais qu'ils utilisent ce genre d'outil d'aide car je suppose que le code généré sera de meilleur qualité que s'ils l'avaient conçus eux même. Certe ils ne progresseront pas, ou peu, ainsi mais si le projet à réaliser à des délais très court, il n'y aura pas forcément assez de temps pour permettre un auto-apprentissage du langage.

J'ai un autre exemple sur l'asp.net entre l'intérêt d'écrire en code behind sur la page aspx.
Cela concerne cette fois-ci du javascript, plus précisément du Jquery.
J'ai crée un usercontrol qui gére une textbox, quelques boutons, champs hidden, et un script Jquery pour faire de l'autocomplete.
Ecrire le script sur la page aspx est beaucoup plus simple que dans la methode render en codebehind via registerscriptblock.
De plus cela facilite sa maintenance et son débogage.
Mais à chaque appel du user control le script sera de nouveau enregistré sur la page ce qui l'alourdira et diminuera les performances de la page.
Par contre en gérant l'enregistrement d'un tel script sur la page en code behind tu peux vérifier que celui-ci n'est pas déjà présent sur la page pour éviter de l'avoir en doublon et optimiser celle-ci.
De plus en code behind tu auras plus de faciliter pour passer une valeur d'une properties de l'UC à ta fonction javascript que tu écris.
Par contre la maintenance du script en lui même sera plus difficile car le script en devient moins lisible. Surtout lorsque tu essayes de voir s'il ne te manque pas un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

});

quelque part.

Donc pour résumer, cela dépend toujours de ton contexte, de tes besoins en optimisation, maintenance, delais de réalisation, qualité de ton équipe ...