2009-03-27 6 views
3

나는이 질문을 zfforums에 대해서도 물어 봤지만 아마도 여기에서 응답을받을 것이다.젠드 프레임 워크 MVC 디자인

젠드 프레임 워크는 범용적이고 유연하며 느슨하게 결합 된 고품질 프레임 워크입니다. 그러나 일부 MVC 부분은 일관성이없고 지나치게 복잡합니다. 희망이 여러분 중 일부는 ZF의 디자인 결정의 일부를 정당화하고 몇 가지 질문에 대답 할 수

일반적인 질문/의견

  1. 왜 MVC 다른 젠드 구성 요소와 같은 이름 지정 규칙을 따라야 젠드하지 않는 이유는 무엇입니까? 예를 들어, mvc는 소문자를 사용합니다. 복수의 디렉토리 이름과 클래스 이름 앞에는 디렉토리 정보가 없으므로 쉽게로드 할 수 없습니다.

  2. 모듈 루트 디렉토리를 추가하는 옵션을 원합니다. 그렇게하면 컨트롤러/모듈 디렉토리를 추가하여 디스패처를 명시 적으로 구성하지 않아도됩니다. 모듈에 넣고 즉시 액세스 할 수 있습니다.

  3. 왜 뷰 헬퍼와 액션 헬퍼가 다른가요? 현재 헬퍼는 코드 전체에서 공유되도록 설계되지 않았으며 헬퍼를로드하고 액세스하는 일관성없는 메소드가 있습니다. 다른 프레임 워크를 사용하면 코드의 어느 위치에서나 동일한 도우미를 공유 할 수 있습니다. 내가 전문적으로 DRY를 위반할 필요성을 알지 못합니다.

젠드보기

  1. 왜 뷰 리소스에 액세스 할 "이 $"사용하십니까 가지 질문? 여분의 타이핑이 필요하지 않습니다. 일부 다른 프레임 워크는 뷰 변수의 배열을 추출()하고 전역 함수를로드하거나 정적 헬퍼를 뷰에서 불러올 수 있습니다. myHelper :: someMethod();

  2. 왜보기 도우미는 클래스 당 하나의 기능 만 허용합니까? 그 결과 많은 수업과 관련 유지 관리가 이루어집니다. 이미 언급 한 것처럼 많은 수의 메소드로 정적 클래스를 선호합니다.

답변

2

나는 이것들에 대한 모든 대답을 알지 못하지만 흥미로운 질문이므로 찌르 게 될 것이며 누군가가 공백을 채울 수 있습니다. 기본 모듈의 모듈 이름, 예를 들어,로 시작하는

일반

  1. 클래스하지 Admin_IndexController이며/admin/controllers에 있습니다. 필자는 분리 이유와 일관성없는 이름 지정 (라이브러리 클래스와 비교)은 중첩 된 폴더 구조에서이 클래스를 사용하면 거의 이점이 없을 것이라고 생각합니다. 컨트롤러는 구현의 일부이므로 개인적으로는 의미가 있다고 생각합니다. 그러나 폴더를 통과하는 것은 다소 힘들어집니다.

  2. 발송자를 수정하거나 디렉토리를 검색하여 추가 할 수 있습니다.

  3. 확실히 중복되는 부분이 있습니다. URL 도우미가 좋은 예입니다. 일반적으로 뷰 헬퍼는 마크 업을 생성하므로 충분히 큰 차이점이 있다고 생각합니다.

보기

  1. 나는 정확한 이유를 모르지만 나는 그것을 더 쉽게 함께 작동하도록 다른 헬퍼 및보기 기능을 할 수 있습니다 추측에는 요. 예를 들어 doctype 도우미를 사용하여 doctype을 설정 한 경우 양식 요소 도우미가 XHTML 또는 HTML을 적절하게 생성 할 수 있습니다.

  2. 분명히 많은 수업이 있지만 확실히 유지 관리에 대한 확신이 없습니다. 나는 어떤 문제에 굴하지 않았다. 정적 클래스에서 사용하는 것을 볼 수는 있지만 Zend_View를 사용하면 멈추지 않을 것임을 기억하십시오. 포함 경로에 정적 클래스가 있고 (Zend_Loader 또는 유사한 것을 사용하는 경우) View Helpers 대신 또는 View Helpers와 함께 사용할 수 있습니다.

+0

좋은 답변을 보내 주셔서 감사합니다. – rick

+0

