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.