0

저는 이것을 수행하는 가장 좋은 방법을 알아 내려고하고 있습니다. 코딩 방법이 확실하지 않거나 뭔가 누락되었습니다.MVC 패턴 및 데이터베이스 디자인

Doctrine (1.2)을 사용하고 MVC를 사용하여 내부 팩스 응용 프로그램을 리팩토링하려고합니다. 팩스를 수신하면 목록으로 이동합니다. 그런 다음 사용자는 현재 진행 중이거나 보관 처리되거나 파쇄 된 작업을 선택할 수 있습니다.

가 그 중 하나 선택

, 그것은 다음과 같은 테이블에 항목 삽입 팩스에 대한 워크 플로 작업 생성 : 초기

fax_id | from_status_id | to_status_id | completed | cancelled 

를, 상태가 'unactioned'

status_id을 나타 내기 위해 null의 경우 fax_status 테이블에서 한 행을 찾습니다.

현재는 코드는이

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(); 

} 

처럼 나는 다음과 같은 작업을 수행 할 가지고 나는 또한 대기 팩스 검색 같은 것들의 문제를 찾는거야 모델

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; 

} 

에서 찾습니다 :

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

여기에 문제가 있습니까? 아니면 더 좋은 방법이 있습니까? 난 그냥 코드가 아주 못생긴 것 같아요, 팩스 모델 내의 조회 값을 검색하는 것은 매우 익숙한 것 같습니다. (팩스 작업 흐름 모델로 이동해야합니까?)

상태 값을 하드 코딩하는 것은 매우 유혹적입니다. 모델에 반영되지만 향후 변경 될 경우 문제가 발생할 수 있습니다. 전체

난 그냥 내가 지금까지 알아 낸 경우에 대하여 의견을 찾고 있어요 것은 '올바른'또는 난 내가 해결하려는

+0

해결하려는 문제에 대해 좀 더 정확하게 설명해 주실 수 있습니까? 예, 코드는 추악합니다. 클래스를 분리하고 데이터베이스 항목을 외부에서 숨기려면 "팩스"및 "팩스 워크 플로"를 제외합니다. –

+0

나는 _doctrine_을 모른다. 어쩌면 나의 질문은 바보 같지만 ... 왜 당신은 "from_status_id/to_status_id"로 상태 테이블을 모델링 했습니까? 나는 과거에 상당히 복잡한 상태 전이 시스템에서 일했고 "행동"+ "상태"(예.: "Shred"/ "Completed")보다 자연 스럽습니다. –

+0

@ p.marino 내가 모델을 그렇게 만든 이유는 항목이 여러 번 대기 할 수 있기 때문입니다. 따라서 기록을 제공합니다. 예를 들어, 보관 처리 된 항목이 파쇄 된 항목으로 전달 된 것입니다. 워크 플로 테이블에 세 개의 레코드가 있습니다. –

답변

0

이 경로 아래로 너무 멀리 가기 전에 재 코딩 볼 필요가있는 경우 의견에서 발견 된 두 가지 문제점.

먼저 일반적으로 완료 상태를 모델링하고 다른 상태로 전환하지 않는 것이 더 좋습니다. 예외는 재귀 쿼리를 사용하여 수행 된 경로를 자세히 설명하고 단일 상태에서 다른 여러 상태로 한 번에 전환 할 수있는 그래프를 모델링해야하는 경우입니다. 그렇지 않으면 from_state_idto_state_id 중복으로 얻을 수있는 것이 없습니다. 이벤트가 발생한 시점, 완료된 상태 및 팩스 ID를 추적하기위한 타임 스탬프 필드를 갖는 것이 좋습니다.

두 번째 요점은 트리거를 사용한 감사 자동화에 관한 Matthew Wood의 요점입니다. 내 경험상 두 가지 일이 일어나는 경향이 있는데, 둘 다 매우 훌륭합니다. 첫 번째는 감사가 우회하기 어렵다는 것입니다. 그것이 그가하는 요점입니다. 그러나 두 번째는 감사 트리거가 응용 프로그램의 보안 가정을 ​​우회하지 못하게하는 것입니다. 그러한 가정이 활성화되어있는 경우 트리거가 실패하고 오류가 발생하는 방식으로 위반하면 기록이 중단됩니다.

관련 문제