DataSet Binding assistant et POO et compagnie ..

Version imprimable

23/11/2015, 21h43
david.catus

DataSet Binding assistant et POO et compagnie ..

Bonsoir,

Je m'adresse aux personnes d'expériences !
Je débute en c# et passe par la case winform (je ne veux pas rentrer dans le débat winform/WFP). J'essaye de développer en respectant les couches; vue/présentation
modèle
Controleur
mapping objet/bdd
Et là en parcourant le net, je constate que la plupart des personnes s'affranchissent de bcp de chose en matière POO. Un exemple, le DataSet (je sais il faut utiliser EF sinon on est bête :lol:) perso je génère le DataSet dans la couche DAL et retourne une liste d'objet. J'essaye de binder comme je peux les différents contrôles et passe entre les formulaires mes objets. je m'appercois rapidement que je galère (par manque d'expérience surement) pour gérer le binding, les mises à jours BDD, etc... Dernièrement je découvre le DataSet fortement typé associé avec un BindingSource et tout cela en mode quasi graphique et en peu de temps comment on peut actualiser, supprimer, insèrer les enregistrements.
Alors voila, j’avoue que je suis un peu désemparé, je continue à l'ancienne (from scrach) ou bien je vais à l'essentiel et ne regarde même pas si le code généré je suis en mesure de le comprendre. QUAND PENSEZ VOUS ?
24/11/2015, 10h38
ranzoken

Bonjour,

Sur le net si on trouve très rarement des exemples de mapping d'objet, c'est que cette partie du code est tellement spécifique qu'on le fait soit même à chaque fois, ou un framework de communication le fait pour nous.

Pour le DataSet associé au BindingSource qui est lui même associé au DataGridView que l'utilisateur a en face de lui et qu'il peut modifier à la volée.
Personnellement, je trouve ça mauvais, je l'ai fait une fois pour un de mes projets quand j'ai découvert cette méthode, et je ne le referais plus.

Ensuite, tout dépend de ton projet et du temps alloué dessus, si ton projet est un outils pour géré quelque donnée et que les uilisateurs savent ce qu'es une base de données, et qu'il savent la modifier, pour moi le bindingsource est une solution envisageable, mais si ton application est pour un autre type d'utilisateurs alors non pas de bindingsource.
Tu peux être sur que ces dernier entreront tous et n'importe quoi dans les champs, donc il faut un maximum de contrôle.

Bon après je ne suis pas le genre de personne dont tu cherchais l'avis, puisque j'ai peu d'expérience ^^
24/11/2015, 10h52
DotNetMatt

Les commentaires de ranzoken sont pertinents.

DataSet = préhistoire ! À l'origine du .NET Framework, IEnumerable<T> et tout ce qui en dérive n'existait pas. Donc le DataSet était parfait et permettait de bosser sur des "collections" d'objets. Aujourd'hui on a les List<T> et autres donc il vaut mieux s'en servir : c'est plus souple et contrairement au DataSet ca ne vient pas avec tout un tas d'outils qui ne servent à rien (le DataSet est lourd, notamment à cause de ca).

Notre ami rv26t a traduit une excellent série d'articles au sujet de la DAL, ca pourra sûrement t'intéresser :
- Architecture de couche d'accès aux données (DAL) de hautes performances — Partie 1
- Architecture de couche d'accès aux données (DAL) de hautes performances — Partie 2
- Architecture de couche d'accès aux données (DAL) de hautes performances — Partie 3

Je m'en suis servi sur pas mal de projets, et avec quelques évolutions on peut tout gérer simplement et proprement. Par exemple, j'ai rajouté une factory afin de pouvoir récupérer directement le bon parser en fonction du DTO demandé, le support pour d'autres types d'opération SQL (ExecuteScalar...).
24/11/2015, 22h10
david.catus

Bonsoir,

Merci beaucoup pour vos retours.

ranzoken, je m'adressais justement à des gens comme toi ayant un vécu sur des projets professionnels. Je conclus que tu utilise dans tes développements, tes propres méthodes pour valider la couche présentation (vérification des zones obligatoires, contenu, etc..). Concernant la couche DAL,
peux tu me dire si tu utilise exclusivement des frameworks comme EF pour économiser de la ressource homme ?

DotNetMatt, ~~je vais consulter les liens fournis~~, "factory afin de pouvoir récupérer directement le bon parser en fonction du DTO demandé" je ne connais pas ces notions. Je me permets de te poser la même question, au niveau de la couche DAL, systématises tu l'usage de EF ?

Je viens de regarder les liens, dommage c'est du VB mais bon, le principe reste le même. Je retrouve bien une approche objet, les DTO sont ce que j’appelle moi, mes objets de la couche "modeles". On reparle de polymorphisme...

Je vais chercher d'autres tuto en c# pour essayer de imprégner de ce paradigme de conception.
Si vous avez deux minutes pour répondre à mes questions, je clôturerais ma demande.

Merci encore
David
25/11/2015, 09h19
Kyroon

Bonjour,

Je rejoins mes collègues ci-dessus.

Concernant les liens, il y a les mêmes en C# :
Architecture de couche d'accès aux données (DAL) de hautes performances — Partie 1.
Architecture de couche d'accès aux données (DAL) de hautes performances — Partie 2
Architecture de couche d'accès aux données (DAL) de hautes performances — Partie 3

Je me sert également de cette solution pour mes développements. Concernant EF, je ne connais pas, je n'aime pas trop les usines ou on a pas trop la main et où l'on ne sait pas vraiment ce qui y est fait. Je rate peut-être quelque chose mais ça me va comme ça jusqu’à présent :).

