2011-01-18 3 views
5

나는 Render가되는 백엔드로 Sencha Touch에서 모바일 애플리케이션을 프로그래밍하고 있습니다. 나는 Sencha에 대해 좀더 깊어지면서 점점 더 두 가지를 분리 해왔음을 발견했습니다. 기본적으로 Rails는 모델 저장소 (데이터베이스)로만 작동하고 Sencha는 JSON을 통해 필요한 모든 것을 가져옵니다. 대부분의 논리는 이미 레일에 존재합니다.Sencha Touch와 Rails (백엔드) 간의 사용자/세션 관리

내 질문에, 각 응용 프로그램에 기능을 위임 할 때 어떤 조언을합니까? 내 Sencha 응용 프로그램에서 REST를 구현하여 사용자 및 관련 데이터를 전달하고 동일한 형식으로 저장할 수 있습니다.

사용자 세션 관리에 적합한 방법인가요? 레일에 더 많은 전력을 공급해야합니까? IE : 세션은 어디에 저장합니까? 서버에서 할 수 있습니까? 세션 저장소 관리로해야합니까? 로컬 저장소? 나는 단지 모른다.

나는 조언을 주시면 감사하겠습니다. 감사.

답변

7

이것은 정확히 귀하의 질문에 대한 구체적인 대답은 아니지만, 나는 당신이 옳은 길에 있다고 생각한다고 덧붙이고 싶습니다. 건축 선을 넘어 섰다고 걱정하지 않을 것입니다. 말하자면.

웹은 브라우저와 서버가보다 대칭적인 동료 인 렌더링 된 문서 (서버가 절대적으로 모든 것을 수행하고 브라우저가 본질적으로 바보였던 곳)에서 진행되고 있습니다. 그리고 두 가지 본격적인 동기화 된 MVC 앱!

(아마도 클라이언트 측 응용 프로그램의 풍부함과 관련하여 서버가 상당히 바보가되는 세상을 볼 수 있습니다.) 이것은 두꺼운 클라이언트/씬 클라이언트 진자의 다음 사이클 일 것입니다. 수십 년 동안 흔들림 ;-))

모바일의 경우 이는 모바일 컴퓨터가 부분적으로 또는 산발적 인 네트워크 범위를 쉽게 가질 수 있으므로 임의의 컴퓨터 과학 문제가 아닙니다. 따라서 응용 프로그램 디자인의 궁극적 인 테스트는 해결해야합니다. 예를 들어 기기가 오프라인 상태 일 때 사용자가 앱에서 계속 작업 할 수 있는지 여부를 터널로 유도 한 다음 네트워크를 다시 사용할 수있게되면 다시 동기화합니다. 풍부하고 반응이 좋은 클라이언트가 실제로 유일한 방법입니다.

브라우저에서 세션을 풍부하게 저장하는 것이 합당한 단계처럼 보입니다. 사실, 여러 클라이언트가 동시에 조작 할 수있는 다른 유형의 데이터 레코드보다 단일 클라이언트와 서버간에 세션 상태를 동기화하는 것이 더 쉽습니다.

+0

흥미 롭습니다. 프로그래밍하는 동안이 사실이 점점 더 사실임을 알게되었습니다. 원래 독창적 인 시각은 모바일 앱을위한 새로운 Rails 뷰 세트를 개발하는 것일뿐입니다. 그러나 오른쪽 MVC 구조는 응답 성 측면에서 최고의 경험을 제공하는 것 같습니다. – JBlake

+0

True- "(아마도 클라이언트 측 응용 프로그램의 풍부함과 관련하여 서버가 상당히 바보가되는 세상을 볼 수 있습니다.) 이것은 두꺼운 클라이언트/씬 클라이언트 진자의 다음 사이클 일 것입니다. 수십 년 동안 흔들림 ;-)) " – arvindwill

관련 문제