Flux 디자인 패턴 (1)

이번에는 리액트에서 많이 사용되는 flux패턴에 대한 공부를 해보고자 합니다.

REACT를 사용하면서 컴포넌트끼리 데이터를 교류할 때 글로벌 이벤트 시스템을 설정하는 방법인 flux 디자인 패턴에 대해 알아보고 MVC가 아닌 FLUX패턴을 적용하는지에 대해 알아 보겠습니다.

디자인 패턴을 사용하는 이유

1. 유지보수성 향상: 디자인 패턴을 사용하면 코드의 일관성이 유지되고, 코드를 이해하기 쉬워집니다. 따라서 프로젝트가 커져도 코드를 쉽게 관리할 수 있습니다.
2. 재사용성 증가: 디자인 패턴을 활용하면 유사한 상황에서 코드를 재사용할 수 있습니다. 이는 개발 시간을 단축시키고 코드의 효율성을 높입니다.
3. 확장성 강화: 디자인 패턴은 시스템을 확장하거나 변경할 때 유용합니다. 새로운 기능을 추가하거나 기존 기능을 수정할 때 코드의 일부를 변경하면 되므로 시스템을 유연하게 확장할 수 있습니다.
4. 코드 품질 향상: 디자인 패턴은 일반적으로 좋은 소프트웨어 공학 원칙을 따릅니다. 이를 통해 코드의 가독성과 유지보수성이 향상되어 더 높은 품질의 코드를 작성할 수 있습니다.
5. 설계 패턴 적용: 디자인 패턴은 특정한 상황에서 효과적인 설계 방법을 제공합니다. 이를 통해 개발자들은 공통된 문제에 대한 일반적인 해결책을 사용할 수 있습니다.
6. 커뮤니케이션 향상: 디자인 패턴은 개발자들 간에 의사소통을 원활하게 합니다. 패턴 이름을 사용하여 코드의 의도를 명확하게 전달할 수 있습니다.
7. 안정성과 신뢰성 향상: 검증된 디자인 패턴을 사용하면 오랜 기간 동안 사용되어 안정성과 신뢰성이 검증된 솔루션을 활용할 수 있습니다.
8. 기술 간 중립성: 디자인 패턴은 특정 기술에 종속되지 않으며 다양한 프레임워크나 라이브러리에서 적용할 수 있습니다.

MVC의 한계

1. 복잡성 증가: 복잡한 애플리케이션에서는 MVC 패턴이 과도하게 복잡해질 수 있습니다. 특히 컨트롤러와 뷰 간의 의존성이 복잡해질 경우 유지보수가 어려워질 수 있습니다.
2. 중복 코드: 뷰와 컨트롤러 간에 코드가 중복될 수 있습니다. 예를 들어, 사용자 입력을 처리하는 로직이 뷰와 컨트롤러 양쪽에서 중복될 수 있습니다.
3. 테스트 어려움: 일부 MVC 구현에서는 컨트롤러와 뷰를 분리하기 어려울 수 있습니다. 이로 인해 유닛 테스트가 어려워질 수 있습니다.
4. 뷰와 모델의 직접적인 의존성: 일부 경우에는 뷰가 모델에 직접 접근하여 데이터를 가져오기도 합니다. 이렇게 되면 뷰와 모델 간의 강력한 의존성이 형성됩니다.
5. 모델의 복잡성: 모델은 종종 비즈니스 로직을 처리하므로 복잡해질 수 있습니다. 이로 인해 모델이 무겁고 복잡해질 수 있습니다.
6. 유지보수 어려움: 일부 경우에는 모델, 뷰 및 컨트롤러 간의 상호 의존성이 높아져 유지보수가 어려울 수 있습니다.
7. 대규모 애플리케이션의 확장 어려움: 대규모 애플리케이션에서는 MVC 패턴이 유지보수 및 확장이 어려울 수 있습니다. 복잡한 의존성과 구조 때문에 적절한 디자인 패턴을 고려해야 할 수 있습니다.
8. 프로젝트 시작 초기에는 지나치게 복잡할 수 있음: 간단한 프로젝트에서는 MVC 패턴을 도입하기에는 지나치게 복잡할 수 있습니다. 이로 인해 초기 개발 속도가 느려질 수 있습니다.