Pour les DataSet, pareil, je n'en ai pas d'utilité, les List<T> et consœur répondent parfaitement à mes besoins, et je peux les manipuler comme je l'entend.

Bonne continuation.

Citation:

Envoyé par david.catus

Je conclus que tu utilise dans tes développements, tes propres méthodes pour valider la couche présentation (vérification des zones obligatoires, contenu, etc..). Concernant la couche DAL,
peux tu me dire si tu utilise exclusivement des frameworks comme EF pour économiser de la ressource homme ?

Oui, pour la couche d'affichage je varie souvent, étant donnée architecture mis en place (BDD avec ou sans Table utilisateurs, WCF,ASP,Winform),
mais je reviens souvent sur une de mes classes, qui gére l'affichage par rapport au Tag que j'ai rentré danx le control

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
public class Affichage
    {
        public static ModeAffichage _modeEnCours = ModeAffichage.visiteur;
 
        internal static void PasserEnMode(System.Windows.Forms.Form formulaire, ModeAffichage modeChoisi)
        {
            _modeEnCours = modeChoisi;
            AppliquerModeEnCours(formulaire.Controls);
        }
        private static void AppliquerModeEnCours(System.Windows.Forms.Control.ControlCollection controlesEnfants)
        {
            foreach (System.Windows.Forms.Control c in controlesEnfants)
            {
                c.Tag = ModeAffichage.connecter;
                if ((c.Tag != null) && (c.Tag is ModeAffichage))
                {
                    c.Enabled = (((ModeAffichage)c.Tag & _modeEnCours) == _modeEnCours);
                }
                AppliquerModeEnCours(c.Controls);
            }    
        }
    }
 
    public enum ModeAffichage
    {
        visiteur = 1,
        connecter = 2
    }

