Discussion :

[Kropernic]

Hello,

Je viens vous voir car je suis à la recherche d'un type de liste commun à WPF et Winforms pour remplacer respectivement ObservableCollection et BindingList.

Lors du développement en couche, la couche logique qui est consommé par le couche graphique est sensée être indépendante de cette dernière. Or, pour le moment, quand je développe en Winforms, j'utilise des listes de type BindingList et en WPF, des listes de type ObservableCollection. Ces deux types de listes permettent de mettre à jour "automatiquement" le composant graphique qui les affiche.

Mais cela rend la couche logique dépendante de la couche graphique et je cherche à m'affranchir de cette dépendance.

J'ai rien trouvé de probant lors de recherche sur le net.

Comment feriez-vous ?

[Noxen]

Je ne suis pas très de ce que tu cherches à faire. Dans un modèle en couche on a une logique métier qui est consommée par une couche applicative, laquelle peut se composer d'une couche de logique interactive qui fera le lien entre les actions utilisateur et les services métier, ainsi que d'une couche de présentation graphique qui prendra en charge l'affichage des données et la capture des actions utilisateur. En principe WPF et WinForm sont deux technologies de couche applicative différentes, bien qu'il soit possible d'héberger des composants d'une technologie dans l'autre ; et que l'on puisse sans doute extraire la part de logique interactive.

