AJAX 응용 프로그램을 설계 할 때 권장되는 방법

Question

이것은 꽤 일반적인 질문이지만 Flex를 사용하여 몇 년 동안 보았습니다. 순수 웹 개발에 익숙하지 않았습니다.

내 질문은 : 당신이 AJAX 응용 프로그램을 구축해야하는 경우 두 가지 방법 중 어느 하나는 당신이 선호하는 것 : 컨트롤러가 모델 데이터와 함께 제공되는 뷰를 돌려

1. 고전 서버 측 MVC를. 뷰는 본격적이거나 부분적 일 수 있습니다. 기본적으로 콘테이너로 작동하는 본격적인 뷰는 소수에 불과하며 자바 스크립트는 부분 HTML 뷰를 비동기 적으로 채우는 데 도움이됩니다. 이 접근법은 자바 스크립트가 전반적인 제어 및 사용자 상호 작용을 유지하기 위해서만 사용되므로 기존 웹 개발을 한 단계 발전시킨 것입니다.

2. 카푸치노, 스프 라우트 코어 또는 Backbone.js로 제작 된 것과 같은 본격적인 js 앱 여기서 클라이언트 측은 두꺼우 며 모델을 처리하고 logi를 제어하며 상호 작용을 보는 MVC의 클라이언트 측 구현을 구현합니다. 이 경우 서버 측은 클라이언트가 데이터를 교환하는 JSON/XML 서비스 세트 역할을합니다. 이 경우의 단점은 초기 애플리케이션이 부트 스트랩 될 때 뷰 템플릿을 처음에로드해야하므로 자바 스크립트가 데이터를 기반으로 마크 업을 레이아웃 할 수 있다는 것입니다. 이점은 서버 응답의 가중치가 줄어들고 클라이언트 내에서 더 나은 제어가 가능해 지므로 뷰 모델 바인딩과 같은 요소가 적용될 수 있습니다.

3. 이 둘 사이에는 다소 혼합 된 접근법이 있습니다.

내가 비슷한 환경에서 제공하기 때문에, 정상적인 두 번째를 선호하고 있지만 (우리가 플래시에 전화 또는 딥 링크) 등의 URL 라우팅 등의 문제에 대해 내가 주로 관심이 그 하나 , 상태 관리, 모듈화 및 뷰 레이아웃 (뷰 마크 업 템플리트는 언제로드됩니까? 템플리트 데이터가 처음에로드되지 않도록 해당 템플리트를 제공하는 특정 서버 엔드 포인트가 있어야합니까?)

제발, 의견

Answer 1

두 번째 방법을 권장합니다. 이미 익숙한 두 번째 접근법 (씬 클라이언트 씬 서버 접근법)은 클라이언트에서 위젯의 렌더링과 관리가 이루어지기 때문에 점점 더 많은 수의 현대 개발자가 선호하는 접근 방식입니다. 따라서 서버에서 계산 및 대역폭 오버 헤드가 절약됩니다. 복잡한 위젯 관리가있는 경우 위젯 용 서버 측 코드를 사용하면 점점 복잡해지고 관리하기 어려워 질 수 있습니다. 당신 가리키는 단점 : 자바 스크립트 데이터를 기반 마크 업 레이아웃 할 수 있도록

뷰 템플릿을 가지고는, 초기 응용 프로그램이 부트 스트랩 시작 부분에로드 할 수 있습니다.

이 올바르지 않습니다. ajax를 통해 필요에 따라 정적 템플릿을 즉시로드하고 자바 스크립트를 사용하여 전체 위젯에 렌더링 할 수 있습니다. 예를 들어 이미지 편집기 구성 요소가있는 imagegallery가있는 경우 사용자가 실제로 이미지를 편집 할 때까지 이미지 편집기 (이미지, 템플릿 및 위젯 렌더링 코드 포함)에 필요한 파일을로드하지 못할 수 있습니다.

스크립트 로더 사용 (예 :requirejs, labjs) 처음에는 중소 규모의 부트 스트랩 스크립트 만로드 한 다음 요구 사항에 따라 나머지 스크립트를 동적으로로드 할 수 있습니다.

또한 강력하고 성숙한 서버 측 위젯 라이브러리는 Java 백엔드 (예 : vaadin)에서만 사용할 수 있습니다. PHP, 파이썬 또는 루비 백엔드에서 작업하는 경우 자체 서버 측 UI 프레임 워크를 작성하는 것은 과도한 과잉 작업이 될 수 있습니다. 예를 들어, 클라이언트 측 서버 - agonistic javascript UI 프레임 워크를 사용하는 것이 훨씬 더 편리합니다. 도장, qooxdoo 등

