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

Design Patterns Discussion :

Design Pattern d'historisation (trace/log)?


Sujet :

Design Patterns

  1. #1
    Membre averti
    Profil pro
    Inscrit en
    Décembre 2004
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2004
    Messages : 28
    Par défaut Design Pattern d'historisation (trace/log)?
    Bonjour à tous,

    Je dois créer un design prenant en compte une notion forte d'historisation. Je m'explique :
    Pour un sous ensemble de mon modèle métier (environ une dizaine de classe), contenant des classes héritées, des aggrégations, ... Je dois pouvoir lors de tout changement garder une trace de l'état de ce sous système à un instant x.
    Le besoin est d'avoir une traçabilité complète de l'évolution de ces classes.

    Est-ce que cela vous ferez penser à un design pattern?

    Le problème est à la fois lié à la compléxité de restituer l'ingralité des modifications mais également à la taille des enregistrements que cela risque de provoquer.

    Merci pour tout idée,

  2. #2
    Membre émérite

    Profil pro
    Inscrit en
    Février 2004
    Messages
    862
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : Suisse

    Informations forums :
    Inscription : Février 2004
    Messages : 862
    Par défaut
    Citation Envoyé par MLK jr Voir le message
    Le problème est à la fois lié à la compléxité de restituer l'ingralité des modifications mais également à la taille des enregistrements que cela risque de provoquer.
    Pour éviter ce problème de taille, on ne conserve pas un "snapshot" du système complet, mais un historique des modifications sous forme de log.

    Le Pattern "Command" est un bon départ pour de tels systèmes, et de manière plus spécifique, fait une recherche d'implémentations de mécanismes d'UNDO/REDO, de nombreux exemples sont facilement trouvables en Java ou en C#.

  3. #3
    Expert éminent
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    Juin 2008
    Messages
    21 741
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2008
    Messages : 21 741
    Par défaut
    Bien que je ne voie pas comment se passer du pattern "command" pour implémenter cela, ce comportement relève plutôt du pattern "memento".
    Après la question est persistance ou pas?
    - W
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  4. #4
    Membre émérite

    Profil pro
    Inscrit en
    Février 2004
    Messages
    862
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : Suisse

    Informations forums :
    Inscription : Février 2004
    Messages : 862
    Par défaut
    Citation Envoyé par wiztricks Voir le message
    Bien que je ne voie pas comment se passer du pattern "command" pour implémenter cela, ce comportement relève plutôt du pattern "memento".
    En fait, non.

    Le pattern Memento pourrait paraître un meilleur candidat, mais en pratique la pattern Command est beaucoup mieux adapté à ce cas de gestion d'historique.

    En admettant que tu étendes le pattern memento pour gérer un historique d'états, tu restes quand même dans un mode "snapshot"...A chaque modification tu dois générer des sauvegardes des objets complets ! Par ailleurs, en utilisant memento il va être très difficile de savoir dans quel ordre il faut réinjecter les mementos pour retrouver l'état du système à un instant T.

    Avec le pattern Command, tout ce dont tu as besoin est un snapshop de l'état d'origine du système. Ensuite tu peux facilement défaire/refaire n'importe quelle opération et retrouver l'état exact à un moment exact.

  5. #5
    wazup
    Invité(e)
    Par défaut
    A priori, la pertinence de l'utilisation du DP memento (en combinaison avec Command) peut s'avérer utile.

    Tout dépend de l'atomicité des changements qui peuvent survenir.

    Je m'explique :

    Si tu a un objet persistant qui contient n membres, et qu'au cours d'une même operation (transaction), entre 1 et n membres peuvent avoir changé, alors il est peut-etre utile d'injecter du "memento".

    Je ne sais pas si je me fait bien comprendre.

Discussions similaires

  1. Réponses: 4
    Dernier message: 24/02/2009, 12h06
  2. [VS.NET] Les design pattern et DOTNET
    Par Nycos62 dans le forum Visual Studio
    Réponses: 4
    Dernier message: 22/10/2004, 14h44
  3. [Observateur] Précisions sur le design pattern Observer [UML]
    Par joquetino dans le forum Design Patterns
    Réponses: 2
    Dernier message: 07/10/2004, 22h35
  4. Les Designs Patterns Entreprise
    Par boulon dans le forum Design Patterns
    Réponses: 4
    Dernier message: 01/09/2004, 19h16
  5. [Design Patterns] Architecture 3 tiers
    Par HPJ dans le forum Design Patterns
    Réponses: 1
    Dernier message: 29/07/2003, 11h49

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