앞 뒤 가 분 리 된 사고 와 실천 (2)

전후 단 분 리 를 바탕 으로 하 는 모델 탐색
머리말
전후 단 분 리 를 할 때 첫 번 째 로 주목 하 는 문 제 는 바로 과장 하 다 View 이 차원 의 일.
전통 적 인 개발 모델 에서 브 라 우 저 엔 드 와 서버 엔 드 는 서로 다른 앞 뒤 엔 드 두 팀 이 개발 하지만 모델 은 이 두 가지 중간 에 모호 한 지역 에 있다.따라서 모델 위 에 점점 더 복잡 한 논리 가 불가피 하고 결국은 유지 하기 어렵다.
우 리 는 앞 뒤 끝의 중간 층 으로 NodeJS 를 선택 했다.NodeJS 를 통 해 정리 하려 고 합 니 다. View 차원 의 사업.
앞 뒤 분업 을 더욱 명확 하 게 하고 전문 안건 을 더욱 잘 유지 하 며 더욱 좋 은 사용자 체험 을 달성 하도록 한다.
본문
이 작업 을 과장 하 는 것 은 전단 개발 자의 일상적인 업무 에 있어 매우 큰 비례 를 차지 하고 백 엔 드 개발 과 갈등 하기 쉬 운 부분 입 니 다.
과거 전단 기술 이 발전 한 이 몇 년 을 돌 이 켜 보면 View 이 차원 의 업 무 는 여러 차례 의 변혁 을 거 쳤 는데 마치:

양식 제출 전체 페이지 새로 고침 = > AJAX 부분 리 셋

서버 리 셋 + MVC = > 클 라 이언 트 렌 더 링 + MVC

전통 적 인 페이지 전환 = > 단일 페이지 응용

이 몇 년 동안 모두 가 과장 하 다 이 일 은 서버 쪽 에서 브 라 우 저 쪽으로 옮 겨 졌 다.
서버 측은 서비스 화 ，데이터 인 터 페 이 스 를 제공 하 다.
브 라 우 저 엔 드 렌 더 링 의 장점
브 라 우 저 엔 드 렌 더 링 의 장점 을 잘 알 고 있 습 니 다.

업무 논리 와 표현 논리 가 자바 모델 엔진 에서 의 결합 과 혼란 에서 벗 어 났 다.

다 중 단말기 에 대한 응용 은 인터페이스 화 된 형식 으로 하기 쉽다.브 라 우 저 에 서로 다른 모델 을 조합 하여 서로 다른 응용 을 보 여 줍 니 다.

페이지 는 원래 html 뿐만 아니 라 전단 의 렌 더 링 은 구성 요소 화 형식 (html + js + css) 으로 쉽게 기능 을 제공 하여 전단 구성 요 소 를 서버 에서 발생 하 는 html 구조 에 의존 하지 않 아 도 됩 니 다.

백 엔 드 개발, 발표 절차 에 대한 의존 에서 벗 어 났 다.

연결 이 편리 하 다.

브 라 우 저 엔 드 렌 더 링 으로 인 한 나 쁜 점
하지만 좋 은 점 을 누 리 는 동시에 우리 도 직면 했다. 브 라 우 저 엔 드 렌 더 링 가 져 온 나 쁜 점 은 다음 과 같다.

모델 은 서로 다른 라 이브 러 리 에서 분리 된다.어떤 모델 은 서버 (JAVA) 에 놓 고, 어떤 모델 은 브 라 우 저 (JS) 에 놓는다.앞 뒤 모판 언어 가 통 하지 않 습 니 다.

모든 모드 와 구성 요소 가 브 라 우 저 에서 불 러 온 후에 야 렌 더 링 을 시작 할 수 있 습 니 다. 바로 볼 수 없습니다.

처음 들 어가 면 흰색 화면 이 렌 더 링 을 기다 리 는 시간 이 있어 사용자 체험 에 불리 하 다

단일 페이지 애플 리 케 이 션 을 개발 할 때 전단 라 우 트 는 서버 엔 드 라 우 트 와 일치 하지 않 아 처리 하기 어렵다.

중요 한 내용 은 모두 전단 에서 조립 하여 SEO

