Le pari .NET vu du plancher

Ça fait quelques semaines que je suis sur mon mandat, et tout le monde autour de moi parle de .NET comme si c’était la fin du vieux monde. Moi, vu du plancher, ce que je vois surtout, c’est un nouveau framework à apprendre vite pis du code à livrer pareil. La grande vision, je la laisse aux slides. Moi, j’ai un formulaire à finir pour vendredi.

Le premier vrai choc, c’est le choix du langage. VB.NET ou C#? Dans l’équipe, le monde qui venait de VB6 saute sur VB.NET parce que ça paraît familier. Les autres, plus orientés C ou Java, partent direct sur C#. Au fond, ça compile sur le même CLR, ça donne le même IL. C’est plus une histoire de confort que de performance. J’ai pris VB.NET, parce que c’est ce que le client roule déjà.

Un formulaire, des données, pas de magie

Là où .NET devient concret pour moi, c’est ADO.NET. Avant, ouvrir une connexion pis lire des données, c’était toujours un peu croche. Là, le SqlConnection pis le SqlDataReader rendent ça pas mal plus propre. Mais propre veut pas dire sans piège: si t’oublies de fermer ta connexion, tu finis avec un pool vide pis une application qui gèle.

Dim cn As New SqlConnection(connStr)
Dim cmd As New SqlCommand("SELECT NoClient, Nom FROM Clients WHERE Actif = 1", cn)
Try
    cn.Open()
    Dim dr As SqlDataReader = cmd.ExecuteReader()
    While dr.Read()
        cboClients.Items.Add(New ClientItem(dr.GetInt32(0), dr.GetString(1)))
    End While
    dr.Close()
Catch ex As SqlException
    MessageBox.Show("Impossible de charger les clients: " & ex.Message)
Finally
    cn.Close()
End Try

Rien de spectaculaire. Mais ce petit bloc-là, c’est 80 % de ce que je fais ces temps-ci: aller chercher des données, les mettre dans un contrôle, gérer le cas où ça plante. Le Try...Catch...Finally, c’est devenu mon réflexe. Le Finally, surtout. C’est lui qui sauve la connexion quand le reste pète.

Le chemin que les données prennent

Quand j’explique mon écran à un collègue, je le dessine toujours pareil: l’utilisateur tape dans le formulaire, mon code valide, ADO.NET parle à SQL Server, pis la réponse remonte.

flowchart LR
    A[Formulaire WinForms] --> B[Code VB.NET<br/>validation]
    B --> C[ADO.NET<br/>SqlConnection]
    C --> D[(SQL Server)]
    D --> C
    C --> B
    B --> A

Vu de même, .NET arrête d’être un buzzword. C’est juste une plomberie un peu plus moderne entre mon écran pis ma base de données.

Ce que je retiens pour l’instant

Le pari .NET, du plancher, c’est pas une révolution philosophique. C’est moins de code répétitif, une gestion d’erreurs plus claire, pis un langage qui me laisse me concentrer sur le problème du client au lieu de la tuyauterie. Est-ce que ça va tenir ses promesses sur les gros systèmes? Aucune idée encore. Mais pour livrer un formulaire qui marche pis qui plante proprement, je suis déjà gagnant. La suite, on verra ça un mandat à la fois.