Discussion :

[Gluups]

Bonjour tout le monde,

J'ai écrit un composant utilisateur dans un projet WinForms sur .Net Core.

Comme j'ai ramé pour l'accès aux données (si quelqu'un a un tuyau là-dessus je suis preneur ; il faut utiliser systématiquement ADO ?), j'ai repris le projet sous .Net Framework, et là une fois la chaîne de connexion correcte ça marche.

Lorsque j'ai transféré le contrôle utilisateur d'un projet à l'autre, il a fallu naviguer au vu des messages d'erreur. À un moment il a fallu enlever InitializeComponent parce qu'il n'était pas défini, et plus tard le remettre sinon le composant n'affichait rien. Je serais incapable de dire à quel moment le InitializeComponent a refait surface, toujours est-il qu'il y a ce qu'il faut dedans.

Dans le code que j'ai mis en commentaire à l'invitation des messages d'erreur du compilateur, il y avait ça :

Code :

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

1
2
3
4
5
6
7
8
        //protected override void Dispose(bool disposing)
        //{
        //    if (disposing && (components != null))
        //    {
        //        components.Dispose();
        //    }
        //    base.Dispose(disposing);
        //}

Là maintenant l'application fonctionne bien, mais je me rappelle que si on n'est pas un peu sérieux avec la méthode Dispose, ça risque de se gâter au bout d'un moment.

Si j'enlève les marques de commentaires dans le fichier uc.designer.cs, un message d'erreur me signale que "components" n'est pas défini.

Si je me laissais aller à la flemme je décréterais que c'est propre à .Net Core, mais je ne suis pas tout-à-fait certain que ça serait du travail sérieux.

Alors, je me dis que quelqu'un va bien avoir un commentaire là-dessus.

[popo]

Tu parles de contrôles utilisateurs, donc d'objets héritant de UserControl et disposant donc déjà d'une implémentation de IDisposable.
Que ce soit en Framework ou en CORE, on implémente ou surcharge l'implémentation deIDisposable uniquement lorsque c'est nécessaire.
Et il y a de fortes possibilité de que si ce code est dans le fichier designer, il devait être nécessaire à l'origine.

J'ignore quelles manipulations tu as faites.
Mais ce code là n'est pas arrivé tout seul.
S'il faut maintenant le mettre en commentaire, c'est probablement parce qu'à l'origine components existait et qu'il a été perdu en cours de route.

De manière générale, ce n'est pas une bonne idée de vouloir passer de CORE à Framework.
Déjà parce qu'ils ne sont pas compatibles mais surtout parce que tu régresses dans la technologie.
C'est comme vouloir ouvrir un DOCX avec Word 98.

[Gluups]

Bon, d'accord, mais ça fait deux fois que je demande "et en .Net Core, qu'est-ce qui existe pour l'accès aux données ?", et deux fois que tout le monde botte en touche.

Il me semble me souvenir que j'ai un jour goupillé ça en ADO.Net, mais est-ce que c'est la seule voie ?

Bon alors pour la méthode Dispose apparemment tu dédramatises la chose, ça m'arrange.

[popo]

Bon, d'accord, mais ça fait deux fois que je demande "et en .Net Core, qu'est-ce qui existe pour l'accès aux données ?", et deux fois que tout le monde botte en touche.
Il me semble me souvenir que j'ai un jour goupillé ça en ADO.Net, mais est-ce que c'est la seule voie ?

ADO n'est qu'une technologie parmi tant d'autres.
Pose la question à Google et tu verras que la listes des possibilités est assez large.
Les plus répandues (selon moi) sont :

1. Entity Framework Core (EF Core) : C'est un ORM (Object-Relational Mapper) léger, extensible et open source développé par Microsoft. Il permet aux développeurs de travailler avec des données en utilisant des objets de domaine sans avoir à se soucier des tables et des colonnes de la base de données sous-jacente. Il utilise ADO.
2. Dapper : C'est un micro-ORM simple et flexible qui fournit des fonctionnalités de mappage objet-relationnel pour .NET. Il est particulièrement utile lorsque vous avez besoin de performances optimales, car il offre un accès direct à la base de données sans la surcharge d'autres ORMs plus volumineux.
3. NHibernate : C'est un ORM mature pour .NET qui offre une grande flexibilité et une large gamme de fonctionnalités. Il a une courbe d'apprentissage plus raide que EF Core ou Dapper, mais il est très puissant une fois maîtrisé.
4. PetaPoco : C'est un micro-ORM pour .NET qui a pour objectif d'être simple, rapide et léger. Il offre un accès direct à la base de données avec un minimum de surcharge.

Personnellement j'utilise Entity Framework Core.

Bon alors pour la méthode Dispose apparemment tu dédramatises la chose, ça m'arrange.

C'est tout le contraire, je dis que tu as sans doutes des trous dans ta raquette.

[Gluups]

Oui j'en ai vu quelques-unes en cherchant ce matin, mais je crois que j'ai bien fait de poser la question car tu m'en sors encore d'autres.

Quand j'ai cherché l'année dernière (sans forcément orienter plus sur .Net Core ou Framework), j'ai trouvé que dans une certaine mesure les nouvelles fonctionnalités des DataSet rendaient Entity Framework obsolète. Bon apparemment, c'est à moduler. Je me rappelle avoir essayé d'installer un projet avec Entity Framework, qui n'a pas tourné, et je n'ai jamais eu de réponse dans le forum du projet d'où ça venait.

On dirait que je serais bien inspiré d'y revenir.

Effectivement je sentais bien ma raquette un peu molle, c'est un peu pour ça que je suis venu faire un tour par ici.

[micka132]

Quand j'ai cherché l'année dernière (sans forcément orienter plus sur .Net Core ou Framework), j'ai trouvé que dans une certaine mesure les nouvelles fonctionnalités des DataSet rendaient Entity Framework obsolète.

Je crois pas qu'il y ait grand monde qui commence des nouveaux projets avec des dataset depuis une dizaine d'année!
Malgré tout ca marche toujours très bien ADO !

Je suis tombé sur un petit article tout frais qui pourrait t'intéresser:
https://www.c-sharpcorner.com/articl...ld-you-choose/

[popo]

Je me rappelle avoir essayé d'installer un projet avec Entity Framework, qui n'a pas tourné, et je n'ai jamais eu de réponse dans le forum du projet d'où ça venait.

As-tu pris la bonne version d'EF.
Il est existe une pour Framework et une autre pour CORE.
Elles ne sont pas pas compatibles et ne fonctionnent pas du tout à fait de la même manière.
Un exemple notable avec EF CORE, il n'y a plus d'EDMX.