Ajout de propriété par rapport au Model

Version imprimable

14/02/2012, 09h35
luc2verga

Ajout de propriété par rapport au Model

Bonjour,

J'ai deux classes (POCO) dans mon modèle définies de la manière suivante :
Commande (int ID, DateTime date, List<LigneCommande> lignesCde, etc.)
LigneCommande (int ID, int quantite, etc.).
J'ai également défini les interfaces ICommande et ILigneCommande.

Maintenant au niveau de ma présentation (ou de ma BLL ?), j'ai besoin de rajouter trois attributs (pour gérer l'état de l'objet) : bool estAjoute, bool estModifie, bool estSupprime au niveau de l'ensemble de mes objets du modèle (POCO).

Comment faire cela ?
1. Créer une classe CommandePresentation (int ID, DateTime date, List<LigneCommandePresentation> lignesCde, etc.) ? Mais je vais être obligé de créer une nouvelle classe "Presentation" pour chaque classe du modèle et je vais être obligé de mapper mon objet Commande en CommandePresentation.
2. Créer un décorateur générique (GenericPresentation<T>) mais la problèmatique est la suivante : j'ai une List<LigneCommande> dans la classe Commande et elle ne sera pas "transformée" en LigneCommandePresentation. (j'espère que je suis clair sur cette explication).

Donc comment gérez-vous cela ?

Merci d'avance
Luc
14/02/2012, 18h55
Luckyluke34

Citation:

Envoyé par luc2verga

j'ai besoin de rajouter trois attributs (pour gérer l'état de l'objet) : bool estAjoute, bool estModifie, bool estSupprime au niveau de l'ensemble de mes objets du modèle (POCO).

Quel est le but ? Détecter les changements sur les objets pour lancer les opérations de persistance (INSERT, UPDATE, DELETE...) qui conviennent ensuite ?

La plupart des outils de mapping objet relationnel gèrent déjà cela, est-voulu d'implémenter un change tracker maison ?

Citation:

Envoyé par luc2verga

1. Créer une classe CommandePresentation (int ID, DateTime date, List<LigneCommandePresentation> lignesCde, etc.) ? Mais je vais être obligé de créer une nouvelle classe "Presentation" pour chaque classe du modèle et je vais être obligé de mapper mon objet Commande en CommandePresentation.

C'est une solution fréquemment choisie, on utilise des DTO (ou des objets ViewModel en MVVM) comme objets qui seront affichés dans la couche présentation. Effectivement cela revient souvent à mapper chaque objet de la couche métier en DTO, mais parfois le mapping n'est pas 1 pour 1 (ex : un DTO qui contient des données mixées de plusieurs objets métier...)

La question de devoir reconstituer ou pas toute une grappe d'objets côté présentation est pertinente, souvent on se contente d'avoir un petit graphe de DTO liés les uns aux autres et taillé exactement pour l'affichage à l'écran. Dans l'exemple des lignes de commande, on pourra avoir un DTO Commande relié à toutes ses lignes de commandes mais on va s'arrêter là. Par exemple si sur cet écran on n'affiche pas l'adresse de livraison, on ne va pas trimballer l'objet AdresseLivraison avec. Donc notre DTO Commande n'aura pas de propriété Adresse Livraison.

Sur le mapping lui-même, avant de partir sur l'implémentation from scratch d'un décorateur ou mappeur générique, je regarderais si là aussi un framework n'existe pas (Automapper...)
14/02/2012, 23h57
luc2verga

Merci Luckyluke34 d'avoir pris le temps de me répondre.

Citation:

Envoyé par Luckyluke34

Quel est le but ? Détecter les changements sur les objets pour lancer les opérations de persistance (INSERT, UPDATE, DELETE...) qui conviennent ensuite ?

En fait, je récupère mes données à partir d'une base de données mais pour mettre à jour cette base de données, je ne passe pas par des INSERT, UPDATE, DELETE mais par des WebServices (je requête une base de données d'un ERP). Donc je charge les instances de mon modèle, j'affiche ma winForm, mon utilisateur fait des ajouts, des modifications, des suppressions puis appuie sur le bouton Enregistrer.
A ce moment là, j'utilise l'état de mes instances (estModifie, estSupprime, etc) pour savoir quel WS je dois appeler.
Mais si tu as une autre idée que la gestion de ces "états" au niveau des instances de mon model, je suis preneur !

Citation:

Envoyé par Luckyluke34

La plupart des outils de mapping objet relationnel gèrent déjà cela, est-voulu d'implémenter un change tracker maison ?

De plus, le choix qui a été fait à l'origine sur ce projet est l'utilisation du DataSet (DataTable - TableAdapter). Donc je n'ai hélas pas d'ORM.

