일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 |
- Flutter #Stream #dart
- 희망적금전환
- 도약전환
- Flutter #Stream
- 도약계좌전환
- 희망적금연계
- flutter #dart #stream
- 플러터 #안드로이드 #플레이콘솔 #앱내리기
- 안드로이드 #코틀린 #코루틴 #콜백 #채널
- 조립 후 재부팅
- 도약연계
- 청년도약계좌환승
- Today
- Total
Flutter 개발 상자
Controller vs Service 플러터와 Nest.js 관점에서 역할 생각해보기 본문
플러터의 경우
사실 플러터는 공식 아키텍처라는게 없다.
그래서 Controller라는 레이어를 아예 안가져가는 경우도 많다.
Controller는 주로 MVC 패턴에서 자주쓰이지만, 앱개발쪽은 이제 MVC 패턴은 아예 안쓰는 추세다
그래도 Controller를 사용한다면
View단에서 사용자의 인터렉션을 받고 처리하는 부분이 Controller 레이어라고 할 수 있다.
여기서 유의해야할점은 실질적으로 서버와 통신하거나 Global상태를 변경하는 로직을 Controller단에 작성하면 안된다는것이다.
Controller에서는 필요할경우 로컬 상태를 변경해주고, 요청에 맞는 서비스 로직을 실행해주는 역할을 한다.
나같은 경우에는 Controller를 따로 두지 않고 hook이나 stf위젯 내부에 함수를 작성하는 편이고, 위젯을 최대한 분리하여 재사용성을 높이는걸 선호하는 편이다.
물론 Controller를 둬야할정도로 로직이나 로컬 상태관리 변수가 많은 위젯의 경우 Controller를 만드는게 낫다.
Service로직의 경우 실질적으로 요청에 맞는 로직을 수행하는 영역이다. 하지만 이부분에서 직접적으로 백엔드와 통신하는 코드는 넣지 않는다. 백엔드 통신은 보통 Repository 레이어에서 수행한다. Services는 Repository 레이어의 함수를 호출하고, 그 결과물을 앱에서 사용하기 좋게 데이터를 가공한다. Global 상태관리가 이곳에서 수행된다.
Nest.js의 경우
Nest.js의 경우 어느정도 정해진 아키텍처를 제공하기 때문에 Controller와 Service의 역할이 명확하게 구분되어있다고 볼 수 있다.
Controller는 사용사의 요청이 들어오는 Path를 정의하고 요청이 들어왔을때 요청에 맞는 함수를 찾아 실행해주는 문지기 역할을 해준다.
플러터와 유사하게 Controller에서 직접적인 데이터 변경 로직은 수행하지 않는다.
Service는 데이터를 다루는 로직이 들어가는 레이어이다.
기본적으로 NestJS의 Module에서 provider로 들어가게되는데 이는 다른 영역에서 Service 인스턴스를 별도로 생성하지 않고 사용할 수 있도록 도와준다.
'Flutter' 카테고리의 다른 글
[Flutter] SQFlite -> Drift 마이그레이션 후기 (0) | 2024.12.04 |
---|---|
[Flutter] GoRouter를 버리고 AutoRouter를 선택하겠습니다. (1) | 2024.08.09 |
[2024/3/13 기준] 구글 네비게이션을 앱에서도 사용할 수 있을까? (0) | 2024.03.13 |
[Flutter] @pragma('vm:entry-point') 이란 무엇을 뜻하는가? (2) | 2024.02.08 |
[Flutter] Riverpod의 Provider에서 BuildContext를 매개변수로 받으면 안되는가? (1) | 2024.01.22 |