요약하면, MVC 패턴은 많은 장점을 가지고 있지만, 복잡한 애플리케이션에서는 유지보수 및 확장이 어려울 수 있습니다. 이런 경우에는 다른 디자인 패턴이나 아키텍처를 고려해 볼 수 있습니다.

Flux 패턴이란?

FLUX패턴은 facbook에서 개발한 웹 애플리케이션 아키텍쳐입니다.

이 패턴은 단방향 데이터 흐름을 갖는 애플리케이션을 만들기 위한 것인데, 애플리케이션의 복잡성을 관리하고 유지보수를 쉽게 하기 위한 목적으로 만들어졌습니다.

Flux 아키텍처는 다음의 구성 요소로 구성됩니다.

1. Actions: 사용자 입력이나 API 응답과 같은 이벤트를 나타내는 객체입니다. Action은 어떤 변화가 일어났는지 설명하는 정보를 가지고 있습니다.
2. Dispatcher: Action을 받아서 Store에 전달하는 역할을 합니다. Dispatcher는 전역적으로 유일한 역할을 하며, Action을 받으면 등록된 모든 Store에 해당 Action을 전달합니다.
3. Stores: 애플리케이션의 상태(데이터)를 관리합니다. 각각의 Store는 특정 부분의 상태를 담당하고 있습니다. Store는 데이터를 가지고 있고, 변경되면 등록된 View에게 알려줍니다.
4. Views: 사용자에게 데이터를 보여주는 부분입니다. View는 Store의 상태를 구독하고, 상태가 변경되면 새로운 데이터를 표시합니다.

Flux의 데이터 흐름은 다음과 같습니다:

1. 사용자 액션 또는 API 요청 등으로부터 Action이 생성됩니다.
2. Action은 Dispatcher를 통해 등록된 모든 Store에 전달됩니다.
3. 각각의 Store는 Action을 처리하여 상태를 업데이트합니다.
4. 상태가 변경되면 Store는 등록된 View에게 알립니다.
5. View는 새로운 상태를 받아와 화면에 업데이트합니다.

사용시 이점

Flux 패턴은 단방향 데이터 흐름을 가지기 때문에 예측 가능하고 디버깅하기 쉬운 장점이 있습니다.

또한 여러 개의 Store가 독립적으로 상태를 관리하기 때문에 각각의 역할이 명확하게 분리되어 있습니다.

Flux 패턴의 대표적인 라이브러리로는 Redux가 있습니다.

사용시 단점

1. 복잡성 증가: 작은 규모의 애플리케이션에서는 간단한 상태 관리만으로도 충분하지만, 큰 규모의 애플리케이션에서는 Flux 아키텍처가 복잡성을 더할 수 있습니다. 많은 Actions, Stores, 그리고 이들 간의 연결을 관리해야 하는 부담이 있습니다.
2. Boilerplate 코드: Flux 패턴은 많은 boilerplate 코드를 생성할 수 있습니다. Store와 Action을 생성하고 연결하는 과정이 반복적으로 이루어져야 합니다.
3. 단방향 데이터 흐름의 한계: 단방향 데이터 흐름은 간단하고 예측 가능하지만, 일부 상황에서는 복잡한 비동기 처리 또는 조건부 업데이트가 어려울 수 있습니다.
4. Store 의존성 관리: 여러 개의 Store이 존재할 때, 각각의 Store이 다른 Store에 의존성을 가지는 경우가 발생할 수 있습니다. 이런 경우에는 Store 간의 의존성을 관리하는 것이 어려울 수 있습니다.
5. 프레임워크 종속성: Flux 패턴은 React와 같은 뷰 라이브러리와 함께 사용될 때 가장 잘 작동합니다. 다른 프레임워크나 라이브러리와의 호환성이 떨어질 수 있습니다.

이러한 단점들은 애플리케이션의 규모와 복잡성, 그리고 개발자들의 경험과 선호도에 따라 다를 수 있습니다. Flux 패턴이 항상 최선의 선택은 아니며, 프로젝트의 특성에 따라 다른 상태 관리 패턴이나 라이브러리를 고려해야 합니다.

 

 

 

 

https://oliviakim.tistory.com/93#Action-1

https://blog.naver.com/backsajang420/221368106022

https://bestalign.github.io/translation/cartoon-guide-to-flux/