p
u
b
l
i
c
i
t
é
publicité
  1. #41
    Membre du Club
    Inscrit en
    octobre 2004
    Messages
    124
    Détails du profil
    Informations personnelles :
    Âge : 31

    Informations forums :
    Inscription : octobre 2004
    Messages : 124
    Points : 61
    Points
    61

    Par défaut

    Le ObjImplements3 est le seul qui sépare données et traitements, l'héritage couple étroitement données et traitements dans les deux premiers exemples.
    Dans l'exemple que tu fournis, cela n'a évidemment aucune importance, mais ramené à l'échelle d'une application, tu retrouves les bénéfices de cette séparation :
    - permettre à deux développeurs de bosser sur des couches différentes
    - ne pas être dépendant d'api techniques qui empêcheraient la réutilisation du modèle métier (ex. créer une méthode qui enregistre/supprime/recherche un client dans l'objet du domaine client lui-même est stupide, car alors la classe Client se retrouverait couplée à une API d'accès aux données => réutilisation difficile dans une autre application)
    - Faciliter la répartition des données et des traitements sur les différents tiers d’une architecture n-tiers
    - + les autres arguments des docs dont les liens ont été fournis ci-dessus...

    @+

  2. #42
    Expert Confirmé Sénior
    Avatar de Immobilis
    Inscrit en
    mars 2004
    Messages
    6 547
    Détails du profil
    Informations forums :
    Inscription : mars 2004
    Messages : 6 547
    Points : 8 119
    Points
    8 119

    Par défaut

    Citation Envoyé par djflex68 Voir le message
    - ne pas être dépendant d'api techniques qui empêcheraient la réutilisation du modèle métier (ex. créer une méthode qui enregistre/supprime/recherche un client dans l'objet du domaine client lui-même est stupide, car alors la classe Client se retrouverait couplée à une API d'accès aux données => réutilisation difficile dans une autre application)
    Me semble etre l'élément le plus important, mais stupide pas forcement. Tout dépend de la taille de l'application.

    A+
    "Winter is coming" (ma nouvelle page d'accueil)

  3. #43
    Membre du Club
    Inscrit en
    octobre 2004
    Messages
    124
    Détails du profil
    Informations personnelles :
    Âge : 31

    Informations forums :
    Inscription : octobre 2004
    Messages : 124
    Points : 61
    Points
    61

    Par défaut

    mais stupide pas forcement. Tout dépend de la taille de l'application
    Tout à fait, stupide n'est pas vraiment le mot qu'il fallait utiliser, disons plutôt qu'il faut éviter de le faire lorsque l'application est suceptible d'être ou de devenir relativement conséquente.

    A ce sujet, même si ce modèle est aujourd'hui largement répandu, il n'est pas non plus exempt de tout défaut (mais en design logiciel, il n'existe pas de solution miracle, tout est affaire de compromis).
    Voir par exemple les remarques émises par Martin Fowler dans sa discussion sur l'anti-pattern "Anemic domain model" (lien wikipedia http://en.wikipedia.org/wiki/Anemic_Domain_Model).
    Tu retrouveras également ici les avantages et inconvénients de cette manière de concevoir une application.

    @+

+ Répondre à la discussion
Cette discussion est résolue.
Page 3 sur 3 PremièrePremière 123

Discussions similaires

  1. [Débutant] Concept de modèle multi-couche
    Par Milyshyn76 dans le forum ASP.NET
    Réponses: 3
    Dernier message: 21/06/2013, 16h15
  2. architecture multi couche avec Linq to SQL
    Par Henry9 dans le forum Débuter
    Réponses: 6
    Dernier message: 17/04/2009, 11h57
  3. Perceptron Multi-couche et descente de gradient
    Par progfou dans le forum Général Algorithmique
    Réponses: 7
    Dernier message: 16/03/2007, 11h41
  4. Hibernate multi couche
    Par BRAUKRIS dans le forum Hibernate
    Réponses: 1
    Dernier message: 27/07/2006, 13h41
  5. Architecture multi couches avec librairie borland?
    Par seb_asm dans le forum JBuilder
    Réponses: 4
    Dernier message: 08/06/2005, 10h14

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