Architecture Pattern

만약에 ..구조가 없으면 ?

⇒ 혼돈의 카오스

⇒ 로직 판정, 레이아웃 처리, 데이터 취득, 이벤트 처리 등등을 한 액티비티 안에서 처리

⇒ 스파게티 🍝→ 기능추가 어렵, 가독성 떨어짐

⇒ <악! 더러워!! 코드> 탄생 😵 😣

MVC

---

ref) https://en.wikipedia.org/wiki/Model–view–controller

• Model
  • 데이터와 비즈니스 로직 담당 (UI와 관계 X)
• View 사용자에게 보여지는 UI 화면
  • 모델의 데이터를 표시하거나 Controller로부터 갱신을 받아들이는 UI로직
  • xml 레이아웃이 해당
• Controller
  • View와 Model 사이의 상호작용을 관리
  • 외부에서 전달받은 입력을 처리해서 View의 내용을 갱신하고 표시할 View를 선택해 화면 그리기를 요청하는 Presentation 로직을 가지고 있음

정리

1. MVC 패턴에서는 Model과 View가 완전히 분리되므로 Model은 쉽게 테스트 가능
2. Controller가 안드로이드에 종속되기 때문에 테스트가 어려워짐
3. 안드로이드 특성상 액티비티가 View 표시와 Controller 역할을 같이 수행해야 하기 때문에 두 요소의 결합도가 높아짐
4. 많은 코드가 Controller로 모이게 되어 액티비티가 비대해짐

MVP (MVC를 보완)

---

ref) https://en.wikipedia.org/wiki/Model–view–presenter

• Model
  • View와의 직접적인 의존성이 사라지고 Presenter가 중간에서 관리함
• View
  • 온전한 View로 간주됨
  • Model 참조가 없어진 대신에 Presenter의 참조가 생김
• Presenter
  • View의 참조를 직접 거치지않고 interface를 통해 교신함으로써 결합이 상대적으로 느슨해짐
  • Controller와는 달리 Android 의존성을 가지지않아 테스트가 용이해짐
• View하고 Model의 참조를 가져서 View로부터 Action을 전달받고 필요한 경우에는 Model로부터 Data를 취득해 결과를 View에 전달

정리

1. View와 Model 사이의 데이터 흐름이 사라지고 Presenter가 중간에서 데이터 흐름을 제어 → 데이터 흐름이 단일해지는 효과를 얻음
2. 인터페이스를 추가로 구현해야 하기 때문에 구현비용이 올라가게 됨
3. View와 Presenter가 1:1로 대응해야 하기 때문에, 앱이 커질수록 두 요소의 의존성이 강해지게 됨

MVVM

---

ref)https://en.wikipedia.org/wiki/Model–view–viewmodel

• Model
  • MVC의 모델과 동일한 역할
• View
  • 사용자에게 보여지는 UI
  • 데이터바인딩을 통해 ViewModel로부터 일방적으로 통지받은 데이터를 표시하는 역할만 함
  • Observing을 통해 UI를 갱신할 수 있음
• ViewModel
  • View를 만들기 위해 필요한 로직을 가짐
  • View를 참조하지 않아 1:N 관계 가능 → 중복되는 코드를 묶어서 작성 가능

정리

1. View와 Model 사이에 의존성이 없으며, ViewModel도 View에 의존성을가지지 않음
2. 참조는 View > ViewModel > Model순으로 단방향으로만 일어남 ⇒ 유지보수가 용이해짐

Android App Architecture

---

ref) https://developer.android.com/jetpack/guide?hl=ko#recommended-app-arch

• Android Architecture Component를 활용해서 MVVM의 핵심가치를 구현한 MVVM like 패턴
• Model은 Room을 통해 구축
• Activity, Fragment는 View로 작동
• View는 ViewModel의 Livedata를 Observing하게 했음 주의) 여기서의 ViewModel은 MVVM의 ViewModel이 아닌 ACC의 특정한 Library인 ViewModel을 의미함
  

2022년에 들어서면서…

ref)https://developer.android.com/topic/architecture?hl=ko

• UI Layer에는 View와 ViewModel이 해당
• DataLayer에는 Repository와 Data Source가 해당
• Domain Layer에는 UseCase가 해당
  • if 없으면.. ViewModel이 비즈니스 로직을 갖고있게 되면서 ViewModel이 비대해지는 문제가 생김 이러한 문제를 해결하기 위해 ViewModel에서 비즈니스 로직만을 분리한 것이 UseCase라고 생각하면 됨
    

Domain Layer의 추가로 Android App Architecture는 기존의 MVVM like 구조보다는 Clean Architecture에 가까워지게 됨

ref) https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

⭐ Android App Architecture는 강제사항이 아닌 권장사항! 해당 Architecture가 반드시 채용되어야하는 정답은 아니며 필요에 따라 Architecture를 선택해 사용하는 것이 좋다!

출처

---

강의

냉동코더의 알기 쉬운 Modern Android Development 입문 강의 - 인프런

출처 : 냉동코더의 알기 쉬운 Modern Android Development 입문

코드

https://github.com/cliearl/book-search-app

Designed and developed by 2022 FrozenCoder

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

   http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

썸네일 사진

Unsplash의Mohamed Nohassi