아키텍처를 알아야 앱 개발이 보인다 - 1

1. 앱 설계 원칙 SOLID

1. 단일 책임 원칙 :

• 모든 클래스가 하나의 책임만 가지고, 그 책임은 완전히 캡슐화 해야함.
• 어떤 클래스나 모듈 또는 메소드는 단 하나의 기능만 가져야한다
• 예를 들면, 특정 데이터를 분석하고 서버에 전송하는 모듈 -> (a) 특정 데이터 분석, (b) 서버 전송 같이 분리.

2. 개방 폐쇄 원칙

• 확장에는 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다는 원칙. ???
• 기능 변경과 확장할 수 있으면서, 사용하는 코드는 수정하지 않는다.
• 상속이나 인터페이스를 통해 기능은 확장하되 코드를 수정하지 않는걸 의미하는듯 
• 예를 들어 차가 있고 트럭, 택시 이런식으로 있다고 한다면 트럭이나 택시가 차를 상속받아서 쓰고 트럭이나 택시별로 차가 가지고 있는 메소드나 기능을 더 구현시켜 확장을하되 차라는 클래스 자체는 코드 변화 없이 놔두는거???

3. 리스코프 치환 원칙

4. 인터페이스 분리 원칙

5. 의존 역전 원칙

 

이 내용들은 추후 조금더 자세히 다루기로.....

 

2. 클린 아키텍처 -  이부분도 일단 생략....

3. 안드로이드 애플리케이션 설계 원칙

• 액티비티와 프래그먼트의 클래스 의존성을 최소화
• 관심사 분리 (관심사 : 어떠한 상태나 데이터에 영향을 미치는 정보의 집합니다)
• 클래스간의 의존성을 낮춰서 모듈화 시킨다.

4. 권장하는 애플리케이션 설계

(1) Activity나 Fragment는 ViewModel만을 참조한다. 그래서 ViewModel에서 하위 계층의 의존성이 어떻게 변경되건 Activity와 Fragment는 상관없음.

 

(2) ViewModel은 Repository라는 저장소를 참조. 이 저장소로 부터 UI 컴포넌트가 화면을 구성하는 데 필요한 데이터를 불러온다. 데이터를 불러와 LiveData라는 데이터의 변화를 감지할 수 있는 형태로 관리한다.

 

(3) 저장소는 두가지 타입의 모델을 참조한다. 내부 모델(네트워크 x), 원격 모델(네트워크 O)

 

(4) 내부 모델은 SQLite나 Room 또는 Realm.  원격 모델은 Http통신, Okhttp, Retrofit과 같은 라이브러리가 될수도 있음.  

(Realm?????) 좀더 자세히...

Realm은 오픈 소스 라이브러리로 모바일에 최적화된 데이터베이스 라이브러리이다.

• 쿼리문을 통해 테이블내 컬럼에 데이터를 저장하는 SQLite의 방식과 달리, 데이터를 객체 형태로 저장합니다.
• 크로스 플랫폼 데이터베이스로 Android, iOS 간 DB 공유가 가능합니다.
• 타 데이터베이스들에 비해 데이터 처리 속도가 빠릅니다.

 

내부 모델 또는 원격 모델을 통해 얻은 데이터는 ViewModel에 관리하며, 데이터의 변경이 감지되는 대로 UI 컴포넌트의 바인딩된 뷰에 나타낸다. 서버에서 얻은 데이터는 데이터 베이스에 저장하여 불러온다. 

 

ViewModel이라는 것은 내부 데이터베이스만을 항상 참조하고, 클라이언트의 데이터베이스와 서버의 데이터베이스가 요청으로 비동기적으로 동기화한다.  이렇게 되면 오프라인이나 네트워크가 약한 상태에서도 애플리케이션이 원할하게 동작. 

 

 

디자인 패턴 

 

MVC (Model - View - Controller) : 

• Model : 데이터를 다루는 영역이다. 일반적인 비지니스 데이터는 DBMS(Database Management System)의해 관리, 안드로이드에서는 데이터베이스의 Entity를 담당하는 POJO 클래스를 포함한 SQLite, Room, Realm 등이 될 수도 있다.

POJO (Plain Old Java Object) :

POJO란, 객체 지향적인 원리에 충실하면서 환경과 기술에 종속되지 않고 필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트를 말한다. 그러한 POJO에 애플리케이션의 핵심로직과 기능을 담아 설계하고 개발하는 방법을 POJO 프로그래밍이라고 할 수 있다.

• View : 사용자에게 표현되는 영역 (Activity, Fragment)
• Controller : 모델 뷰에 의존. 뷰로부터 입력을 받거나 특정 이벤트가 발생할 때 모델 또는 뷰 변경. Activity와 Fragment는 뷰와 컨트롤러 역할 동시에 수행.

MVC 장점 :

• 직관적 : 구조가 단순해서 MVC를 잘 모르더라도 쉽게 받아들이고 적용 가능.  (모델에서 데이터를 얻고 뷰로 표현. 이것을 컨트롤러가 중개)
• 규모가 작은 앱에서는 MVC 적용시 개발기간 단축.

MVC 단점:

• 앱의 규모가 크면 Activity와 Fragment이 비대해짐. -> 그에 따라 유지보수가 힘듬
• 컨트롤러는 뷰와 모델에 의존적, 뷰는 모델에 의존적이라 -> Unit Test가 거의 불가능.
• 실제로는 View에서 Model을 이용하기 때문에 View와 Model은 의존적임.
  

 

MVP (Model - View - Presenter) : 

• MVC와는 다르게 Presenter를 이용해 UI와 비지니스 로직을 분리하는데 집중. -> Unit Test 가능.

MVP 장점 :

• View Model 의존성 내림
• 그로인해 유닛테스트 수월

MVP 단점 : 

• View와 Presenter의 의존성이 높음
• View와 Presenter가 1:1 관계여서 재사용불가. View가 늘어 날수록 Presenter가 늘어남.

 

MVVM (Model - View - ViewModel) : 

• 기존의 MVC, MVP와는 다르게 View가 직접 ViewModel로부터 Databinding을 통해 데이터를 가져옵니다 (데이터 자동 갱신).
• Command와 Data Binding을 통해 View의 의존성을 끊어버렸습니다.
• MVVM 모델은 MVP 모델과 같이 View에서 입력이 들어옵니다.입력이 들어오면 Command 패턴을 통해 ViewModel에 명령을 내리게 되고 ViewModel은 Model에게 필요한 데이터를 요청합니다.Model은 ViewModel에 필요한 데이터를 응답하고 Data Binding을 통해 ViewModel의 값이 변화하면 바로 View의 정보가 바뀌게 됩니다.