1
데이터베이스에 액세스하는 코드를 넣고 select 요소의 옵션 값을 채우는 데 가장 적합한 장소를 찾으려고합니다. 이 코드를 컨트롤러에 넣는 것은 서투른 것처럼 보인다. 양식에 데이터베이스를 인식시키는 단점은 무엇입니까?Zend_Form의 옵션에 데이터베이스 값을 채우는 것은 누구의 책임입니까?
A
답변
1
데이터베이스를 인식하는 형태의 단점은 위의 경우 Zend_Form과 데이터베이스 액세스 계층이 밀접하게 결합 된 구성 요소를 얻게된다는 단점입니다. 그러나이 2 개에는 공통점이 없어야합니다.
가능한 시나리오를 상상해 : 당신은 다른 하나의 데이터베이스에서 데이터를 이동- . 또는 캐싱 레이어를 맨 위에 추가하려고합니다. 프로젝트 전체에서 db 특정 호출을 수정해야합니다.
- 클래스를 단위 테스트하기로 결정했습니다. 테스트 (또는 그것에 대한 모의)에서 db 연결을 유지해야합니다.
- 다른 장소에서 동일한 양식 클래스를 사용하고 데이터베이스에서 옵션이 아닌 ini 구성 파일에서 선택 항목을 채우려는 경우 ... 아이디어가 있습니다.
그래서 가장 좋은 해결책은 원하는 데이터를 얻을 수있는 db-specific mapper 클래스를 사용하는 것입니다. 그런 다음이 데이터를 양식에 대한 종속성으로 전달하십시오. 그렇게하면 모든 외부 레이어에서 양식을 독립적으로 유지 관리 할 수 있습니다.
양식의 개체를 만들려면 컨트롤러에있는 데이터 소스의 데이터를 전달하십시오.
답장을위한 thx. 여러 가지 선택 옵션을 채우고 유효성 검사 후에도 선택한 값을 개체로 변환하면 매우 뚱뚱한 컨트롤러로 이어지지 않습니까? 이러한 유형의 양식을 사전/사후 처리 형식의 도우미 객체로 옮기는 방법이 있습니까? – blacktie24
예. 다음 단계는 생성 코드를 몇 가지 전용 클래스로 옮기는 것입니다 ([PHP의 팩토리 디자인 패턴이란 무엇입니까?] (http://stackoverflow.com/questions/2083424/what-is-a-factory-design- 패턴 - in - php) 좋은 예를 들어). 검증 된 폼에서 결과 객체를 생성하기 위해 폼과 팩토리를 생성하는 팩토리가 필요할 것이라고 가정합니다. –