Est-ce-que tu utilises une approche "hybride" qui utilise à la fois du WPF et du WinForm (est-ce d'ailleurs possible) ? Est-ce-que tu as un service qui peut être utilisé par deux applications reposant sur des technologies différentes ? Dans quel contexte dois-tu choisir entre une ObservableCollection et une BindingList ? Est-ce pour la valeur de retour du service ? Dans ce cas mon parti-pris serait le suivant : un service qui renvoie une liste d'objets devrait le faire sous la forme d'une collection énumérable abstraite, car il s'agit d'une liste qui doit être consultée, c'est une autre fonction qui devrait prendre en charge la mise-à-jour des données. Par exemple :

Code :

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

public IEnumerable<User> GetUsers();

Ce sera ensuite le code consommateur qui instanciera l'objet dont il a besoin à partir de cette liste. WPF :

Code :

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

var users = new ObservableCollection<User>(service.GetUsers());

Tu peux jeter un œil aussi aux CollectionView. Ceci-dit je te donnes mon avis un petit peu hors contexte, peut-être que tu as des contraintes qui ne te permettent pas de suivre ma suggestion.

[Kropernic]

Hello,

Déjà, merci pour la réponse.

Il n'est pas question d'approche hybride. C'est juste que, sur certains projets, on fait du winforms et sur d'autre, du wpf.

Je vais essayer d'être plus clair...

Disons qu'on a une classe de la couche logique qui s'appelle "UnObject" et contient les propriétés P1, P2 et P3.

En winforms, je ferais par exemple :

Code :

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

monDataGridView.DataSource = UnObject.GetListFromDB(param1, param2)

Où la signature de la fonction GetListFromDB serait Static BindingList(Of UnObject) GetListFromDB(param1 as object, param2 as object)En wpf, je ferais par exemple (en supposant qu'il n'y a pas de binding du côté xaml) :

Code :

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

monDataGrid.ItemsSource = UnObject.GetListFromDB(param1, param2)

Où la signature de la fonction GetListFromDB serait Static ObservableCollection(Of UnObject) GetListFromDB(param1 as object, param2 as object)J'utilise ces types de liste car c'est en fait la classe UnObject qui gère sa liste et y ajoute/supprime des éléments. Il est donc important que ce soit mis à jour du côté graphique. D'où le fait d'utiliser ce type de liste à notifications.

Mais cela rend la couche logique "dépendante" dans la couche graphique (nos couches sont graphique -> logique (métier) -> données (accès db) + dto en couche transversale).

Si ça se trouve, je (enfin on, car on est deux) suis complètement à côté de plaque et ce n'est pas la bonne manière de coder ^^.

Est-ce plus clair ?

[popo]

Comme le précise Noxen et comme tu le suggère toi même, ce n'est pas la bonne méthode car effectivement tu créer un lien fort entre ta couche d'accès au données et ton IHM.
Il faut voir ta couche d'accès au données comme une librairie à part que tu appelle à partir de différents projets.

Il faudrait écrire :

Code :

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

Static IEnumerable(of UnObject) GetListFromDB(param1 as object, param2 as object)

et ensuite
- écrire un autre objet qui te ferait la transformation en BindingList
- écrire un autre objet qui te ferait la transformation en ObservableCollection

Une sorte de troisième couche intermédiaire...
Cette troisième couche ne doit pas faire partie de ta librairie d'accès au données car ce n'est pas sa responsabilité et cela créerai ce lien (c'est moins évident mais c'est pourtant encore le cas) que tu cherches à éviter. Je te suggère donc de créer deux autres librairies dont ce serait le rôle d'effectuer la transformation en BindingList pour la première et en ObservableCollection pour la seconde. Cela pourrait être la même qui gère en sortie du BindingList ou du ObservableCollection mais je ne vois pas dans quel cas tu aurais besoin des deux techno pour le même csproj.

[Kropernic]

Hello,

Juste pour être certain qu'il n'y a pas de confusion (vu qu'apparemment, quand on en vient aux histoires de couches, chacun aménage un peu à sa sauce), ma couche d'accès aux données (DAL) renvoie bien une liste. Pas une IEnumerable(Of T) mais juste une List(Of T). Là tout va bien.

Mon problème "philosophique" (car techniquement, ça marche fort bien^^), ce situe au niveau de couche métier (BLL).

EDIT :

Donc oui je pourrais tout à fait ajouter une couche intermédiaire entre la couche graphique/applicative (GUI) et la BLL pour faire la transformation mais ne serait-ce pas là recoder la BLL juste pour une ou deux méthodes ??
Surtout que c'est quand même vachement pratique.

Si on a par exemple une classe de la BLL pour représenter une équipe par exemple.
Elle aurait probablement les propriétés suivantes :

• Name de type String
• Members de type List(of Person)
• ... (d'autres propriétés suivant le contexte)

En créant une instance de cette classe dans la GUI, on peut facilement afficher la liste des membres dans un contrôle de type grille. Et si un élément est ajouté à/retiré de la liste, la modification est automatiquement répercuté sur le composant visuel (d'où le fait que j'utilise 2 types différents suivant le type de projet de la GUI).

Si je crée une couche intermédiaire, toute la logique métier gérant la liste devra être déportée (dupliquée?) dans cette nouvelle couche non ?

[popo]

Le but d'une couche métier est de gérer les règles métiers qui s'appliquent.
A ce niveau là, c'est au bon plaisir de chacun mais en règle général on y retrouve :
- des vérification sur la validité des données avant insertion ou modification
- des filtres sur ce qui doit être visible ou non lors de la sélection
- des contraintes d'intégrité lors de la suppression.

Il n'est normalement pas de la responsabilité de la couche métier de s'adapter à l'IHM.
Donc ta logique métier reste au niveau du métier et la couche intermédiaire de transformation n'est qu'un passe plat qui ne contient pas d'intelligence à l'exception de celle te permettant d'effectuer cette transformation.

En gros ta couche métier continue de gérer ta liste.
La couche de transformation se charge de transformer cette liste (déjà travaillée par ton métier) en quelque chose de compréhensible par l'IHM. Elle va se contenter de faire des Add.

[Noxen]

Hello,
Juste pour être certain qu'il n'y a pas de confusion (vu qu'apparemment, quand on en vient aux histoires de couches, chacun aménage un peu à sa sauce), ma couche d'accès aux données (DAL) renvoie bien une liste. Pas une IEnumerable(Of T) mais juste une List(Of T). Là tout va bien.

IEnumerable<T> est une interface qui décrit un objet qu'il est possible de parcourir de façon itérative et implémentée par l'essentiel des conteneurs du Framework, dont List<T>, ce qui permet de les utiliser avec foreach ou des requêtes LinQ par exemple.

Pour en revenir à ton problème, as-tu besoin d'instancier une collection active dans ta couche métier ? N'est-ce pas suffisant de le faire dans la couche applicative à partir d'une simple liste fournie par le service ? Quel est le besoin de synchronisation que tu as ? As-tu une architecture client-serveur en dehors de la base de données ? S'il faut que toutes les applications soient averties en temps réel des modifications faites sur les données il faudra sûrement un point d'entrée central et une architecture plus lourde qu'une ObservableCollection. Si c'est simplement au sein d'une même application que cette synchronisation est nécessaire tu peux instancier la collection spécifique dans l'application et non dans la couche métier. Au moment d'ajouter un objet en base à travers le service, si l'action réussit on ajoute l'objet à la collection et l'interface est mise à jour.

Pour ce qui est d'utiliser un IEnumerable en retour d'opération de service ma philosophie est qu'il s'agit de données lues, à un instant t, et qui ne devraient pas être modifiées directement dans cette liste ; le service propose d'autres méthodes pour manipuler les données, dont le résultat peut être immédiatement récupéré et l'interface permet limiter l'exposition du type sous-jacent.