예제에서는 알려주지 않는 Model 이야기.

in 07/11/2019 Naver Mobile Tech Concert

Transcript

2. Rainist | 김범준 예제에서는알려주지않는Model이야기
3. 3BJOJTU
4. !
5. M
6. MVC
7. MVP
8. MVVM
9. MVI
10. Metc..
11. MODEL
12. MODEL 역할 분리
13. 모델(model)이란 어떠한 동작을 수행하는 코드를 말한다. 표시 형식 에 의존하지 않는다. 다시 말해, 사용자에게 어떻게 보일지에 대해 신 경쓰지 않아도 된다. 모델은 순수하게 public 함수로만 이루어진다. 몇몇 함수들은 사용자의 질의(query)에 대해 상태 정보를 제공하고 나머지 함수들은 상태를 수정한다. Definition of Wikipedia (MVC)
14. 모델(model)이란 어떠한 동작을 수행하는 코드를 말한다. 표시 형식 에 의존하지 않는다. 다시 말해, 사용자에게 어떻게 보일지에 대해 신 경쓰지 않아도 된다. 모델은 순수하게 public 함수로만 이루어진다. 몇몇 함수들은 사용자의 질의(query)에 대해 상태 정보를 제공하고 나머지 함수들은 상태를 수정한다. Definition of Wikipedia (MVC)
15. 간단하게.. 데이터베이스, API를 통해 데이터를 불러오고 저장하는 역할. 서비스의 비지니스 로직(도메인)을 담당.
16. 간단하게.. 데이터베이스, API를 통해 데이터를 불러오고 저장하는 역할. 서비스의 비지니스 로직(도메인)을 담당.
17. 간단하게.. 데이터베이스, API를 통해 데이터를 불러오고 저장하는 역할. 서비스의 비지니스 로직(도메인)을 담당.
18. 그래서 오늘 하고싶은 이야기는 Model의 역할(책임)에 따른 분리 과정
19. Model의 역할(책임)에 따른 분리 과정 Model
20. Model의 역할(책임)에 따른 분리 과정 Model Domain Data Source
21. 김신입의 좌충우돌 개발기(Review) ૓೯ߑध 코드 작성 -> Review -> 리뷰 반영.
22. 이름 : 김신입 경력 : 신입 부연 설명 : 신입 드디어 원하던 회사에 입사하게된 김신입. 들어온지 얼마 안되어 피쳐를 맡게 된다. 서비스의 코드 구조는 MVP이며 김신입도 이에대한 경험이 있어 자신만만이다. 즐겁게 개발을 하는 신입씨. 그렇게 리뷰의 시간이 다가오는데…. Profile
23. Model View Presenter Early
24. View Presenter Result Data Source Model
25. View Presenter Result Domain Data Source Model
26. 목차 #1. Repository Pattern을 사용하라! #2. Business Logic을 분리하라! #3. Exception handling
27. Repo : https://github.com/omjoonkim/GitHubBrowserApp
28. #1 #1. Repository Pattern을 사용하라!
29. #1 #1. Repository Pattern을 사용하라! branch : model_v1
30. #1 Repository Pattern을 사용하라! - 예제 Github Api : Repo
31. #1 #1 Repository Pattern을 사용하라! - 서버통신을 위한 Retrofit object ApiClient { val githubBrowserService: GithubService init { githubBrowserService = makeGithubBrowserService(…) } fun makeGithubBrowserService(): GithubService {…} private fun makeGithubBrowserService(…): GithubService {…} private fun makeOkHttpClient(…) :OkHttpClient{…} private fun makeLoggingInterceptor(…): HttpLoggingInterceptor {…} }
32. #1 #1 Repository Pattern을 사용하라! - 서버통신을 위한 Retrofit object ApiClient { val githubBrowserService: GithubService init { githubBrowserService = makeGithubBrowserService(…) } fun makeGithubBrowserService(): GithubService {…} private fun makeGithubBrowserService(…): GithubService {…} private fun makeOkHttpClient(…) :OkHttpClient{…} private fun makeLoggingInterceptor(…): HttpLoggingInterceptor {…} }
33. #1 #1 Repository Pattern을 사용하라! - MODEL object RepoDetailModel { fun getRepo(userName: String, id: String) :Repo = ApiClient.githubBrowserService.getRepo( userName, id ) }
34. #1 #1 Repository Pattern을 사용하라! - MODEL object RepoDetailModel { fun getRepo(userName: String, id: String) :Repo = ApiClient.githubBrowserService.getRepo( userName, id ) }
35. #1 #1 Repository Pattern을 사용하라! - PRESENTER class RepoDetailPresenter( view: RepoDetailView ) : BasePresenter<RepoDetailView>(view) { fun onCreate(userName: String, repoName: String) { val repo = RepoDetailModel.getRepo(userName, repoName) view.setName(repo.name) view.setDescription(repo.description ?: "") view.setStarCount(repo.starCount) } }
36. #1 #1 Repository Pattern을 사용하라! - PRESENTER class RepoDetailPresenter( view: RepoDetailView ) : BasePresenter<RepoDetailView>(view) { fun onCreate(userName: String, repoName: String) { val repo = RepoDetailModel.getRepo(userName, repoName) view.setName(repo.name) view.setDescription(repo.description ?: "") view.setStarCount(repo.starCount) } }
37. #1 Repository Pattern을 사용하라! - Review Review !
38. #1 Repository Pattern을 사용하라! - Review Review ! Repository Pattern을 적용해보는게 어때요? &
39. #1 Repository Pattern을 사용하라! - Repository? Repository?
40. Data #1 Repository Pattern을 사용하라! - Repository? 디자인 패턴중의 하나 데이터 불러오는 로직을 분리시켜 관리 하는것이 목적 추상화를 통해 테스트에 용이해진다. 하나의 Repository는 하나의 Domain을 담당한다.
41. Data #1 Repository Pattern을 사용하라! - Repository? 디자인 패턴중의 하나 데이터 불러오는 로직을 분리시켜 관리 하는것이 목적 추상화를 통해 테스트에 용이해진다. 하나의 Repository는 하나의 Domain을 담당한다. branch : model_v1_resolve
42. #1 #1 Repository Pattern을 사용하라! - Repository class RepoRepositoryImpl( private val api : GithubService ) : RepoRepository { override fun getRepo(userName: String, id: String): Repo = api.getRepo(userName, id) }
43. #1 #1 Repository Pattern을 사용하라! - Repository class RepoRepositoryImpl( private val api : GithubService ) : RepoRepository { override fun getRepo(userName: String, id: String): Repo = api.getRepo(userName, id) }
44. #1 #1 Repository Pattern을 사용하라! - Repository class RepoRepositoryImpl( private val api : GithubService ) : RepoRepository { override fun getRepo(userName: String, id: String): Repo = api.getRepo(userName, id) }
45. #1 #1 Repository Pattern을 사용하라! - Repository interface RepoRepository { fun get(userName: String, id: String): Repo }
46. #1 #1 Repository Pattern을 사용하라! - PRESENTER class RepoDetailPresenter( view: RepoDetailView, private val repoRepository: RepoRepository ) : BasePresenter<RepoDetailView>(view) { fun onCreate(userName: String, repoName: String) { val repo = repoRepository.getRepo(userName, repoName) view.setName(repo.name) view.setDescription(repo.description ?: "") view.setStarCount(repo.starCount) } }
47. #1 #1 Repository Pattern을 사용하라! - PRESENTER class RepoDetailPresenter( view: RepoDetailView, private val repoRepository: RepoRepository ) : BasePresenter<RepoDetailView>(view) { fun onCreate(userName: String, repoName: String) { val repo = repoRepository.getRepo(userName, repoName) view.setName(repo.name) view.setDescription(repo.description ?: "") view.setStarCount(repo.starCount) } }
48. #1 Repository Pattern을 사용하라! - Source Source 데이터를 불러올 수 있는 모든 외부 Server(Http, socket), Local(db, cache) 현재 예제에서는 Http만 사용하기 때문에 나누지 않음.
49. #1 Repository Pattern을 사용하라! - 정리 Model -> Repository Pattern(추상화) 적용. 추상화를 통하여 테스트가 용이해지게 되었다.
 (GitHubApiService, RepoRepository) ( 데이터를 불러오고 처리하는 역할을 분리.
50. #2 #2. Business Logic을 분리하라!
51. #2 #2. Business Logic을 분리하라! branch : model_v2
52. #2 Business Logic을 분리하라! - 지금까지의 줄거리 View Presenter Data Source Model
53. #2 Business Logic을 분리하라! - 기능 추가 Fork
54. #2 Business Logic을 분리하라! - 기능 추가 Fork Business Logic 추가.
55. #2 Business Logic을 분리하라! - Business Logic 유저의 행동에 따라 서비스에서 보여주고자 하는 결과를 나타내기 위해 데이터를 가공하는 로직
56. #1 #2 Business Logic을 분리하라! - ForkRepository class ForkRepositoryImpl( private val api: GithubService ) : ForkRepository { override fun gets(userName: String, id: String): List<Fork> = api.getForks(userName, id) }
57. #1 #2 Business Logic을 분리하라! - PRESENTER class RepoDetailPresenter( view: RepoDetailView, private val repoRepository: RepoRepository, private val forkRepository: ForkRepository ) : BasePresenter<RepoDetailView>(view) { fun onCreate(userName: String, repoName: String) { val repo = repoRepository.get(userName, repoName) val forks = forkRepository.gets(userName, repoName) view.setName(repo.name) view.setDescription(repo.description ?: "") view.setStarCount(repo.starCount) view.refreshForks(forks) } }
58. #1 #2 Business Logic을 분리하라! - PRESENTER class RepoDetailPresenter( view: RepoDetailView, private val repoRepository: RepoRepository, private val forkRepository: ForkRepository ) : BasePresenter<RepoDetailView>(view) { fun onCreate(userName: String, repoName: String) { val repo = repoRepository.get(userName, repoName) val forks = forkRepository.gets(userName, repoName) view.setName(repo.name) view.setDescription(repo.description ?: "") view.setStarCount(repo.starCount) view.refreshForks(forks) } }
59. #1 #2 Business Logic을 분리하라! - PRESENTER class RepoDetailPresenter( view: RepoDetailView, private val repoRepository: RepoRepository, private val forkRepository: ForkRepository ) : BasePresenter<RepoDetailView>(view) { fun onCreate(userName: String, repoName: String) { val repo = repoRepository.get(userName, repoName) val forks = forkRepository.gets(userName, repoName) view.setName(repo.name) view.setDescription(repo.description ?: "") view.setStarCount(repo.starCount) view.refreshForks(forks) } }
60. Review ! #2 Business Logic을 분리하라! - Review!
61. Review ! #2 Business Logic을 분리하라! - Review! Business Logic을 분리해보시겠어요? &
62. #1 #2 Business Logic을 분리하라! - Business Logic class RepoDetailPresenter( view: RepoDetailView, private val repoRepository: RepoRepository, private val forkRepository: ForkRepository ) : BasePresenter<RepoDetailView>(view) { fun onCreate(userName: String, repoName: String) { val repo = repoRepository.get(userName, repoName) val forks = forkRepository.gets(userName, repoName) view.setName(repo.name) view.setDescription(repo.description ?: "") view.setStarCount(repo.starCount) view.refreshForks(forks) } }
63. #1 #2 Business Logic을 분리하라! - Business Logic fun onCreate(userName: String, repoName: String) { Single.zip( repoRepository.get(userName, repoName), forkRepository.gets(userName, repoName), BiFunction { t1: RepoModel, t2: List<ForkModel> -> t1 to t2 } ).subscribe({ (repo, forks) -> view.setName(repo.name) view.setDescription(repo.description ?: "") view.setStarCount(repo.starCount) view.refreshForks(forks) }, ::printStackTrace) }
64. #2 Business Logic을 분리하라! - Business Logic Business Logic을 분리해야 하는 이유?
65. #2 Business Logic을 분리하라! - Business Logic Business Logic을 Presentation Logic에서 분리해야 하는 이유? 복잡한 화면일수록 Presentation의 코드가 커지게 된다. 그럴수록 복잡성이 증대. 유지보수성 저하 됨. Presentation의 역할을 분리해줄 필요성이 생김. Presentation에서 Business Logic을 분리. Presentation에 집중하게한다. 물론 작은 서비스, 화면, Platform에 따라 분리하지 않아도 괜찮긴 함.
66. #2 Business Logic을 분리하라! - Business Logic Business Logic을 Presentation Logic에서 어떻게 분리? Service? UseCase?
67. #2 Business Logic을 분리하라! - Service Service Layer Pattern (n-tier, 3-layer에서 파생). MSA, 작은 서비스에서 쓰일 때 유용함. 혹은 설계가 짜임새있게 되어 있어야 한다. 완벽하게 Presentation에서 Logic을 분리하기 어렵기 때문. 또한 유지보수에 있어 어려움이 있을 수 있다. Business Logic의 집합소 개념. 재사용이 용이하다.
68. #2 Business Logic을 분리하라! - Service Service Service Service Service Repository Repository Repository
69. #2 Business Logic을 분리하라! - UseCase 서로(UseCase)에게 독립적. 즉, Business Logic들 간의 의존성이 X Service와 마찬가지로 설계가 중요. 유지보수, 변경등의 비용이 저렴하다. 하나의 유저행동에 대한 서비스(Application)의 Business Logic이 담겨있는 객체.
70. #2 Business Logic을 분리하라! - UseCase UseCase Repository Repository Repository
71. #2 Business Logic을 분리하라! - UseCase를 잘못 사용하는 경우. UseCase를 Repository처럼 사용하는 경우. UseCase를 Service처럼 사용하는 경우. (강조) 보통의 경우에는 유저의 행동(Business Logic)과 1:1로 매칭된다. (강조)
72. #1 #2 Business Logic을 분리하라! - UseCase Template abstract class SingleUseCase<T, in Params>( private val schedulersProvider: SchedulersProvider ) { protected abstract fun buildUseCaseSingle( params: Params ): Single<T> fun get(params: Params) = buildUseCaseSingle(params) .subscribeOn(schedulersProvider.io()) .observeOn(schedulersProvider.ui()) }
73. #1 #2 Business Logic을 분리하라! - UseCase Template abstract class UseCase<T, in Params> { protected abstract fun buildUseCase(params: Params): T fun get(params: Params) = buildUseCase(params) }
74. #1 #2 Business Logic을 분리하라! - Business Logic class GetRepoDetail( private val repoRepository: RepoRepository, private val forkRepository: ForkRepository, schedulersProvider: SchedulersProvider ) : SingleUseCase<Pair<Repo, List<Fork>>, Pair<String, String>>( schedulersProvider) { override fun buildUseCaseSingle(params: Pair<String, String>) : Single<Pair<Repo, List<Fork>>> = Single.zip( repoRepository.get(params.first, params.second), forkRepository.gets(params.first, params.second), BiFunction { t1: Repo, t2: List<Fork> -> t1 to t2 } ) }
75. #1 #2 Business Logic을 분리하라! - Business Logic class GetRepoDetail( private val repoRepository: RepoRepository, private val forkRepository: ForkRepository ) : UseCase<Pair<Repo, List<Fork>>, Pair<String, String>>() { override fun buildUseCase( params: Pair<String, String> ): Pair<Repo, List<Fork>> { val repo = repoRepository.get(params.first, params.second) val forks = forkRepository.gets(params.first, params.second) return repo to forks } }
76. #1 #2 Business Logic을 분리하라! - Business Logic class GetRepoDetail( private val repoRepository: RepoRepository, private val forkRepository: ForkRepository ) : UseCase<Pair<Repo, List<Fork>>, Pair<String, String>>() { override fun buildUseCase( params: Pair<String, String> ): Pair<Repo, List<Fork>> { val repo = repoRepository.get(params.first, params.second) val forks = forkRepository.gets(params.first, params.second) return repo to forks } }
77. #1 #2 Business Logic을 분리하라! - Presentation class RepoDetailPresenter( view: RepoDetailView, private val getRepoDetail: GetRepoDetail ) : BasePresenter<RepoDetailView>(view) { fun onCreate(userName: String, repoName: String) { val (repo, forks) = getRepoDetail.get(userName to repoName) view.setName(repo.name) view.setDescription(repo.description ?: "") view.setStarCount(repo.starCount) view.refreshForks(forks) } }
78. #1 #2 Business Logic을 분리하라! - Presentation class RepoDetailPresenter( view: RepoDetailView, private val getRepoDetail: GetRepoDetail ) : BasePresenter<RepoDetailView>(view) { fun onCreate(userName: String, repoName: String) { val (repo, forks) = getRepoDetail.get(userName to repoName) view.setName(repo.name) view.setDescription(repo.description ?: "") view.setStarCount(repo.starCount) view.refreshForks(forks) } }
79. #2 Business Logic을 분리하라! - 정리 Presentation에서 Business Logic을 분리. ( Domain 시스템이 복잡해져도 유연하게 대처할 수 있게 되었다.
80. #3 #3. Exception handling
81. #3 #3. Exception handling branch : model_v3
82. #3 Exception handling - 지금까지의 줄거리 View Presenter Domain Data Source Model
83. #3 Exception handling - 예제 HttpNetworkException 403 Forbidden Rate Limit Toast Api call
84. #1 #3 Exception handling - Presenter fun onCreate(userName: String, repoName: String) { getRepoDetail.get( userName to repoName ).subscribe({ (repo, forks) -> … }, ::handleException) } private fun handleException(throwable: Throwable) { when (throwable) { is HttpException -> { if (throwable.code() == 403) view.toastRateLimitError() else view.toastNetworkError() } else -> view.toastUnexpectedError() } } }
85. #1 #3 Exception handling - Presenter fun onCreate(userName: String, repoName: String) { getRepoDetail.get( userName to repoName ).subscribe({ (repo, forks) -> … }, ::handleException) } private fun handleException(throwable: Throwable) { when (throwable) { is HttpException -> { if (throwable.code() == 403) view.toastRateLimitError() else view.toastNetworkError() } else -> view.toastUnexpectedError() } } }
86. #3 Exception handling - Review Review !
87. #3 Exception handling - Review Review ! Business Logic이 분리되지 않았어요. &
88. #1 #3 Exception handling - Business Logic fun onCreate(userName: String, repoName: String) { getRepoDetail.get( userName to repoName ).subscribe({ (repo, forks) -> … }, ::handleException) } private fun handleException(throwable: Throwable) { when (throwable) { is HttpException -> { if (throwable.code() == 403) view.toastRateLimitError() else view.toastNetworkError() } else -> view.toastUnexpectedError() } } }
89. #3 Exception handling - Business Logic Presenter의 Exception Handling이 Business Logic인 이유. HttpException, 403 code 체킹은 Presentation로직이 아니다. Presenter에선 Http, 403등에 대한 개념을 모르기 때문. 또한 유저의 행동에 따라 발생하는 예외 상황이기 때문에 Business Logic으로 볼 수 있다. 그러나 관점에 따라서는 다르게 처리 하는 방법도 있을 수 있다.
90. #3 Exception handling - Resolve HttpNetworkException 403 Forbidden Rate Limit Toast Api call Business Logic Convert to using in domain
91. #3 Exception handling - Resolve Presenter Domain Data Source Convert to using in domain Business Logic
92. #1 #3 Exception handling - Source override fun getForks( userName: String, id: String ): Single<List<Fork>> = githubBrowserAppService .getForks(userName, id) .map { it.map { forkEntityMapper.mapFromRemote(it) } } .composeDomain() internal fun <T> Single<T>.composeDomain() = compose(NetworkExceptionSingleTransformer()) Single.error( if (it is HttpException) NetworkException(it.message(), it.code()) else it )
93. #1 #3 Exception handling - UseCase override fun buildUseCaseSingle(params: Pair<String, String>) : Single<Pair<Repo, List<Fork>>> = Single.zip( repoRepository.getRepo(params.first, params.second), forkRepository.getForks(params.first, params.second), BiFunction { t1: Repo, t2: List<Fork> -> t1 to t2 } ).onErrorResumeNext { if (it is NetworkException && it.code == 403) Single.error(RateLimitException()) else Single.error(it) }
94. #1 #3 Exception handling - Presenter private fun handleException(throwable: Throwable) { when(throwable){ is RateLimitException -> view.toastRateLimitError() is NetworkException -> view.toastNetworkError() else -> view.toastUnexpectedError() } }
95. #3 Exception handling - 정리 Exception Handling도 Business Logic으로 볼 수 있다. 도메인(UseCase)에서 사용할 수 있도록 관련된 곳 (Data)에서 Exception을 변환 해주어야 할 필요가 있다. (
96. Conclusion View Presenter Model
97. Conclusion View Presenter Data Source Model
98. ] View Presenter Domain Data Source Model
99. Conclusion View Clean Architecture
100. …… 오잉 !?
 김신입의 상태가 ………! Evolution
101. 김사원 (으)로 진화했다! Evolution
102. 김사원 (으)로 진화했다! Evolution Would you Join us?
103. #End Thank you!✨✨✨ https://crosp.net/blog/software-architecture/clean-architecture-part-1-databse-vs-domain/ https://crosp.net/blog/software-architecture/clean-architecture-part-2-the-clean-architecture/ 참고 링크 https://github.com/android10/Android-CleanArchitecture/issues/141 https://groups.google.com/forum/#!msg/clean-code-discussion/mvP_NR2MUPc/wrkHHxzkDQAJ https://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/ https://www.youtube.com/watch?v=Nltqi7ODZTM
104. (
105. (