Flux 아키텍쳐

MVC의 문제점

Flux 아키텍처를 알아보기전에 그 배경이 되는 MVC 패턴의 특징을 먼저 알아보겠습니다.

• Facebook에서 언급했던 MVC의 단점은 양방향 데이터 흐름입니다.
• MVC 패턴의 동작 과정은 다음과 같습니다.
  • Controller는 Model의 데이터를 조회하거나 업데이트 하는 역할을 합니다.
  • Model이 업데이트 되면 View는 화면에 반영합니다.
  • View가 Model을 업데이트할 수도 있습니다. 이 때 해당 Model에 의존성을 가진 또 다른 View가 업데이트 될 수 있습니다.
• 이러한 양방향성 데이터 흐름을 가진 동작 과정은 애플리케이션이 복잡해질 수록 유지보수, 기능추가를 어렵게 합니다.

Flux 아키텍쳐란?

• MVC 모델의 단점을 보완하기 위해 페이스북에서 발표한 아키텍쳐입니다.
• 단방향 데이터 흐름을 가집니다.
  • 데이터는 항상 Dispatcher → Store → View로 흐릅니다.
  • 액션을 따라가면 어떤 변경이 발생하는지 알 수 있어 코드 흐름 파악 가능
    • 유지보수, 기능 추가, 유닛 테스트에 용이합니다.
• Redux나 Mobx와 같이 Flux를 발전시킨 다양한 구현 라이브러리들이 있습니다.

구성

Dispatcher

• Flux의 모든 데이터 흐름을 관리하는 허브 역할입니다.
• View로부터 Action을 받아 스토어에 전달합니다.
• 내부에 상태 변경 로직이 존재하지 않습니다.

 

Store

• 어플리케이션의 상태가 저장되어 있는 전역 저장소입니다.
• 어플리케이션 내 **모든 상태 변경을 결정(상태 변경 로직 있음)**합니다.
• 디스패처에서 전달된 액션을 통해서만 상태를 변경합니다.
• 상태가 변경되면 뷰에게 통지합니다.

 

View

• 상태에 따라 화면을 출력합니다.
• 컨트롤러와 뷰의 역할을 합니다.
  • 스토어가 통지하는 상태 변경을 수신하고 받은 상태에 따라 뷰를 새로 랜더링합니다.
• 디스패쳐에 액션 전달하여 상태변경 요청할 수 있음

 

Action (Flux의 구성요소는 아닙니다.)

• ajax나 뷰에서 발생한 상태변경을 요청합니다.
• 디스패쳐에 전달되는 데이터를 담은 단순한 객체입니다.
• 액션이름(type)과 데이터(payload)를 담고있습니다.

{
	type: 'newMessage',
	payload:{
		id: 1,
		message: 'lunch time!',
		...
	}
}

 

 

 

 

 

 

 

 

 

 

[참고자료]

[디자인패턴] Flux, MVC 비교

[10분 테코톡] 우디의 Flux Architecture