디자인 패턴
디자인 패턴은 소프트웨어의 개발 방법을 공식화한 것으로 소프트웨어 개발에서 반복적으로 발생하는 문제에 대한 해결책을 정형화한 형태의 설계 템플릿이자, 개발자들 간의 커뮤니케이션의 효율성을 높이는 기법이다.
MVC 패턴
MVC (Mode-View-Controller) 패턴은 소프트웨어 개발에서 사용되는 아키텍처 패턴 중 하나로, 애플리케이션을 세 가지 주요 구성 요소로 분리하여 개발하는 방법입니다. 각 구성 요소는 특정한 역할을 수행하며, 애플리케이션의 코드를 조직화하고 유지 보수하기 쉽게 만듭니다.
Model
Model은 데이터와 비즈니스 로직을 관리하는 역할을 담당합니다. 데이터는 애플리케이션의 상태나 정보를 나타내며, 비즈니스 로직은 데이터를 처리하고 조작하는 데 사용됩니다. Model은 주로 데이터베이스와의 상호 작용, 데이터 유효성 검사, 비즈니스 규칙의 구현 등을 다룹니다.
View
View는 사용자 인터페이스(UI)를 나타냅니다. 이는 사용자가 시각적으로 상호 작용하는 부분으로, 화면에 표시되는 요소들을 담당합니다. View는 사용자 입력을 받고 Model에서 가져온 데이터를 표시하는 역할을 수행합니다. 사용자와의 직접적인 상호 작용을 처리하는 로직은 포함하지 않으며, 오로지 데이터의 표현에만 집중합니다.
Controller
Controller는 Model과 View 간의 상호 작용을 관리하는 역할을 수행합니다. 사용자의 입력을 처리하고 해당 입력에 대한 비즈니스 로직을 호출합니다. 이후, 필요한 데이터를 Model에서 가져와 View에 전달하여 데이터의 표현을 업데이트합니다. Controller는 Model과 View의 결합도를 낮추고, 각각 독립적으로 변경 가능하도록 합니다.
MVC 패턴의 느낀점
장점
- 코드의 재사용성과 유지 보수성이 좋고 각 구성 요소가 독립적으로 개발되고 테스트될 수 있기 때문에 코드의 변경이 다른 요소에 영향을 미치지 않습니다.
- 역할 분리로 인해 개발 작업이 효율적으로 분담됩니다. 디자이너는 View를 디자인하고, 개발자는 Model과 비즈니스 로직을 구현하며, 컨트롤러는 사용자 입력과 상호 작용을 관리합니다.
- 사용자 인터페이스와 비즈니스 로직의 분리로 인해 테스트 작업이 용이해집니다. 각 구성 요소는 독립적으로 테스트할 수 있으며, 테스트 커버리지를 높일 수 있습니다.
단점
- 복잡한 애플리케이션에서는 각 구성 요소 간의 의존성과 상호 작용이 복잡해질 수 있습니다. 이로 인해 구현의 복잡성이 증가할 수 있습니다.
- 작은 규모의 애플리케이션에서는 MVC 패턴의 추가적인 구조와 계층이 부담스러울 수 있습니다. 필요 이상의 오버헤드가 발생할 수 있습니다.
- View와 Model 간의 양방향 통신이 필요한 경우, 복잡한 상태 관리와 데이터 일관성을 유지하는 데 어려움이 있을 수 있습니다.
MVVM 패턴
MVVM(Model-View-ViewModel) 패턴은 MVC 패턴의 확장된 형태로, 소프트웨어 개발에서 사용되는 아키텍처 패턴입니다. MVVM은 UI와 비즈니스 로직 간의 결합도를 낮추고, 데이터 바인딩을 통해 코드의 가독성과 유지 보수성을 향상하는 데 중점을 둡니다.
Model
Model은 데이터와 비즈니스 로직을 관리하는 역할로, MVC 패턴의 Model과 동일합니다. 데이터를 저장하고 검색하며, 비즈니스 로직을 구현합니다.
View
View는 사용자 인터페이스(UI)를 나타내는 역할로, MVC 패턴의 View와 유사합니다. 사용자에게 정보를 표시하고, 사용자 입력을 받아 ViewModel로 전달합니다.
ViewModel
ViewModel은 View와 Model 간의 상호 작용을 관리하는 역할을 담당합니다. View에 표시할 데이터를 제공하고, 사용자 입력을 처리하여 Model에 반영합니다. ViewModel은 일반적으로 데이터 바인딩을 통해 View와 양방향으로 상호 작용하며, View의 상태를 추적하고 업데이트합니다.
MVVM 패턴의 느낀점
장점
- 데이터 바인딩을 통해 View와 ViewModel 간의 자동 업데이트가 가능해집니다. 데이터 변경 시, UI는 자동으로 업데이트되어 개발자가 직접 UI를 관리할 필요가 없습니다.
- View와 ViewModel이 독립적으로 개발될 수 있기 때문에, UI 로직과 비즈니스 로직이 분리되어 코드의 가독성과 재사용성이 높아집니다.
- 테스트 작업이 용이해집니다. ViewModel은 비즈니스 로직을 포함하므로, 단위 테스트를 통해 로직의 정확성을 검증할 수 있습니다.
단점
- MVVM 패턴은 복잡한 애플리케이션에 적합하며, 작은 규모의 애플리케이션에서는 오버헤드가 발생할 수 있습니다.
- 데이터 바인딩의 오용은 애플리케이션의 성능을 저하시킬 수 있습니다. 필요하지 않은 업데이트가 발생하거나, 많은 양의 데이터가 바인딩되는 경우에 주의가 필요합니다.
- MVVM 패턴의 도입은 초기 구조 설계 및 학습 곡선이 존재할 수 있습니다. 패턴에 대한 이해와 적절한 사용 방법을 학습해야 합니다.
Component 패턴
Component 패턴은 UI 요소를 재사용 가능하고 독립적으로 개발할 수 있도록 분리하는 디자인 패턴입니다. 애플리케이션을 작은 단위로 구성하는 컴포넌트들을 조합하여 복잡한 UI를 구성합니다.
기존 MVVM의 하나의 Page 단위에서 Page 안에 여러 가지 모듈이 있고 그 모듈을 조립하여 하나의 화면에서 구성하도록 하는 아키텍처로 발전한 디자인 패턴이라고 할 수 있습니다.
Component 패턴의 느낀점
장점
- 컴포넌트는 독립적으로 작동하며, 필요한 곳에서 쉽게 재사용할 수 있습니다. 이는 개발 생산성을 향상하고 코드의 중복을 줄여줍니다.
- 컴포넌트는 각각 독립적으로 개발되고 테스트될 수 있기 때문에, 변경이 다른 컴포넌트에 영향을 미치지 않습니다. 이는 코드의 유지 보수성을 향상시키고 오류의 범위를 제한하는 데 도움을 줍니다.
- 컴포넌트는 개별적으로 개발되기 때문에, 개발 작업을 분담하고 동시에 병렬로 진행할 수 있습니다. 이는 팀 작업에서 협업을 용이하게 합니다.
단점
- 컴포넌트 기반 개발은 애플리케이션의 구조를 분리하고 재조합하는 과정을 필요로 합니다. 이는 초기 구조 설계 및 학습 곡선이 존재할 수 있습니다.
- 너무 많은 컴포넌트를 사용하거나 컴포넌트 간의 데이터 흐름이 복잡한 경우, 성능 문제가 발생할 수 있습니다. 이는 관리되지 않은 불필요한 업데이트 또는 컴포넌트 간의 중복된 계산을 초래할 수 있습니다.
위 단점을 해결해 주기 위해 Redux를 사용해 FLUX 패턴을 도입해 단방향 데이터 흐름을 만들어 데이터를 예측 가능한 상태로 만들어 유지 관리하기 쉽게 만들 수 있습니다. 또한 Redux를 사용해 클라이언트 상태관리를 한다면 Props Drilling을 피할 수 있습니다.
Atomic 패턴
Atomic 디자인 패턴은 UI 요소를 작은 단위로 분리하여 재사용 가능한 구성 요소로 만드는 방법론입니다. 이 패턴은 화면을 구성하는 원자적인 요소들을 조합하여 복잡한 UI를 구축하고 일관된 디자인 시스템을 구성하는 데 중점을 둡니다.
Atomic 패턴의 느낀점
장점
- 원자적인 요소들은 독립적으로 개발되고 테스트될 수 있기 때문에 재사용성과 유지 보수성이 높아집니다. 또한, 조합하여 구성한 분자적인 요소들도 재사용이 용이하며, 변경이 필요한 경우 해당 요소만 수정하면 되므로 코드의 중복을 피할 수 있습니다.
- Atomic 패턴은 템플릿과 스타일 가이드를 통해 일관된 디자인 시스템을 구축할 수 있습니다. 이는 사용자 경험의 일관성을 제공하고 개발자와 디자이너 간의 협업을 용이하게 합니다.
단점
- 초기에 디자인 시스템과 스타일 가이드를 구축해야 하므로 일정한 초기 비용이 발생할 수 있습니다.
- 관련된 디자인 시스템, 템플릿, 스타일 가이드 등을 학습해야 합니다. 이는 학습 곡선을 필요로 하며, 팀 내에서의 협업과 커뮤니케이션을 강조해야 합니다.
- 원자, 분자, 조직 등 단위 간의 모호한 구분으로 협업을 통해 명확한 기준을 설정하고 모든 컴포넌트를 사전에 디자인해야 하는 복잡한 과정이 필요합니다.
'Experience' 카테고리의 다른 글
| [ Templete ] 경력기술서 (0) | 2023.07.14 |
|---|