0

J'essaie de trouver la meilleure façon de le faire, je ne sais pas si c'est mon code ou il me manque quelque chose.MVC Pattern & Database Design

J'essaie de refactoriser notre application de fax interne avec doctrine (1.2) et en utilisant MVC - quand un fax est reçu, il va dans une liste. Ensuite, un utilisateur peut choisir des choses à faire avec lui - actuellement en avant, archiver ou déchiqueter.

Quand ils choisissent un de ceux, il génère une action de workflow pour la télécopie qui insère une entrée dans le tableau suivant:

fax_id | from_status_id | to_status_id | completed | cancelled 

Dans un premier temps, l'état est nul pour désigner « unactioned »

status_id recherche une ligne dans la table fax_status.

Actuellement, le code ressemble à ceci

Controller: 

function action_shred($fax_id) 
{ 

    $fax = Doctrine_Core::getTable('fax')->findOneById($fax_id); 

    // error handling for checking it exists and belongs to the user 

    $fax->shred(); 

} 

et dans le modèle

function shred() 
{ 

    $wf = new FaxWorkFlow(); 
    $wf->fax_id = $this->id; 
    $wf->from_status_id = $this->status_id; 
    $wf->to_status_id = Doctrine_Core::getTable('fax_status')->findOneByStatus("Shredded")->id; 
    $wf->completed = 0; 
    $wf->cancelled = 0; 
    $wf->save(); 
    $this->status_id = Doctrine_Core::getTable('fax_status')->findOneByStatus("Queued")->id; 

} 

Je trouve aussi des problèmes avec des choses comme la recherche de télécopies en attente que je dois faire ce qui suit:

$queued_id = Doctrine_Core::getTable('fax_status')->findOneByStatus("Queued")->id; 
$queued_faxes = Doctrine_Core::getTable('fax')->findByStatusId($queued_id); 

Y at-il des problèmes avec cela ou y at-il une meilleure façon de le faire? Je pense juste que le code est très laid, et il semble très hackish pour rechercher la valeur de recherche dans le modèle de fax (devrait-il être déplacé dans le modèle faxworkflow?)

Il est très tentant de coder en dur les valeurs d'état dans le modèle, mais si elles changent à l'avenir, cela causerait des problèmes.

dans l'ensemble je suis à la recherche d'une opinion sur si ce que j'ai jusqu'à présent est « correct » ou si je dois regarder recodage avant d'aller trop loin dans cette voie

+0

Pouvez-vous être un peu plus précis sur les problèmes que vous tentez de résoudre? Oui, le code est moche - je prendrais en compte "fax" et "fax workflow" pour séparer les classes et cacher les choses de la base de données de l'extérieur. –

+0

Je ne connais pas _doctrine_ alors peut-être que ma question est idiote mais ... pourquoi avez-vous modélisé votre table d'état comme "from_status_id/to_status_id"? Dans le passé, j'ai travaillé sur des systèmes de transition d'état assez complexes, et pour moi, j'ai "l'action" + "statut" (par ex.: "Shred"/"Completed") se sent plus naturel. –

+0

@ p.marino la raison pour laquelle je l'ai modélisé de cette façon est parce qu'un élément peut être mis en file d'attente plusieurs fois, donc il fournit un historique - par exemple, il est passé de archivé à transmis à déchiqueté. c'est trois enregistrements dans la table de flux de travail –

Répondre

0

Je veux aborder deux problèmes trouvés dans les commentaires. Premièrement, il est généralement préférable de modéliser l'état complet, et non la transition d'un état à l'autre. L'exception est lorsque vous avez besoin de modéliser des graphiques avec des requêtes récursives détaillant les chemins qui ont été empruntés, et que vous pouvez passer d'un état unique à plusieurs autres états à la fois. Sinon, il n'y a rien à gagner avec la duplication from_state_id et to_state_id. il serait préférable d'avoir un champ d'horodatage pour suivre quand un événement s'est produit, l'état a été complété et l'identifiant de fax.

Le deuxième point est le point de Matthew Wood sur l'automatisation de l'audit à l'aide de déclencheurs. Dans mon expérience, cela a tendance à provoquer deux choses qui sont très bonnes. Le premier est que l'audit est plus difficile à contourner. C'est le point qu'il est en train de faire. La deuxième est cependant qu'il est plus difficile de contourner les hypothèses de sécurité de votre application dans la mesure où vos déclencheurs d'audit en dépendent. Si vous avez de telles suppositions actives, si vous les violez de telle sorte que le déclencheur échoue et génère une erreur, vos écritures seront annulées.