오늘은 Data Model과 Repository 에 대해서 설명합니다.
설명과 함께 구현하는 코드는 github repository에 있고 본 글은 commit 0126e41기준입니다.
먼저 지금 만들고 있는 Idea Note의 Class Diagram을 그려봤습니다.
앞서 Chapter #5 BLOC에서 설명했던 아래 구조대로 BLOC와 Data로 구분되어 있음을 알 수 있습니다.
위 Class Diagram에는 UI는 없지만 UI가 IdeaBloc와 Interfacing을 함으로써 추가될 거라는 것을 알 수 있습니다.
Data Model
이 부분은 간단합니다.
Idea는 unique한 id가 있고 title, role, goal, value 그리고 created된 시간을 갖습니다.
Repository
우선 여기서 사용하는 SharedPreference는 library를 import한것입니다.
pubspec.yaml에 다음을 먼저 추가해주세요.
shared_preferences: ^0.5.12+4
코드 설명 들어갑니다.
- ideas을 갖도록 합니다.
- CURD를 할 수 있는 Interface들입니다. getList는 ideas가 Map이라서 value의 iterator 형태가 필요할 경우를 위해서 만들었습니다.
- fetch, save는 물리적 저장소에 저장하는 Interface입니다.
- 일단 지금은 단말내에만 data를 저장하도록 Android의 SharedPreference를 사용합니다. 여기만 rest api등으로 바꾸면 server의 database으로 변경할 수 있겠죠? 또는 여기를 Proxy패턴을 사용하도록 하면 Network 연결 여부에 따라 서버와 단말에 저장 영역을 달리 할 수 있습니다.
- Platform이나 Network과 같이 다른 Component와 통신함으로써 async한 상황이 생기는 경우 Future를 사용해야 합니다.
BLOC
다시 Bloc로 돌아가 mapEventToState 를 확인해보겠습니다.
- IdeaEventFetching Event인 경우 repository로부터 물리적 저장소로부터 data를 fetching하도록 합니다. 그리고 state를 IdeaStateFetched로 정해줍니다.
- Event가 IdeaEventSaving일 경우를 처리하죠.
- Event가 IdeaEventDeleting일 경우를 처리합니다.
쉽죠?
마치며
각 객체는 최대한 자신의 역할에 집중할 수 있어야 합니다.
IdeaRepository는 Data Model을 handling하고 data를 UI에 Providing하는 역할을 합니다.
그 역할에 집중할 수 있도록 설계하여 구현해봤습니다.
다음은 이 Repository로부터 data를 제공받아 UI로 표현해주는 것을 설명합니다.
제가 UI부터 설명하지 않고 Business Logic Component와 Data Repository부터 설명하는 이유는 UI는 언제든지 User의 요구에 따라 변경할 수 있어야 하고 이를 위해서는 Business Logic Component와 Data Repository가 엄격히 분리되어 있어야 하고 구조가 잘 잡혀 있어야지 가능한 일이기 때문입니다.