Citation:

Envoyé par Luckyluke34

Sur le mapping lui-même, avant de partir sur l'implémentation from scratch d'un décorateur ou mappeur générique, je regarderais si là aussi un framework n'existe pas (Automapper...)

Je vais regarder cela, merci.
Si des personnes passant ici en connaissent, je suis preneur !
15/02/2012, 11h11
Luckyluke34
J'essaierais d'explorer 3 pistes :
- Pattern Unit Of Work à implémenter soi-même ou trouver une implémentation toute faite (sur CodePlex, etc.) Ce pattern permet de découper l'usage de l'application en business transactions qui sont des contextes isolés dans lesquels on place des objets métier dont on va tracer l'état (dirty, new, deleted...). Ensuite à la résolution de la transaction (Save ou Commit) il "suffit" de regarder l'état de chaque objet de la transaction et d'appeler le web service qui va bien en conséquence.
- Entity Framework qui utilise le même pattern. Mais c'est de la grosse artillerie et je manque d'expérience pour dire si c'est vraiment prévu pour persister vers autre chose qu'un SGBD relationnel.
- Explorer les possibilités d'ADO.NET (DataSet, DataTables...) pour gérer le change tracking des objets. Cf http://stackoverflow.com/questions/2...rds-in-dataset
Tout cela afin d'éviter de surcharger les objets métier eux-mêmes avec des propriétés liées au change tracking. En effet en faisant cela on casse la persistence ignorance, on viole Single Responsibility Principle, etc.
15/02/2012, 17h08
luc2verga

Citation:

Envoyé par Luckyluke34

Quel est le but ? Détecter les changements sur les objets pour lancer les opérations de persistance (INSERT, UPDATE, DELETE...) qui conviennent ensuite ?

Ca me permet également de gérer des couleurs au niveau de la présentation.
Si je comprends bien, le change tracking au niveau des outils ORM me permet d'avoir l'information si mon instance est nouvelle ou a été modifiée mais uniquement au niveau de ma couche DAL ou je me trompe ?

J'ai de plus besoin de connaitre l'état de mon objet au niveau de ma BLL, pour savoir si je dois faire certains vérifications. Comment fait-on cela du coup ?

Citation:

Envoyé par Luckyluke34

Tout cela afin d'éviter de surcharger les objets métier eux-mêmes avec des propriétés liées au change tracking. En effet en faisant cela on casse la persistence ignorance, on viole Single Responsibility Principle, etc.

C'est pour cela que je cherche à créer mes DTOs pour gérer ces flags supplémentaires et ne pas les avoir dans mon model :)
16/02/2012, 13h38
Luckyluke34
Citation:

Envoyé par luc2verga

Si je comprends bien, le change tracking au niveau des outils ORM me permet d'avoir l'information si mon instance est nouvelle ou a été modifiée mais uniquement au niveau de ma couche DAL ou je me trompe ?

Non, c'est bien ça.

Citation:

Envoyé par luc2verga

J'ai de plus besoin de connaitre l'état de mon objet au niveau de ma BLL, pour savoir si je dois faire certains vérifications. Comment fait-on cela du coup ?

Si je comprends bien, tu veux pouvoir tracer l'état des objets métier
- Dans la couche UI
- Dans la couche métier
- Dans la DAL
Dans ce cas-là, ça vaut peut-être le coup de garder les mêmes objets entre les différentes couches sans faire de DTO. A voir en fonction du type d'application (si la couche présentation et la couche métier sont sur des tiers différents, ça va être difficile).

Autre solution : dans la couche présentation, se reposer entièrement sur les composants UI pour marquer l'état des éléments. Ex : dans une grille, pour marquer un élément édité d'une couleur particulière, se fier au fait que l'utilisateur ait modifié la ligne plutôt qu'à une propriété particulière de l'objet.
Ca a l'avantage de ne pas devoir se trimballer plein de propriétés relatives à l'état dans chaque objet de la couche présentation. D'autant plus qu'il y a des chances pour que tous les états ne soient pas exploités dans l'UI (typiquement, un objet supprimé va juste disparaitre, on ne va pas le marquer d'une couleur particulière...)
21/02/2012, 14h27
luc2verga

Citation:

Envoyé par Luckyluke34

Dans ce cas-là, ça vaut peut-être le coup de garder les mêmes objets entre les différentes couches sans faire de DTO. A voir en fonction du type d'application (si la couche présentation et la couche métier sont sur des tiers différents, ça va être difficile).

En effet, je pense que je vais conserver les mêmes objets entre mes différentes couches (je suis sur le même tiers). J'ai donc créer une interface pour gérer cela !

Merci en tout cas Luckyluke34 !!