MVC 프레임워크를 통한 Ajax 요청(예:ColdBox)인가요?

Question

선택한 MVC 프레임워크를 통해 Ajax 요청을 실행합니까, 아니면 CFC로 직접 실행합니까?

Ajax 요청에서 'View'가 필요하지 않기 때문에 MVC를 우회하는 쪽으로 기울고 있습니다.

Coldbox와 같은 MVC 프레임워크를 통해 Ajax 호출을 라우팅하는 전문가는 무엇입니까?

업데이트:이 페이지를 찾았습니다 http://ortus.svnrepository.com/coldbox/trac.cgi/wiki/cbAjaxHints 하지만 나는 그것이 초래하는 복잡성보다 어떤 이점을 가져다 주는지에 대해 여전히 마음을 포장하려고 노력하고 있습니다.

Answer 1

Henry, 나는 내 모델의 대중 개체에 대한 ajax 요청을한다. 일반적으로 나는 그렇게 할 때 '프레임 워크'를 벗어납니다. 즉, 설정된 보안 모델 내에서 작업하는 것과 같이 프레임 워크를 활용해야 할 수도 있습니다.

Answer 2

나는 MVC 프레임 워크를 우회한다는 이점을 실제로 볼 수 없다 -이 세 가지 요소는 ~이다 너의 어플리케이션.

Ajax 요소는 실제로보기의 일부입니다. Luca가 말했듯이보기는 모델 및 컨트롤러의 결과를 출력합니다.

이런 식으로보십시오 - iPhone 친화적 인 웹 인터페이스 (즉, 새로운보기)를 만들었다면 모델과 컨트롤러를 우회 하시겠습니까?

Answer 3

Coldbox의 제작자 인 Luis Majano 말했다:

이들은 Ajax 상호 작용 Henry의 두 학교입니다.

프록시 접근법은 다음을 추가하기 때문에 선호합니다.

1. 디버깅
2. 디버거 추적
3. AOP 차단 지점
4. 보안
5. 가용성 설정
6. 프록시는 이벤트 모델로 전달되므로 로컬 인터셉트 포인트, 로컬 AOP, 플러그인 등을 사용할 수 있습니다.

다시 말해, 간단한 서비스 CFC 호출 대신 고도로 모니터링 된 통화 일 수 있습니다.

하나는 실행 프로파일 러 (Coldbox Debugger의 일부)를 실행하는 것을 좋아하므로 Ajax 요청이 들어올 때와 나올 때를 확인할 수 있습니다. 요청 된 데이터와 데이터가 다시 전송되는 것을 볼 수 있습니다. 로그 파일을 보거나 결과 나 문제를 상상하려고 할 필요가 없습니다. 디버깅에 실제로 도움이됩니다.

그러나 그것은 당신이 가기로 결정한 개발자 선택이 될 것입니다. 저의 개인적인 취향은 항상 대리를 사용하여 이벤트 대표단을 사용하는 것입니다.

Answer 4

MVC 프레임워크에서 "뷰"의 목적은 다음과 같습니다. 보여주다 "모델"과 "컨트롤러"가 생성한 이후의 데이터입니다."뷰"가 필요하지 않다면 그러한 디자인 패턴을 사용하는 이유는 무엇입니까?

Answer 5

나는 루카에 동의합니다. 또한 MC 스택에있는 모든 종류의 소독 및 필터링 로직을 우회합니다. 기본적으로 귀하가 할 수도 있고 없을 수도있는 모든 종류의 쿼리 처리를 무효화합니다.

Answer 6

예, 나는 당신의 프레임 워크를 우회하지 않고, 당신에게 슬픔의 원인을 파악하고, 불쾌한 조각을 사냥하고, 헤더 나 바닥 글과 같은 일반적인 구성 요소를 배제하기 위해 논리를 추가하고, HTML에 대해 잘 어울리는 곳을 주입하는 방법을 찾고 있습니다. JSON을 구문 분석 할 때 올바른 문제가 있습니다.

output = "false"추가 Application.cfc에서 특히 정리 한 메소드가됩니다.

나는 CFC의 직접적으로 직접 액세스하지 않는다는 강한 신자이며, 주요 리팩토러가 구성 요소를 통합하거나 제거하려고 할 때 장기적인 문제를 일으킨다는 것을 알았습니다. 직접 액세스는 특히 제 3자가이를 더 어렵게 만듭니다. 다른 도메인에서 ajax를칩니다 (예 : 플래시 리모 팅).

스티브의 대답에 +1.