필자가 개인적으로 가장 좋아하는 아키텍쳐이다. 지금까지 간단하게 배웠던 아키텍쳐들은 필자가 느끼기에 아래와 같은 장단점을 가졌다고 생각한다.
VIPER
- 구조가 명확하고 View, Interactor, Presenter, Entity, Route 형태로 나뉘어져서 수정할려는 한 부분에 집중할 수 있다.
- 한 부분을 수정할려면 많은 파일들을 수정해야한다. 하지만 이 부분이 컴파일 오류를 만들어줘서 오히려 안정성이 더 있는듯?
- 규모가 커지면 커질수록 Presenter도 커지는 느낌을 지울수가 없다?
- 혼자서 하거나 완전 소규모 형태로 앱을 개발할 때는 적용하기 힘들다. 할 게 너무 많아짐.. 완전 소규모로 개발하는거라면 앱이 빨리 출시되는게 더 중요할텐데…
MVC
- 애플에서 샘플로 MVC 아키텍쳐를 사용한다. 간단하게 앱 만들때 짱임.
- 손쉽게 앱 만들기 좋은 구조.
- 기능이 좀 추가된다면
ViewController에 모든 로직이 들어가져서 다른 개발자가 유지보수하기 힘들다.
MVP
- 위의 MVC 패턴에서 비즈니스 로직을 Presenter에 던져뒀다.
- 직관적인 구조. 대신 View에 따로 데이터가 갱신되었다는 알림을 직접 해주어야한다.
- 한번도 제대로 파보지 않아서 잘 모르겠지만 MVVM에서 데이터 바인딩이 빠진거 같음. 이거랑 MVVM이랑 이름 말고 차이점이 뭐지?
- 구조가 정확하게 잡혀있지 않아 프로그래머 마다 작성 스타일이 다 다름
MVVM
- MVC 패턴에서 비즈니스 로직을 ViewModel에 던져뒀다.
- 직관적인 구조. 대부분 Reactive 프로그래밍을 통해 구현하므로 데이터가 갱신되었다는 알림을 직접 해줄 필요 없다.
- Reactive 프로그래밍을 모른다면 MVP 패턴으로 이름이 둔갑할듯.
- 구조가 정확하게 잡혀있지 않아 프로그래머 마다 작성 스타일이 다 다름
여기까지 필자가 간단하게 공부했던 아키텍쳐 장단점인데, 필자는 주로 혼자 작업했기에 MVVM 패턴을 사용하고 있다.
하지만 최근에 모듈화를 하는 과정에 관심을 가졌고, 관련 글을 찾아보니 MVVM에 패턴에 클린 아키텍쳐를 접목시켜 모듈화를 한 게시글을 보았다.
보자마자 바로 샘플 앱을 만들었는데 손쉽게 모듈로도 분리할 수 있어서 나중에 협업을 하게 된다면 무조건 채택할듯..
일단 샘플 앱의 구조를 보자. Application에 어플의 중요한 부분을 구성해두었고, Presentation에는 각 화면별 모듈이 포함되어있다.
그리고 이건 따로 모듈로 분리했던 화면인데 폴더가 뭔가 많지만 별 거 없다.
- Network의 경우에는 네트워크 통신 부분과 통신을 통해 받은 데이터를 DTO로 변환하는 기능이 포함되어있다.
- Domain 폴더의 겨우 Entities, Interfaces, UseCases 로 분리되어있다. Entities에는 전송할 데이터의 구조체를 포함하고 있고, Interface에는 네트워크 통신의
protocol이 구현되어있다. 나중에 유닛테스트할때 해당 프로토콜을 기준으로 목업 네트워크 서비스를 만들어서 테스트하면된다. UseCases의 경우 터치 액션이 들어올시에 네트워크 통신을 호출하는 함수를 호출해두었다. - Presentation은 화면에 관한 기능이 포함되어있다. 비즈니스 로직은 ViewModel에서 처리한다.
- 그리고 마지막의
MainSceneDIContainer의 경우는 해당 화면의 의존성(네트워크)등을 주입해준다. 즉, 얘가 엔트리 포인트임
아, 그리고 클린 아키텍쳐를 만드신 분께서는 RxSwift 사용안해도 괜찮다고 하는데, 사용해도 상관은 없다.