Pour ce qui est de la DAL, encore une fois ça dépend du projet, si le projet dépasse les 40 jour homme(mesure pris au hasard), avec des objet et des dépendance complexe
je met en place EF
Sinon j'utilise tous ce qui à de plus simple une bonne vielle classe d'accès au données.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
 
    class SQLAcces
    {
        /// <summary>
        /// utilisable dans un using, gere l'objet de connexion grace a un Provider Factory
        /// </summary>
        /// <param name="cnxName">non de la chaine de connexion enregistrer dans l'app config</param>
        /// <returns>IDbConnection</returns>
        public static IDbConnection SeConnecter(String cnxName)
        {
            IDbConnection cnx = null;
            ConnectionStringSettings settings = ConfigurationManager.ConnectionStrings[cnxName];
            cnx = DbProviderFactories.GetFactory(settings.ProviderName).CreateConnection();
            cnx.ConnectionString = settings.ConnectionString;
            cnx.Open();
            return cnx;
 
        }
        /// <summary>
        /// méthode pour se déconnecter, inutile si utilisation d'un using 
        /// </summary>
        /// <param name="cnx"></param>
        public static void SeDeconnecter(IDbConnection cnx)
        {
            if (cnx != null && cnx.State != ConnectionState.Broken && cnx.State != ConnectionState.Closed)
            {
                try
                {
                    cnx.Close();
                }
                catch (DbException ex)
                {
                    throw new ApplicationException(ex.Message);
                }
            }
        }
        /// <summary>
        /// méthode pour crée une commande capable de dialoguer avec la BDD
        /// </summary>
        /// <param name="cnx">notre IDbConnetion préalablement crée</param>
        /// <param name="requete">la requete SQL </param>
        /// <param name="type">Command Text ou Command Procédure Stocké</param>
        /// <returns>IDbCommand</returns>
        internal static IDbCommand CreerCommand(IDbConnection cnx, String requete, CommandType type = CommandType.Text)
        {
            IDbCommand cmd = cnx.CreateCommand();
            cmd.CommandText = requete;
            cmd.CommandType = type;
            return cmd;
        }
 
        /// <summary>
        /// fonction qui ajoute un parametre a la commande SQL passer en parametre 
        /// </summary>
        /// <param name="cmd">un IDbCommand qui contient l'objet de connexion</param>
        /// <param name="nomParametre">chaine de caractere ex: @Nom</param>
        /// <param name="valeurParametre"></param>
        /// <param name="typeParametre"></param>
        internal static void CreerParametre(IDbCommand cmd, 
                                        string nomParametre, 
                                        object valeurParametre, 
                                        DbType typeParametre)
        {
            IDbDataParameter param = cmd.CreateParameter();
            param.ParameterName = nomParametre;
            if (valeurParametre != null)
            {
                param.Value = valeurParametre;
            }
            else
            {
                param.Value = DBNull.Value;
            }
            param.DbType = typeParametre;
            param.Direction = ParameterDirection.Input;
            cmd.Parameters.Add(param);
        }
 
        /// <summary>
        /// retourne une liste T passé en paramètre.
        /// Attention le nom des colonnes de la BDD 
        /// doit être identique a vos propriété de votre class Métier
        /// </summary>
        /// <typeparam name="T"></typeparam>
        /// <param name="reader"></param>
        /// <returns>List T</returns>
        internal static IList<T> Liste<T>(IDataReader reader)
        {
            //création de la liste 
            List<T> retour = default(List<T>);
            try
            {
                retour = Activator.CreateInstance<List<T>>();   //création d'une nouvelle instance de la list
                if (reader.IsClosed)                            //vérification si le jeu de donnée est encore valide
                    throw new ApplicationException("La connexion est actuellement Fermer");
                while (reader.Read())                           //on boucle pour lire tout le jeu de donnée
                {
                    //création et récupération de notre objet BO
                    T obj = (T)Activator.CreateInstance(typeof(T));
                    foreach (System.Reflection.PropertyInfo propriete in typeof(T).GetProperties())
                    {
                        propriete.SetValue(obj,
                                    ! reader.IsDBNull(reader.GetOrdinal(propriete.Name))
                                    ? reader[reader.GetOrdinal(propriete.Name)]
                                    : default(Object));
                    }
                    retour.Add(obj); //on ajoute notre objet T a notre liste et on continue a lire notre reader
                }
            }
            catch (Exception ex)
            {
                throw new ApplicationException(ex.Message);
            }
            return retour;
        }

25/11/2015, 09h52
DotNetMatt

Citation:

Envoyé par david.catus

DotNetMatt, ~~je vais consulter les liens fournis~~, "factory afin de pouvoir récupérer directement le bon parser en fonction du DTO demandé" je ne connais pas ces notions. Je me permets de te poser la même question, au niveau de la couche DAL, systématises tu l'usage de EF ?

Non EF je ne l'utilise que très rarement, sur des projets "jetables" et relativement simples. Pour les projets complexes EF empêche d'avoir la main totalement sur le code SQL généré (ou du moins, ce n'est pas simple de tout contrôler). Donc pour éviter les soucis de performance sur ces projets complexes, je préfère avoir le contrôle sur tout avec une DAL classique (comme présentée dans les liens que je t'ai donné).

Citation:

Envoyé par david.catus

Je viens de regarder les liens, dommage c'est du VB mais bon, le principe reste le même. Je retrouve bien une approche objet, les DTO sont ce que j’appelle moi, mes objets de la couche "modeles". On reparle de polymorphisme...

Oui VB.NET permet de faire quasiment tout ce qu'on peut faire en C#. Si tu regardes les articles originaux, le code est en C#.

Sinon, la factory est un design pattern qui permet de construire des objets (ici les DTO) sans avoir à instancier leur class concrète. Tu peux te documenter plus en détails en cherchant "C# Factory design pattern" sur ton moteur de recherche préféré ;)
25/11/2015, 12h04
david.catus

