Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 7 sur 7
  1. #1
    Invité régulier
    Inscrit en
    juin 2004
    Messages
    49
    Détails du profil
    Informations forums :
    Inscription : juin 2004
    Messages : 49
    Points : 9
    Points
    9

    Par défaut 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

  2. #2
    Membre chevronné
    Inscrit en
    janvier 2011
    Messages
    264
    Détails du profil
    Informations forums :
    Inscription : janvier 2011
    Messages : 264
    Points : 692
    Points
    692

    Par défaut

    Citation Envoyé par luc2verga Voir le message
    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 Voir le message
    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...)

  3. #3
    Invité régulier
    Inscrit en
    juin 2004
    Messages
    49
    Détails du profil
    Informations forums :
    Inscription : juin 2004
    Messages : 49
    Points : 9
    Points
    9

    Par défaut

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

    Citation Envoyé par Luckyluke34 Voir le message
    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 Voir le message
    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 Voir le message
    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 !

  4. #4
    Membre chevronné
    Inscrit en
    janvier 2011
    Messages
    264
    Détails du profil
    Informations forums :
    Inscription : janvier 2011
    Messages : 264
    Points : 692
    Points
    692

    Par défaut

    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.



    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.

  5. #5
    Invité régulier
    Inscrit en
    juin 2004
    Messages
    49
    Détails du profil
    Informations forums :
    Inscription : juin 2004
    Messages : 49
    Points : 9
    Points
    9

    Par défaut

    Citation Envoyé par Luckyluke34 Voir le message
    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 Voir le message
    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

  6. #6
    Membre chevronné
    Inscrit en
    janvier 2011
    Messages
    264
    Détails du profil
    Informations forums :
    Inscription : janvier 2011
    Messages : 264
    Points : 692
    Points
    692

    Par défaut

    Citation Envoyé par luc2verga Voir le message
    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 Voir le message
    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...)

  7. #7
    Invité régulier
    Inscrit en
    juin 2004
    Messages
    49
    Détails du profil
    Informations forums :
    Inscription : juin 2004
    Messages : 49
    Points : 9
    Points
    9

    Par défaut

    Citation Envoyé par Luckyluke34 Voir le message
    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 !!

+ Répondre à la discussion
Cette discussion est résolue.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •