IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Architecture Discussion :

Ajout de propriété par rapport au Model [Élaboration]


Sujet :

Architecture

  1. #1
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Juin 2004
    Messages
    49
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2004
    Messages : 49
    Points : 34
    Points
    34
    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
    "De tous ceux qui n'ont rien à dire, les plus agréables sont ceux qui se taisent" (Desproges)

  2. #2
    Membre émérite
    Inscrit en
    Janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 917
    Points
    2 917
    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
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Juin 2004
    Messages
    49
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2004
    Messages : 49
    Points : 34
    Points
    34
    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 !
    "De tous ceux qui n'ont rien à dire, les plus agréables sont ceux qui se taisent" (Desproges)

  4. #4
    Membre émérite
    Inscrit en
    Janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 917
    Points
    2 917
    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
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Juin 2004
    Messages
    49
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2004
    Messages : 49
    Points : 34
    Points
    34
    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
    "De tous ceux qui n'ont rien à dire, les plus agréables sont ceux qui se taisent" (Desproges)

  6. #6
    Membre émérite
    Inscrit en
    Janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 917
    Points
    2 917
    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
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Juin 2004
    Messages
    49
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2004
    Messages : 49
    Points : 34
    Points
    34
    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 !!
    "De tous ceux qui n'ont rien à dire, les plus agréables sont ceux qui se taisent" (Desproges)

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

Discussions similaires

  1. [Élaboration] Question d'architecture, ajout de propriété par rapport à la couche Business
    Par Oberown dans le forum Architecture
    Réponses: 7
    Dernier message: 24/11/2011, 18h03
  2. Réponses: 1
    Dernier message: 30/01/2010, 21h25
  3. Réponses: 11
    Dernier message: 27/10/2009, 18h12
  4. Réponses: 5
    Dernier message: 25/06/2007, 12h01

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo