Discussion :

[david.catus]

Bonjour,

J'alimente un dataGridView à partir d'une liste d'objet "Procédure" obtenue via les couches BAL <-> DAL (procédure stockée simple select * from tblProcedure)

Code :

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

1
2
 BALayer objBal = new BALayer();
            dgListeProcedures.DataSource = objBal.listeProcedure();

La Classe BEL "Procedure" est constituée des propriétés suivantes :

Code :

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

1
2
3
4
5
6
7
8
        public int id { get; set; }
        public DateTime datecreation { get; set; }
        public DateTime datemodification { get; set; }
        public BEL_Personne redacteur { get; set; }
        public BEL_Personne valideur { get; set; }
        public string libelle { get; set; }
        public BEL_Categorie categorie { get; set; }
        public string fichier { get; set; }

Le DataGridView affiche :



Comme vous pouvez le constater j'ai besoin d'alimenter certaines colonnes avec du .Text de propriétés des objets concernés comme rédacteur (laprocedure.leredacteur.nom).
Je ne veux pas utiliser d'autre approche que List<object> pas de databinding et consort.

Que me conseillez vous ? je rajoute un traitement intermédiaire qui parcoure la List<Procedure> et j'alimente "manuellement" le dataGridview ?

Merci

[theMonz31]

salut

tu peux commencer par faire une surcharge des méthodes ToString() pour les objets de type BEL_Personne, BEL_Categorie, comme ça, tu afficheras
une données plutôt que le type de base de la classe.. ce qui pourrait suffire dans ton cas..

[youtpout978]

Oui ou tu peux créer une propriété te renvoyant le nom du rédacteur dans ta classe

Code :

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

1
2
3
4
5
6
7
8
 
public string NomRedacteur
    {
        get
        {
            return redacteur != null ? redacteur.nom : string.Empty;
        }
    }

[DotNetMatt]

Pour reprendre un peu la structure des projets en MVVM/MVC, on peut aussi rajouter un genre de ViewModel, BEL_Personne étant un Model.

Le ViewModel permet de ne garder que ce qui est strictement nécessaire à l'affichage. Comme son nom l'indique, c'est un Model qui est propre à la Vue.

[david.catus]

Merci pour ta réponse !

Je commence par faire une redéfinition de "toString()" dans ma classe BEL_Personne:

Code :

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

1
2
3
4
5
        public override string ToString()
        {
            return "blabla";
 
        }

Cela "fonctionne" :


Je modifie en :

Code :

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

1
2
3
4
5
        public override string ToString()
        {
            return nom;
 
        }

et pour que cela "fonctionne" dans ma couche DAL je définis pour l'exemple la valeur de la propriété nom de mes objets :

Code :

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

1
2
3
4
5
 procedure.redacteur = leredacteur;
                            procedure.redacteur.nom = "toto";
 
                            procedure.valideur = levalideur;
                            procedure.valideur.nom = "tata";

j'obtiens :


Forcement dans ma couche DAL il va falloir que j'aille chercher les valeurs qui m'intéressent pour les afficher. Pour ce faire j'imagine deux possibilités :

1) Une jointure dans ma procédure stockée.
2) Je créé une Classe BEL "hybride" procedure/personne (un peu comme les modèles de vue en C# . NET MVC) et dans ce cas,
la méthode DAL retourne une liste d'objet hybride.

Quand penses tu ?

[david.catus]

Oup's j'avais pas vu les autres réponses ! merci pour votre contribution

l'approche "VueModel" vous semble donc la plus pertinente !

En fait, dans les dataGridView vous utilisez (vos réponses dans les autres posts) vous utilisez des méthodes ou propriétés particulières
pour manipuler les liste DTO retournées ? ou bien on doit considérer comme dans mon exemple on alimente en datasource = objBAL.methodeliste() et la méthode toString affiche un point c'est tout ? vous arrivez à tout gérer dans vos applications ? (vous ne faites peut être plus de winform depuis longtemps ).

En tout cas merci beaucoup je vais continuer à avancer

[david.catus]

Oui ou tu peux créer une propriété te renvoyant le nom du rédacteur dans ta classe

Code :

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

1
2
3
4
5
6
7
8
 
public string NomRedacteur
    {
        get
        {
            return redacteur != null ? redacteur.nom : string.Empty;
        }
    }

là je ne comprends pas tout ! tu te situe ou dans l'application ? UI récupère une List<> depuis la BAL

[youtpout978]

Dans ta classe BEL "Procedure" mais il fait que la propriété rédacteur soit renseigné à ce moment là, sinon tu peux partir sur un VM comme indiqué par dotnetMatt.

[DotNetMatt]

Pour le "ViewModel", voici un exemple :

Deux DTO:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class MonDTO
{
    public string LastName { get; set; }
    public string FirstName { get; set; }
    public string Email { get; set; }
 
    // Référence vers l'autre DTO
    public MonSecondDTO MonObjet { get; set; }
}
 
public class MonSecondDTO
{
    public Guid Id { get; set; }
    public string Name { get; set; }
}

La couche DAL et BLL classiques qui traitent avec le DTO.

La couche UI en MVC :
- Un MonDTOModel, qui reprend quasiment toutes les propriétés du DTO. L'utilité du Model c'est que dans certains cas on peut ne pas avoir besoin de remonter toutes les propriétés du DTO dans la couche UI...
- Un MonDTOViewModel, dans lequel tu ne gardes que ce que tu veux afficher, par exemple ici juste le nom et le prénom, et le nom du DTO "MonObjet" :

Code :

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

1
2
3
4
5
6
public class MonDTOViewModel
{
    public string LastName { get; set; }
    public string FirstName { get; set; }
    public string MonObjetName { get; set; }
}

Quand tu construis ton ViewModel (par ex. dans le Controller pour MVC), tu lui passes la valeur de MonDTO.MonObjet.Name dans sa propriété MonObjetName.

Ensuite tu branches ta grid pour qu'elle soit bindée sur la structure du ViewModel.

Cela permet de garder une architecture assez clean et de pouvoir gérer plusieurs ViewModel pour une même grid/vue, ce qui offre un peu plus de flexibilité, au prix d'une légère complexité supplémentaire.


Les autres solutions données ici fonctionneront aussi très bien et sont plus simples. A toi de voir si tu veux ajouter cette petite complexité à ton projet ou non

[david.catus]

Mais comment puis je alimenter avec cette méthode "NomRedacteur" ma liste retournée au dataGridView ?

merci

[david.catus]

J'avais déjà utilisé cette approche ModelVue !
merci à tous pour vos retours

David