당신은 클라이언트 쪽 mvc 프레임 워크쪽으로 향한 경향이 보인다. 이것은 좋은 접근 방법이지만 (클라이언트와 마찬가지로 서버에서도) 이중 mvc 아키텍처는 종종 코드 중복 및 혼란을 야기하는 경향이 있습니다. 이런 이유로 나는 혼합 된 접근법을 추천하지 않을 것이다.

프론트 엔드에는 적절한 mvc 프레임 워크가 있고 안락한 API를 통해 응용 프로그램과 상호 작용하는 서버 측 모델 계층 만 사용할 수 있습니다 (기울어 진 경우에는 rpc).

flex 배경에서 왔기 때문에 Ajax.org ui 플랫폼 http://ui.ajax.org을 확인하시기 바랍니다. 사용자 인터페이스 프레임 워크는 플렉스와 같은 태그 기반이며 프로젝트가 새롭지 만 강력한 위젯 세트와 매우 인상적인 차트 및 데이터 바인딩 솔루션을 갖추고 있습니다. Dojo 및 Ample SDK는 태그 기반 위젯 레이아웃 시스템을 채택합니다.

Qooxdoo와 extjs는 레이아웃과 렌더링에서 자바 스크립트를 통해 모든 일을 옹호하며 이는 사용자에게 불편할 수 있습니다.

Answer 2

나는 자신을 # 2 선호하지만 자바 스크립트를 발굴했습니다.

불행하게도 플렉스 코드가 어떤 모습인지 전혀 보지 못했습니다. 내 경험으로는 레일을 사용하기 때문에 이러한 용어로 이야기하겠습니다.하지만 개념이 보편적으로 충분하므로 대답이 의미가 있습니다.

클라이언트 측 템플릿은 서버 측 플랫폼에 스토리가있는 것이 가장 좋습니다 그것을 위해 (예 : 레일 3.1 자산 파이프 라인이나 jammit plugin for pre 3.1). 레일을 사용하고 있다면 더 많은 정보를 제공 할 수 있습니다.하지만 내가 할 수있는 첫 번째 일이 아니라면이 상자를 처리하는 자산 관리 시스템을 찾아야합니다.

내 대체 당신이 (JQuery와 구문) 같은

var template = $('#foo-template').html(); 

을 할 수있는 문자열 나중에 검색하려면

<script type='text/html' id='foo-template'></script> 

같은 스크립트 태그 안에 내 서버 측 템플릿에 바로 내장 템플릿에 일반적으로 내 서버 측 템플릿에서

, 나는 부분 지문으로 자신의 파일에 그 스크립트 태그를 가져옵니다, 그래서 여전히 파일 분리를 얻을

<%= render :partial => 'templates/foo.html.erb' %> 

(구문 레일)

나는 jammit을 사용하는 편이 더 좋으며 클라이언트 측 템플릿을 .jst로 끝나는 별도의 파일로 템플리트하는 것이 더 좋지만 두 번째 방법은 어느 곳에서나 작동하며 대부분 동일한 이점을 얻습니다.

Answer 3

나는 동시에 20,000 명이 온라인에있는 100,000 명의 사용자를 가진 하나의 모바일 웹 응용 프로그램을 설계 한 사람입니다.

그런 종류의 애플리케이션 (예 : 제한된 대역폭)에서는 # 2가 내가 생각하는 유일한 옵션입니다.

그래서 서버 쪽은 단지 데이터 서비스 집합이며 클라이언트는 순수한 AJAX RPC를 사용합니다. 여기서는 모든 것을 포함하는 단일 정적 index.htm 파일을 사용합니다. 또한 HTML5 매니페스트를 사용하여 시작시 스크립트/스타일/이미지에 대한 서버 왕복 횟수를 줄입니다. 앱 상태 지속성 및 캐싱을 위해 localStorage를 사용합니다.

MVC 현재 : are many template engines out there이므로 가장 편리한 것을 사용할 수 있습니다. 자체적으로 템플릿은 데이터가 포함되어 있지 않기 때문에 매우 컴팩트하므로 모든 템플릿을 포함시키는 것이 좋습니다 (우리의 경우).

예. 이러한 응용 프로그램의 아키텍처는 선행을 고려해야합니다. # 1 옵션은 그리 중요하지 않습니다. 엔트리 레벨이 낮습니다.

내가 타겟팅하는 플랫폼을 알 수는 없지만 # 2는 아마도 모바일 전용 옵션입니다.