Architecture, modelisation et bonne pratique !

Bonjour à tous !

1 . J'utilise une architechture MVC

1. et je j'utilisele design Pattern DAO

je créer un site avec par exemple un utilisteur classic et un autre qui lui est abonner

je suppose que comme class je crée

• User
• UserAbonne (qui herite de la class User)

et je crois que quand on fais du DAO chaque class à son equivalent en table SQL ?

si oui je dois donc créer une table user et userAbonné ?

aussi et toujours du design

admettons que je propose un service payant sur internet et qu'un jour je souhaite faire une promotion quelconque sur ce meme service comment puis je le modeliser ?

dois je créer une class qui represente ce service lié à une base de donnée ou bien as tu une idée sur la façon de le modelisé ?

merci d'avance pour vos précieux conseils !

Salut !

Tu n'es pas obligé de faire une classe par table. Heureusement que l'OO repose sur l'héritage. Tu as deux façons de faire pour gérer la différence entre User et Abonné. La plus simple, c'est de faire un champ "is_suscriber" dans ta table User et de lui affecter la valeur 0 ou 1.

Ensuite dans ta classe User, tu fais tes deux méthodes :

<?php
class User
{
  public function getIsSuscriber()
  {
    return (1 === $this->is_suscriber) ? true : false;
  }
  public function isSuscriber()
  {
    return $this->getIsSuscriber();
  }
  public function setIsSuscriber($v)
  {
    if (1 === $v || true === $v)
    {
      $this->is_suscriber = 1;
    }
    else
    {
      $this->is_suscriber = 0;
    }
  }
}

Ou alors tu fais une classe dérivée qui set automatiquement l'attribut is_suscriber. Puis libre à toi de redéfinir dans UserSuscriber la méthode setIsSuscriber() pour lui faire jeter une exception ou bien de la mettre en "final" dans User pour éviter qu'on puisse la redéfinir dans UserAbonne. Tout dépend si ensuite un SuscriberAbonne peut ou non repasser au statut de User.

<?php
class UserSuscriber extends User
{
  public function __construct()
  {
    parent::setIsSuscriber(true);
    parent::__construct();
  }
  public function setIsSuscriber($v)
  {
    throw new Exception('Unable to set the is_suscriber value for a UserSuscriber object');
  }
}

Par contre, tu peux faire une seconde table dédiée au UserSuscriber à condition que tu aies des infos spécifiques à stocker pour ce type de user. Auquel cas ça devient plus intéressant de séparer les user des user abonnés. Ce qui te permettrait par exemple de faire ce genre d'appels dans ton code :

<?php
$user = UserTable::retrieveByPk(123);
$user->getUserSuscriber()->getNumberOfPurchases();
$user->getUserSuscriber()->getLastPurchase();
$user->getUserSuscriber()->getBirthDate();

En ce qui concerne le service que tu voudrais dévoiler, tout dépend de ce que c'est. De quel genre de service veux-tu réaliser ?

++

Hugo.

hello

merci pour ces infos !

donc ton exemple vaut pour un utilisateur enregistrer c'est vrai qu'il ne servirais à rien de faire une 2 eme table !

par contre si j'avais un utilisateur particulier et un professionnel je pense que je devrais en faire 2?

car le professionnel possède par exemple un numéro de siret, rca ou autre !

en mème temps si je voulais faire remplir une adresse et que je souhaite recevoir une adresse de domicile et ou une addresse de livraison et facturation ?

Pour ce qui est du service et la promotion !

en fait ma questions serait plutôt payez pour acceder à un service !

exemple :

je me s'incrit c'est gratuit mais si je veux acceder à certaine page qui ont plus de possibilité , alors à ce moment la je dois payer !

un peu comme meetic !

et je voudrais savoir comment je peux modeliser ce sytème la !

dans le sens ou si un jour je souhaite faire un promotion voir un truc du genre entre tel date et tel date une promotion de -10% par exemple avec un message pour l'annoncer !

et aussi faire des tarifs forfaitaire du genre si tu veux acceder à ça et bien c'est tant d'euros ! plusieur forfais proposer

devrais je faire une table genre de tarifs avec le titre ou autre ?

que je pourais gérer avec la classe session

c'est des questions un peu bête mais ça m'aide à mieux penser et surement d'eviter des erreur de modelisation !

++ Vini

**Bonjour ! **

en faite je fais une classe de type CRUD par exemple et de cette classe je peux rassembler tous les infos concernant l'utilisateur qu'il soit abonner ou non puis je creer une classe user_aboner qui herite de la class user ou j'insere les méthode propre à user_abonner ?

et je voulais avoir le choix que l'utilisateur peux avoir plusieurs adresse genre domicile, profesionnel et facturation ou livraison...

au niveau de ma structure de bdd dois je rajouter une table ?

car 1utilisateur peux avoir plusieurs adresse ?

j'ai encore un peu de mal entre l'architecture objet et celle de la bdd , je ne sais pas si je dois produire un format similaire du genre chaque table à son equivalent en classe et ce sont les objets qui communique entre eux

merci pour ton aide Emacs

Salut,

Oui tu fais une classe UserAbonne qui contient les propriétés et méthodes spécifiques à ton objet. Quant aux adresses, tu fais une table Address qui contient les informations atomiques d'une adresse (n° rue, rue, code postal, ville, pays... et un flag pour indiquer le type d'adresse).