Bonjour tout le monde et un grand merci à tous !

Je vais "digérer" vos retours, vos codes (merci ranzoken).

Je cloture la discussion sinon je vais vous poser 200 questions :lol:

Allez une dernière pour la route :

lorsque j'ai commencé à alimenter ma couche présentation, je récupérais de la DAL une liste d'objet métier pour rester dans l'approche POO par contre j'ai buté
sur certaines choses qui m'ont fait "basculer" sur les BindingSources comme par exemple, je n'arrivais pas à exploiter la donnée dans mes DataGrid, afficher la valeur d'une propriété d'un objet de la liste ou récupérer la valeur sélectionnée d'une cellule via un clic.

Merci
25/11/2015, 12h26
ranzoken
Citation:

Envoyé par david.catus

Je cloture la discussion sinon je vais vous poser 200 questions :lol:
i

Tu ne dérange pas du tout ^^, j'aime bien faire partager ma science, pour te dire je m'amuse à jouer au profs avec des amis qui débute l'informatique
(je rassure tous le monde, ils ont des vrai cours en parallèle)

Citation:

Envoyé par david.catus

lorsque j'ai commencé à alimenter ma couche présentation, je récupérais de la DAL une liste d'objet métier pour rester dans l'approche POO par contre j'ai buté
sur certaines choses qui m'ont fait "basculer" sur les BindingSources comme par exemple, je n'arrivais pas à exploiter la donnée dans mes DataGrid, afficher la valeur d'une propriété d'un objet de la liste ou récupérer la valeur sélectionnée d'une cellule via un clic.
i

Oubli le BindingSource ^^, le bindingsource étant la pour zappé la POO tu pouvais dialogué de l'ihm à la BDD.
puisque tu fait de ka POO, la DAL te génère un IList<T> qui la transmet a tas BLL ou tu renseigne un Getter qui retrouve une List<T>.
Puis dans l'IHM une seul et unique ligne

mondagaDrigview.datasource = BLL.MaClasse.MonGetterDeMaListe

Et magie magie ton control est remplis.
puis pour récupérer tes cellules tu as des propriétés, il faudra chercher un peu sur la MSDN
Code:

1 2 3 // récupérer la cellule en cours (VB.NET) sender.CurrentCell.Value.ToString
25/11/2015, 20h47
david.catus

Merci encore à vous tous.
30/11/2015, 21h17
david.catus

N'est plus résolue - Acte II

Bon désolé mais c trop intéressant pour moi, j'ouvre à nouveau la discussion.

Je suis en train de digérer les articles sur la couche DAL. En attendant, je continue mon application pour me faire la main. J'utilise donc exclusivement des DTO (unitaires ou list de DTO) entre mes différentes couches. J'affiche mes données dans mes DataGrid (plus de BindingSource et autre DataSet).
Au niveau de ma couche de présentation, comment puis je "compenser" les DataRelations qui me permettaient de lier deux contrôles via une pseudo jointure données/affichage ?
Peut être comme en dev Intranet MVC créer des objets de présentation (modèle vue) pour obtenir l'équivalent de DataRelation avec des méthodes sur les événements (clic par exemple) pour rafraîchir l'affichage du contrôle enfant ?

Merci