일반 질문 # 1에 대한 응답 : 일관성의 이름 (MIT에 따라 4 가지 좋은 코드의 특성 중 하나)에서 컨트롤러 이름은 "Admin_Controllers_Index"로 전환되어야합니다. 디렉터리와 클래스 이름에 대해 단일 "컨트롤러"를 사용하는 것이 더 일관성이 있습니다. – rick

+0

일반적인 질문 # 2에 대한 응답 : 실제로, 기본 표준 디스패처를 확장하여 단일 루트 디렉토리를 사용하고 컨트롤러와 디렉토리가 zf lib 명명 규칙을 따르도록 디스패처를 작성했습니다. zf 융통성을 지키기 위해, 이것은 확실히 플러그 형이며 간단했습니다. – rick

5

거대한 인트라넷 사이트에서 젠드 프레임 워크를 사용하여 미안, 키우면 이후 초기 단계, 0.3 또는 0.4 나는 생각한다, 나는 귀하의 질문에 대한 대부분의 결정을 따랐다. 나는 그들을 조금 설명하려고 노력할 것이다 :

  1. 대부분의 경우 당신은 모듈을 사용할 필요가 없다. application/default 디렉토리에 모든 컨트롤러를 삭제하고 IndexController 또는 HelpController으로 이름을 짓고 완료하면 http://www.domain.com/ 또는 http://www.domain.com/help에 액세스하면됩니다.

    프로젝트 시작이 admin 모듈, index 컨트롤러 http://www.domain.com/admin (멋져요하여 그들을 acessing 모듈 (디렉토리 이름)의 이름으로 Admin_IndexController 또는 Forum_PostController 그들을 접두사, 당신이 원하는대로 당신이 모듈을 추가 할 수 있습니다 성장 가면,하지 default 모듈/admin 컨트롤러).

  2. 예를 들어 modules 디렉토리를 applicatoin/modules으로 설정할 수 있으며 모듈에 대해이 디렉토리를 보도록 FrontController를 구성 할 수 있습니다. addModuleDictory 사용 새 디렉토리를 만들고 view/controllers를 넣을 때마다 디스패처에서 자동으로 검색합니다. Here이 그 예입니다.

  3. 분명히 분명히 다른 목적을 가지고 있습니다. ViewHelpers는 마크 업을 생성하고 다른 액션을 뷰, 메뉴 생성, 사이드 바 등에서 직접 렌더링하는 데 사용됩니다. OTOH ActionHelpers는 디스패치 프로세스와 상호 작용하여 예를 들어 다른 액션으로 리디렉션 할 수 있습니다.

조회 수 beggining에서

  1. 나도 조금 어색하지만, 내가하는 데 사용되었다. 주된 이유는 네임 스페이스를 오염시키는 것이 아니라고 생각합니다. 그런데 나는 extract()의 사용을별로 좋아하지 않지만 그것은 내 개인 취향이다.

  2. 파일 당 컨트롤러를 두 개 이상 가질 수없는 주된 이유는 자동 로딩입니다. $this->someViewHelper()을 사용할 때 기본 엔진은 플러그인 경로에서 *_SomeViewHelper_Helper이라는 클래스를 찾습니다. 또 다른 이유는 정적 클래스가 단위 테스트를하기가 매우 어렵 기 때문입니다. FrontController를 Singleton이 아닌 인스턴스 클래스로 다시 작성하는 제안도 있습니다.

두 번째 단락에서 말하는 지나치게 복잡한 부분에 대해 개발자와 커뮤니티는 알고 있습니다. 모든 요구 사항과 변형을 수용하기 위해서는 이러한 방식이어야합니다.

결국 ZF는 우리가 원하는 것을 할 수있는 자유를주는 매우 견고한 프레임 워크라고 생각합니다.

귀하의 질문을 해결하는 데 도움이되기를 바랍니다.

+0

정말 고마워요. 안개가 들기 시작합니다. – rick

+0

첫 번째 일반적인 질문은 디렉토리 및 클래스 이름 지정에 관한 것이 었으며 여전히 mvc에 대한 협약이 왜 무시되었는지 이해할 수 없습니다. 일관성은 단순하므로 모든 클래스를 쉽게 자동로드하려고합니다. – rick

+0

addModuleDictory()에 빛을 비춰 주셔서 감사합니다. addControllerDirectory()에 대한 별칭이라고 생각했지만 지금은 모듈 모음의 루트에 대한 경로를 제공한다는 것을 이해합니다. – rick