Flux 패턴


자바스크립트에서 데이터 레이어를 생성하기위한 아키텍쳐로 Flux라는 이름으로 패턴이 구현되었다.


프로그램의 데이터에 대한 명확하고 이해하기 쉬운 업데이트 경로를 만드는데 중점을 둔다.


개발과정에서는 변경사항을 추적하는 것이 간단하고, 버그를 찾고 수정하는것이 용이해진다.


개요 


플럭스를 가장 잘 설명하기 위해 MVC와 같은 주요 클라이언트 측 아키텍처 중 하나와 비교해 보면 알 수 있는데, 클라이언트 측 MVC 애플리케이션에서 사용자의 상호 작용은 컨트롤러의 코드를 트리거한다. 컨트롤러는 모델의 메소드를 호출하여 하나 이상의 모델에 대한 변경 사항을 조정하는 역할을 한다. 이는 모델이 변경되면 하나 이상의 뷰에 통보하고 모델에서 새 데이터를 읽고 사용자가 새 데이터를 볼 수 있도록 업데이트한다.





MVC는 어플리케이션의 규모가 커지면서 controller, model, view가 추가되는데

종속성이 더욱 복잡해진다.



단 3 개의 뷰, 하나의 컨트롤러 및 하나의 모델을 추가했을뿐인데

종속성 관계는 이미 추적하기가 더 어려워졌다. 


사용자가 UI와 상호 작용할 때 여러 가지로 분기된 경로로 코드가 실행되고 

응용 프로그램에서는 디버깅 할때에도 문제가 되는데 

특히나 런타임에서 구동되는 프로그램의 경우 실행되면서 발견할 수 있는 잠재적 버그를 찾는것 또한 이러한 경로 중 하나 (또는 ​​그 이상)의 어떤 모듈에 버그가 있는지 파악하는 데 많은 불편함이 있다.


최악의 경우, 사용자 상호 작용은 업데이트를 트리거하고 추가 업데이트를 트리거하므로 오류가 발생하기 쉽고 디버깅하기 어려울 수 있다. 

이 중 일부는 중복되는 경로를 따라 계단식 효과가 발생하기도 한다.


Flux는 단방향 데이터 흐름을 선호하여이 디자인을 피한다. 

뷰 내의 모든 사용자 상호 작용은 작업 생성자를 호출하여 싱글 톤 전달자에서 

작업 이벤트를 발생시킨다 . 

디스패처는 플럭스 적용시 모든 동작에 대해 단일 포인트 송출만을 갖는다. 

액션은 디스패처에서 전송되고 store작업에 대한 응답으로 업데이트 한다.





간단한 플럭스 흐름


추가된 store 또는 뷰에 대한 플로우는 크게 변경되지 않습니다. 

Dispatcher는 모든 작업을 응용 프로그램의 모든 store에 보낸다. 

저장소를 실제로 업데이트하는 방법에 대한 내용은 store에 포함되어있지 않다. 

store 자체는 이벤트가 Dispatcher된 비즈니스 로직만을 갖고있다. 

각 저장소는 응용 프로그램의 작업에 대한 응답으로만 업데이트된다.


복잡한 플럭스


보다 복잡한 플럭스 흐름

저장소가 업데이트되면 변경 이벤트가 발생한다. 

많은 React 어플리케이션에서 특별한 뷰 ( "컨트롤러 뷰"라고도 함)는 이 변경 이벤트를 감시하고, 저장소의 새 데이터를 읽고, 해당 데이터를 속성을 통해 하위 뷰에 전달되게 된다. 

저장소 변경 이벤트에 대한 React 응용 프로그램에서 최상위에서 다시 렌더링을 트리거하고 효과적으로 (React가 효율적인 방식으로 처리하는) 나타내기때문에,

모든 계층 구조를 다시 렌더링하는 경우는 드물게된다. 이는 모델의 특정 속성 변경을 감시하고 일부보기만 수정하려고 시도 할 때 발생할 수있는 복잡한 버그 및 성능 문제를 완전히 방지할 수 있다.


========= 작성중 =======


키 특성 

플럭스 아키텍처는 데이터를 명확하고 쉽게 이해할 수 있게 해주고 

버그의 범위를 증가시키는 것을 중심으로 제공하는 몇 가지 핵심 속성을 가지고있다. (그래서 당신은 많은 것을 사냥 할 필요가 없다. 잘못된 경로를 찾기위한 코드 경로). 

많은 플럭스 및 플럭스와 같은 구현이 가능한데 이러한 속성은 플럭스 아키텍처에서 

가장 중요하다


강제 동기화 

저장소 작업 디스패치와 그 핸들러는 동기적입니다. 모든 비동기 작업은 작업의 결과를 시스템에 통지하는 액션 디스패치를 실행해야합니다 (자세한 내용은 비동기 드 타가이도를하십시오). 액션 작성자는 비동기 API를 호출 할 수 있지만 저장소 액션 핸들러는 이상적으로는 그렇지 않습니다. 이 규칙은 응용 프로그램의 정보의 흐름이 매우 명확합니다. 응용 프로그램 상태의 오류를 디버깅하려면, 어떤 조치가 상태가 발생했는지를 확인하고 해당 작업에 답 된 잘못된 논리를 찾을 필요합니다.


반전 제어 

스토어 (제어 라와 같은의 모듈 르 의해 외부에서 업데이트되는 것이 아니라) 액션 무지개하고 부적으로 업데이트되므로 시스템의 다른 부분은 응용 프로그램의 상태를 업데이트하는 방법을 알 필요가 없습니다. 상태를 업데이트하는 논리는 모든 상점 자체에 포함되어 있습니다. 또한 스토어는 액션 무지개 동기화으로 만 업데이트되지 않으므로 저장소를 테스트하는 것은 순으로 초기 상태로 액션을 보내 올바른 최종 상태에 있는지 여부를 테스트 할 수 있습니다.


시맨틱 액션 

스토어는 액션 무지개 자신을 업데이트 할 필요가 있기 때문에, 액션은 의미 적으로 기술적 경향이 있습니다. 예를 들어, 플럭스 포 라무아뿌리케 프로그램에서 스레드의 매 크를 넣으려면 타입 MARK_THREAD_READ의 액션을 발송합니다. 액션 (및 액션을 생성하는 구성 요소) 업데이트를 실시하는 방법을 모르지만, 그것이 무엇을 원하는지를 설명합니다.


이 속성을 위해, 당신은 당신의 작업 유형을 추가 할 필요는 거의 없습니다. 저장소가 그것을 어떻게 반대하거나뿐입니다. 응용 프로그램에 '스레드'의 뜻이 스레드로 매 크 버튼 또는 기타 작업이있는 한 MARK_THREAD_READ 조치 유형은 의미 적으로


계단식 액션 없음 

Flux는 액션을 발송 한 결과, 두 번째 액션을 발송하는 것을 허용하지 않습니다. 이것은 디버깅이 어려운 캐스 드 업데이트를 방지하는 데 도움 또한 세만 틱 액션의 관점에서 응용 프로그램의 상호 작용에 대해 생각하는 데 도움이됩니다.


http://fluxxor.com/what-is-flux.html

'■ 개발관련 ■ > Design Pattern' 카테고리의 다른 글

Flux 패턴  (0) 2019.03.12
AS3.0 MVC Pattern  (0) 2013.10.16
Posted by SAP (Study And Programming) by serpiko

댓글을 달아 주세요