Titanium의 비즈니스 로직을 Node.js로 개발

크리스마스까지 앞으로 약간.
올해는 첫 참가로 2 프레임 주셔서 감사합니다. @ 시노우 t 라고 합니다.
Titanium-JP계의 저명한 분들에게 신세를 지면서 의료계 스타트업을 시작한 JSer입니다.
전회와 관련한 내용이 됩니다만 자신의 관심 있는 멀티 플랫폼 JavaScript의 이야기를 시켜 주세요.
이해하기 어렵다면 죄송합니다. .

비즈니스 로직 계층과 UI 계층을 분리하는 것이 좋습니다.



그것은
1. 규모가 커져도 취급하기 쉽고, 변경에 강하다
2. 비즈니스 로직 부분을 Node로 개발할 수 있으면 개발 속도 빨라진다
부터입니다.
(규모가 작을 때는 스마트 UI 패턴 로 만들어 도망치는 것도 선택사항 중 하나입니다.)

어떻게 나누는가



모델과 그 동작 (model), 모델 생성 (factory), 모델의 CRUD 부분 (repository)
비즈니스 로직으로 격리. 이른바 '도메인'이라는 부분입니다.
(이것을 깨끗이 잘라내는 것이 힘들지만 그 이야기는 할애...)

예를 들어 MBaaS (Mobile Backend as a Service, 데이터의 지속성에 관한 RESTful API를 제공하는 것)를 이용한 서비스를 생각합니다.

이 경우 데이터 계층이 HTTP를 통한 범용이 되기 때문에 플랫폼에 의존하기 어려워집니다 또한 있습니다).

이전에 소개한 ti-superagent을 사용하면 HTTP Request 라이브러리의 superagent을 Titanium에서도 사용할 수 있으며 데이터 액세스 부분도 포함하여 Node.js/Web/Titanium에서 이동하게 됩니다.

개발/테스트는 Node.js에서 수행 할 수 있으며 PDCA 사이클을 빠르게 돌릴 수 있습니다.
특히 네트워크를 통한 테스트를 Node로 할 수 있는 것은 큰 장점입니다.

도메인은 여러 플랫폼에서 재사용 가능



MBaaS 외에 관리용 서버가 필요하거나 웹 앱이 필요하다는 수요가 있을 것이다.
그 때 모델 포함한 비즈니스 로직의 재정의는 필요없고, 그대로 도메인을 사용하면 됩니다.

아래에 개념도를 올렸습니다.



browserify 이나 tisomorphic 을 사용하여 require() 등의 차이를 흡수하고
각 플랫폼에서 움직일 수 있습니다.

Alloy의 모델 (Backbone의 것)은 어떻게합니까?



현재는 사용하지 않습니다. 이용하는 이점도 있다고 생각합니다만,
1. 개발 속도
2. 재사용
그렇다면 플랫폼 의존성을 없애는 것이 더 중요하다고 생각합니다.

예를 들면 모두가 신경이 쓰이고 있다 코르도바 이나 React Native 에도 마찬가지로 도메인을 재이용할 수 있으므로,
쉽게 기존 프로젝트를 이러한 플랫폼에서 사용해 볼 수도 있습니다.

요약


  • UI와 비즈니스 로직(도메인)을 분리하고, 비즈니스 로직은 범용적인 JS로 하면 된다.
  • 범용적인 JS는 Node.js로 개발/테스트하면 사이클이 빠르다!
  • 데이터 계층이 네트워크에 있으면 다 플랫폼 배포하기 쉽다!
  • 분리된 비즈니스 로직은 나중에 다른 플랫폼에서 재사용할 수 있습니다!
  • 좋은 웹페이지 즐겨찾기