Discussion :

[Royd938]

Bonjour à tous,

Voilà j'ai un petit problème de conception assez basique dans le cadre d'une architecture 3-tiers.

Admettons que mon application manipule des objets Contact (id, nom, prenom, adresse, age). En respectant le principe 3-tiers, j'ai une classe ContactDAO qui gère l'ajout et la suppression de Contact dans la table contact d'une DB. J'ai également une classe ContactManager qui gère la création, l'ajout et la suppression de Contacts en faisant appel à la couche données.

Jusque là ok. Prenons maintenant le cas d'un ajout de Contact. Les différentes données du contact sont rentrées par le user mais l'ID du contact ne dépend pas du User... A quelle niveau cette ID doit être créé? au niveau métier ou au niveau donnée lors de l'insertion dans la table contact. Car admettons que mon application permette à l'utilisateur de créer plusieurs Contact en mémoire avant des les insérer tous dans la table, comment dois-je procéder dans ce cas... et où dois-je stocker ces différent contact en mémoire? Au niveau de ma classe ContactManager ?
Une dernière petite question... Lors de l'insertion d'un nouveau Contact, qui va se charger de vérifier le fait que le contact existe déjà dans la DB. La couche métier ou la couche données ???

J'espère me faire comprendre...

Merci d'avance pour votre aide...

[JMLJ]

> A quelle niveau cette ID doit être créé? au niveau métier ou au niveau donnée lors de l'insertion dans la table contact.

Moi je dirai au niveau donnée. De toute façon ce numéro d'id dans ton cas est semble-t-il automatique (autoincrément) ?

> Car admettons que mon application permette à l'utilisateur de créer
> plusieurs Contact en mémoire avant des les insérer tous dans la table, > comment dois-je procéder dans ce cas... et où dois-je stocker ces
> différent contact en mémoire? Au niveau de ma classe
> ContactManager ?

Tu te retrouves avec une collection d'objet Contact que ton ContactManager va persister à travers ta couche DAO. Non ?

> Une dernière petite question... Lors de l'insertion d'un nouveau Contact,
> qui va se charger de vérifier le fait que le contact existe déjà dans la
> DB. La couche métier ou la couche données ???

Vu qu'apparemment tu ne gères pas toi même tes clés unique (autoincrément), ta BD ne va pas t'allerter. A mon avis à toi de créer les bons contrôles à travers tes couches pour demander à la couche DAO de vérifier si le Contact existe ou non.

Le risque est qu'entre le moment où tu as fais ce test et celui ou le système va réellement écrire l'enregistrement dans la base qu'un autre utilisateur essaye de créer ce même contact Si ton SGBD te le permet tu auras posé une index non duplicable sur le Nom de ton Contact, une exception sera levée et la transaction "Roolbacké" ...

Tout ça reste théorique, attends quelques moi avant que je le mettes en pratique

Jean-Marc

[BizuR]

Je vais egalement tenter de répondre à ces questions en mettant en avant une expérience similaire d'un projet que j'ai eu a realiser ...

Les id doivent être générées au niveau ou tu l'utilises ... je m'explique ... si jamais dans ton application, tu manipules les identifiants au niveau logique applicative (LA), tu devra alors les créer dans ton ContactManager, par contre, si elle ne te sont d'aucune utilité (ce qui etait mon cas) je les créait automatiquement dans la base (le fameux autoincrement dont parle JMLJ)

Pour les stockages temporaires avant enregistrement, cela releve évidemment de ta methode de traitements, si tu dois chargé les contact ... ou les stocke tu ? normalement si tu veux conserver une independance de tes couches LA et Données, il faut aller charger les données en LA , stocker temporairement ces données toujours en LA, et enregistrer le tout en passant par la couche Données ...

Donc comme JMLJ l'avez tout deux dit: on les stocke dans le ContactManager (avec une collection quelconque)

Enfin pour l'insertion ... les l'emplacement des controles dépendent de type... si c'est un
controle de saisie -> IHM
controle de doublons -> LA
controle de cles (si tu la generes toi même) -> Donnees

Après je ne rentre pas dans les details aussi poussés que JMLJ puisque mon appli etait mono utilisateur ... (ca restait un projet)
Bonne chance a toi ^^

[Royd938]

OK merci à toi pour ta réponse...