2011-08-10 1 views
1

J'ai un site Web que je convertis en Codeigniter et je veux simplifier et découpler. J'aime ce que j'ai lu sur le pattern Observer pour des choses comme "new survey created" (qui déclenche un nouveau ticket d'aide, qui déclenche un email, etc). Mais comment implémenter une telle chose dans Code Igniter? Je vois le composant Symfony mais à ce stade je ne suis pas concerné par la compréhension du système autant que par la façon de l'utiliser dans les contrôleurs et les modèles. J'ai déjà étendu CI_Model et CI_Controller pour d'autres raisons. Le code pattern Observer serait-il le meilleur?en utilisant le modèle Observateur avec un site Web MVC/Codeigniter

j'imagine un point comme celui-ci: quelqu'un frappe le site Web et génère une demande qui est acheminé vers un contrôleur/action: http://localhost/test/save_changes

// warning, pseudo-code! 

class Test extends MY_Model 
{ 
    public function __construct() 
    { 
     // do I put this here?!? - or maybe in MY_Model? 
     // Should it be a singleton? 
     $this->load->library('dispatcher'); 
     // where do I attach what I want... here? 
     $this->load->library('emailer'); 
     $this->dispatcher->attach($this->emailer); 
     // what if I have 50 possible things that might happen 
     // based on any given event, from adding a user to 
     // deleting a survey or document? There has got to be a 
     // way to attach a bunch of observers that trickle 
     // down to each object, right? 
    } 

    public function save_changes() 
    { 
     $this->load->model('user'); 
     $this->user->init($this->session->userdata('user.id'))->save();    
    } 
} 



class User extends MY_Model 
{ 
    public function __construct() 
    { 
     parent::__construct(); 
     // do I put this here?!? 
     $this->load->library('dispatcher'); // just something to call it 
    } 

    public function init($id) 
    { 
     if($this->_loadUser ($id)) 
     { 
      $this->dispatcher->notify($this, 'user.loaded'); 
     } 
    } 

    public function save($id) 
    { 
     if(parent::save()) 
     { 
      $this->dispatcher->notify($this, 'user.saved'); 
     } 
    } 



} 

class Emailer 
{ 
    public function update ($caller,$msg) 
    { 
     switch ($msg) 
     { 
      case 'user.saved': 
     // send user an email 
     // re-cache some stuff 
     // other things that we might want to do, including more of these: 
     $this->dispatch->notify('user-saved-email-sent'); 
      break; 
     } 
    } 
} 

class Dispatcher 
{ 
    public function notify ($caller, $msg) { ...foreach attached do $obj->update($caller,$msg) ...} 
    public function attach ($obj) { ... } 
    public function detach ($obj) { ... } 
} 

Je peux voir la puissance qui serait. Mais je ne suis pas sûr de savoir comment simplifier la configuration et l'attachement de tous ces auditeurs/observateurs.

Peut-être que je devrais avoir une usine pour les créer tous? Il semble juste que oui, ils seraient découplés de la façon dont cela fonctionne actuellement, mais il semble que la gestion de tous les différents objets que je devrais «attacher» dans chaque contrôleur ou méthode serait couplée d'une manière différente.

Merci, Hans

Répondre

0

Votre __gVirt_NP_NN_NNPS<__ structure proposée devraient être quelque chose comme:

$this->load->library('observer_factory', 'of'); // factory for creating observers 
// Observer_factory would have knowledge/access to different classes which relate 
// to the pattern. 
$ync = $this->of->getNotifier($some_variable)); 
$ync->attach($this->of->getObserver($some_other_variable)); 
$ync->attach($this->of->getObserver($some_final_variable)); 

$ync->someMethod(); // someMethod calls notify 

Mais je me demande à ce sujet. Vous auriez une classe d'usine qui devient lentement tout savoir. Il commence à usurper la fonctionnalité du chargeur. Pourquoi charger une bibliothèque quand mon Observer_factory peut le faire en faisant exactement la même chose?

Je pense que vous êtes mieux avec une bibliothèque ou un modèle qui sait ce qu'il est censé faire et est bien conçu, puis en ajoutant cette structure de classe. Je ne vois pas les gains l'emporter sur les coûts.

+0

Ouais, j'aime l'idée d'un noyau d'application qui pourrait diriger tous ces événements, mais en réalité, je ne pense pas que ça va être aussi facile. J'ai pensé à suivre le chemin de la méthode statique et j'ai essayé de savoir comment Kohana le faisait (mais je n'ai pas encore eu le temps de regarder en détail) – Hans

+0

On dirait que Kohana l'a sorti de 3.0. Hmm. Devinez qui signifie qu'ils pensaient que ça ne marchait pas bien? Les gens le soutiennent encore, en tant que classe statique, mais ce n'est plus un module de base. – Hans

Questions connexes