에 불리 하 다.
전후 단의 정 의 를 반성 하 다.
사실 돌 이 켜 보면 우리 가 렌 더 링 작업 을 서버 (자바) 에서 브 라 우 저 (JS) 로 추출 할 때 우리 의 목적 은 단지 명확 한 전후 단 직책 구분 은 브 라 우 저 렌 더 링 이 아 닌 것 이 아 닙 니 다. 。
다만 전통 적 인 개발 모델 에서 서버 가 나 오 면 브 라 우 저 에 도착 하기 때문에 전단 의 작업 내용 은 브 라 우 저 로 만 제 한 될 수 있다.
그래서 많은 분 들 이 인정 해 주 셨 어 요.  =   =  ，아래 그림 처럼
타 오 바 오 UED 에서 진행 되 고 있 는... 미 드 웨 이 프로젝트 에서 JAVA – Browser 중간 에 NodeJS 중간 층 을 구축 하여 이 앞 뒤 부분의 분할 선 을 다시 겨냥 하려 고 합 니 다. 직책 구분 하고 하 드 환경 을 구분 합 니 다 (서버 & 브 라 우 저).
그래서 우 리 는 모델 과 경로 의 공 유 를 할 수 있 는 기회 가 있 고 앞 뒤 분업 에서 가장 이상 적 인 상태 이다.
타 오 바 오 미 드 웨 이
미 드 웨 이 프로젝트 에서 우 리 는 앞 뒤 단 계 를 구분 하 는 선 을 브 라 우 저 에서 서버 쪽으로 옮 겼 다.
구실 을 대다 거뜬 히 장악 하 다 ... 뿐만 아니 라 브 라 우 저 와 공유 의 Nodejs 층 으로 앞 뒤 단 분 리 를 더욱 뚜렷하게 완성 할 수 있 습 니 다.
전단 개발 이 서로 다른 상황 에 맞 춰 스스로 결정 하도록 할 수도 있다. 가장 적절 한 해결 방안 。모든 게 아니 라 모두 브 라 우 저 에서 처리 합 니 다. 。
직책 구분
미 드 웨 이 는 전단 에서 백 엔 드 밥그릇 을 빼 앗 으 려 는 프로젝트 가 아니 라 모판 이 모호 한 지 대 는 명확 하 게 절단 되 어 더욱 명확 한 직책 구분 을 얻 었 다.

백 엔 드 (JAVA), 집중

서비스 층

데이터 형식, 데이터 안정

업무 논리

 

전단, 집중

UI 층

제어 논리, 렌 더 링 논리

상호작용, 사용자 체험

 
서버 나 브 라 우 저 측의 차이 에 얽 매 이지 않 습 니 다.
모드 공유
전통 적 인 개발 모델 에서 브 라 우 저 엔 드 와 서버 엔 드 는 서로 다른 앞 뒤 엔 드 두 팀 이 개발 하지만 모델 은 이 두 가지 중간 에 모호 한 지역 에 있다.따라서 모델 위 에 점점 더 복잡 한 논리 가 불가피 하고 결국은 유지 하기 어렵다.
NodeJS 가 있 으 면 백 엔 드 학생 들 은 JAVA 층 에서 업무 논리 와 데이터 개발 에 전념 할 수 있 습 니 다.전단 학생 들 은 논리 와 과장 을 통제 하 는 개발 에 전념 했다.그리고 스스로 이 모델 들 을 선택 하 는 것 은 서버 (NodeJS) 혹은 브 라 우 저 엔 드 과장 하 다.
똑 같은 모드 언어 로. XTemplate ，같은 렌 더 링 엔진 JavaScript
... 에 있다 서로 다른 렌 더 링 환경 (Server - side, PC Browser, Mobile Browser, Web View, etc.) 렌 더 링 같은 결과 。
공유 경로
NodeJS 라 는 층 이 있 기 때문에 경 로 를 더욱 세밀 하 게 제어 할 수 있다.
전단 에서 브 라 우 저 단 로 를 만 들 필요 가 있 을 때 서버 단 로 를 동시에 설정 하여 브 라 우 저 쪽 바 꾸 기 혹은 서버 페이지 변경 ，모두 일치 하 는 렌 더 링 효 과 를 얻 을 수 있다.
SEO 문제 도 처리 했다.
모델 공유 의 실천
일반적으로 우리 가 브 라 우 저 에서 모델 을 렌 더 링 할 때 절 차 는 다음 과 같 습 니 다.

브 라 우 저 에서 모드 엔진 (xtmpleate, juicer, handlerbar, etc.)

을 불 러 옵 니 다.

브 라 우 저 에서 모드 파일 을 불 러 옵 니 다. 방법 은 있 을 수 있 습 니 다

사용  ...  페이지 에 인쇄

모듈 로 도 구 를 불 러 오고 모듈 파일 (KISSY, requireJS, etc.)

을 불 러 옵 니 다.

기타

