HMVC 및 AJAX 주변의 응용 프로그램 설계 [Kohana 3.2]

Question

현재 몇 페이지가있는 응용 프로그램을 설계하고 있으며 각 페이지에는 AJAX를 통해 업데이트되는 구성 요소가 있습니다. 레이아웃은 '홈', '디스 커버'및 '연결'이 별도의 페이지 인 새로운 트위터 디자인과 유사하지만 페이지 내에서 상호 작용 (예 : '팔로어'또는 '팔로우'클릭)하면 AJAX가 사용됩니다.

AJAX를 통해 개별적으로 업데이트 할 수있는 여러 구성 요소 (트위터 : 트윗, 팔로어, 다음 내용)의 초기 페이지로드가 필요하기 때문에 기본 설정 페이지를 제공하는 컨트롤러 및 기타 컨트롤러는 전체 페이지를 제공하는 대신 데이터베이스 쿼리 및 JSON 개체 반환을 엄격하게 처리합니다. 이렇게하면 초기 페이지로드시 각 구성 요소에 대한 데이터를 수집하기 위해 여러 HMVC 요청을 수행 할 수 있으며 AJAX 호출을 통해 각 구성 요소를 개별적으로 업데이트 할 수 있습니다.

제 아이디어는 제공 페이지를 처리하는 Controller_Default를 갖는 것입니다. 트위터의 맥락에서, Controller_Default이 포함됩니다 : 다음 다른 전체 페이지를 제공과 거래를하지 않는 컨트롤러,하지만 페이지가 아니라 구성 요소를 것

action_home() 
action_connect() 
action_discover() 

. 예를 들어 트위터의 맥락에서 Controller_Tweet은 다음을 가질 수 있습니다.

action_get() 

특정 사용자의 트윗을 포함하는 JSON 객체를 반환합니다. 그런 다음 Action_home()은 여러 가지 HMVC 요청을 만들어 페이지의 여러 구성 요소에 대한 데이터를 가져올 수 있습니다 (즉, '트위터/get', 'followers/get', 'follow/get'). 그러나 페이지에서 AJAX 호출을 콘텐츠 특정 컨트롤러 (즉, 'tweet/get')로 호출하여 콘텐츠를 업데이트 할 수 있습니다.

내 질문 : 좋은 디자인입니까? 페이지 구성 요소가 다른 특정 기능의 컨트롤러를 통해 (JSON 형식으로) 제공되는 상태에서 기본 컨트롤러를 통해 페이지가 제공되는 것이 맞습니까?

질문과 관련하여 혼동이 있으면 명확히 요청하십시오!

Answer 1

HMVC 패턴의 장점 중 하나는이 유형의 계층화 된 응용 프로그램을 사용하더라도 나중에 변경하기 어려운 워크 플로에 잠겨 있지 않다는 것입니다.

위에서 언급 한 내용을 보면 클라이언트에게 콘텐츠를 제공하는 방법으로 완벽하게 수용 될 수 있습니다. 기본 컨트롤러는 동일한 요청을 달성하기 위해 클라이언트에서 여러 AJAX 호출을 피하는 하위 요청을 래핑합니다. 내가 할 수

두 가지 제안 :

1. 가 트위터 백엔드 요청이 응용 프로그램 DRY'er을 만들기 위해 도서관에서 추출되고 관리되어 있는지 확인하고 유지 보수를보다 쉽게 ​​만듭니다.
2. 기본 컨트롤러가 각 요청에 대해 절대적으로 필요한 호출 만 수행하는지 고려하십시오. 캐싱을 사용하여 모든 요청에서 자주 변경되지 않는 데이터를 가져 오지 않도록합니다 (예 : 팔로워는 30 초마다 업데이트 될 수 있음). 이것은 물론 애플리케이션 요구 사항에 달려 있지만,로드가 심하면 Twitter API 요청 제한에 빨리 도달 할 수 있습니다.

마지막 관찰 : 서버 부하가 높고 Twitter API 요청이 돌아 오는 데 시간이 오래 걸리는 경우 다른 서버를 프로비저닝하고 응용 프로그램 복사본을 설치하는 것이 좋습니다.그런 다음 기본 게이트웨이 응용 프로그램의 하위 요청을 두 번째 응용 프로그램 서버로 "가리킬"수 있습니다. 그러면 두 서버가 고속 링크로 연결된 경우 응답 시간이 향상됩니다.