데 이 터 를 얻 고 모드 엔진 을 사용 하여 html 를 지정 한 위치 에 삽입 합 니 다.
이상 의 절 차 를 통 해 알 수 있 듯 이 모델 의 크로스 엔 드 공 유 를 하려 면 중점 은 바로 일치 하 는 모듈 선택 이 일 은
시장 에 서 는 KMD, AMD, CommonJS 등 여러 가지 모듈 표준 이 유행 하고 있 는데, NodeJS 의 모듈 파일 을 일치 모듈 규범 을 통 해 NodeJS 단 에 출력 할 수만 있다 면 기본 적 인 모듈 공 유 를 할 수 있다.
그리고 후속 적 인 시 리 즈 는 모델 의 proxy 와 공유 에 대해 진일보 한 연 구 를 할 것 이다.
사례 연구
중도 도 라 는 중간 층 이 있 기 때문에 과거의 일부 문제 에 대해 더 좋 은 해답 을 얻 었 다. 예 를 들 어
사례 1 복잡 한 상호작용 응용 (예 를 들 어 카 트, 주문 페이지)

상황: 모든 HTML 은 전단 에서 렌 더 링 이 완료 되 었 고 서버 는 인터페이스 만 제공 합 니 다.

문제: 페이지 에 들 어 갈 때 짧 은 흰색 화면 이 있 습 니 다.

해답:

첫 페이지 진입, NodeJS 에서 진행 전체 페이지 렌 더 링 ，배경 에 관련 모델 을 다운로드 합 니 다.

후속 상호작용, 브 라 우 저 에서 완료 부분 리 셋

 동일 판 ， 생기다 같은 결과

사례 2 단일 페이지 응용

상황: Client Side MVC 프레임 워 크 를 사용 하여 브 라 우 저 에서 페이지 를 바 꿉 니 다.

문제: 렌 더 링 과 페이지 교환 은 모두 브 라 우 저 에서 이 루어 집 니 다. 인터넷 주 소 를 직접 입력 하거나 f5 새로 고침 할 때 같은 내용 을 직접 표시 할 수 없습니다.

해답:

브 라 우 저 에서 NodeJS 단 과 공유 같은 루트 설정

브 라 우 저 에서 페이지 를 바 꿀 때 브 라 우 저 에서 Route 변경 및 페이지 내용 렌 더 링

같은 주 소 를 직접 입력 할 때 NodeJS 에서 진행 페이지 프레임 워 크 + 페이지 내용 렌 더 링

브 라 우 저 에서 페이지 를 바 꾸 거나 같은 주 소 를 직접 입력 하면 보 이 는 내용 은 모두 같다 。

체험 을 늘 리 고 논리 적 복잡 도 를 줄 이 는 것 외 에.더욱 해결 되 었 다 SEO 라 는 질문

사례 3 순 탐색 형 페이지

상황: 페이지 는 정보 만 제공 하고 상호작용 이 적 거나 없다

문제: html 는 서버 에서 발생 하고 css 와 js 는 다른 위치 에 놓 여 서로 의존 합 니 다.

해답:

NodeJS 를 통 해 html + css + js

를 통일 적 으로 관리 합 니 다.

앞으로 복잡 한 응용 이나 단일 페이지 응용 으로 확장 해 야 한다 면 쉽게 이전 할 수 있다.

사례 4 단 단말기 페이지

상황: 똑 같은 응용 은 서로 다른 점 에서 서로 다른 인터페이스 와 상호작용 을 보 여야 한다

문제: html 관리 가 쉽 지 않 고 서버 에서 서로 다른 html 가 자주 발생 하 며 브 라 우 저 에서 또 다른 처 리 를 해 야 합 니 다

해답:

터미널 을 뛰 어 넘 는 페이지 는 렌 더 링 문제 이 고 전단 에서 통일 적 으로 처리 합 니 다.

NodeJS 층 과 백 엔 드 서비스 화 를 통 해 이런 유형의 복잡 한 응용 에 착안 하여 가장 좋 은 해결 방안 을 디자인 할 수 있다.

총결산
과거 AJAX, Client - side MVC, SPA, Two - way Data Binding 등 기술 의 등장 은 당시 전단 개발 이 겪 었 던 병목 을 해결 하려 는 시 도 였 다.
한편, NodeJS 중간 층 의 등장 도 현재 전단 이 브 라 우 저 에 국한 되 어 있 는 제한 을 해결 하려 고 노력 하고 있다.
이 글 은 앞 뒤 모델 공유 에 전념 하고 벽돌 을 던 져 옥 을 끌 어 올 리 는 데 도 전념 하고 있 습 니 다. 여러분 과 함께 NodeJS 중간 층 이라는 구조 에서 우리 가 어떻게 우리 의 업무 절 차 를 개선 하고 어떻게 할 수 있 는 지 토론 하고 자 합 니 다. 백 엔 드 전단 이 일 은 더욱 잘 한다.