안드로이와 MVC

뭔가 이름이 거창해서 맨날 고민하던 것들을 깨부셔 줄수있는 획기적인 것이 나오길 바랐는데 그러지는 않았다.

하지만 사실상 알고 있는것들을 한번더 짚어줬고 살짝 모호 했던 것들을 책으로 봤으니 어디가서 이책에 나옴 하고 나의 의견을 강화시킬수 있는정도라고 생각한다.

사실상 나는 안드로이드로 개발을 시작해서 그런지 가장 모호하고 뭐가 분리가되고 이점이 있다는건지 모르겠는 아키텍쳐가 MVC 이다.

하지만 우테코 미션을 통해 콘솔에서 MVC를 구현하는것을 시도 해보았고 여기서 느낀 바로는 뷰로직은 뷰쪽에 도메인로직은 도메인에

각 영역의 범위를 벗어나면 안된다는게 제1 원칙이라고 생각하고 그 두 로직들이 유일하게 침범할수 있는 범위가 컨트롤러이고 컨트롤러가 중간에 중계자 역할을 한다고 생각한다.

결국 도메인을 뷰에서 가져다 쓸수는 있지만 엄연히 이야기한다면 이런거 죄다 분리해야한다고 생각한다.

(안드로이드는 화면이 더럽게 복잡하니까 화면관련 상태값들이 존재해서 더욱 그렇다고 생각한다.)

그리고 의존성의 방향이 제일 중요하지 않는가 라는 생각을한다.

안드로이드의 MVC

안드로이드는 애초에 MVC 를 기본으로 설계되었다고 한다. 사실 모델부분만 잘 나눠준다면 액티비티에 그냥 코드를 갈기면 MVC 비스무리하게 나온다고 생각한다.

하지만 액티비티와 뷰가 세트로 움직여야하는 운명이 오히려 안드로이드에서 MVC가 멀어지게 만드는 주요인 아닌가 싶다. 애초에 컨트롤러를 안드로이드 프레임 워크에서 제공하는

클래스에서 작성해야하므로 컨트롤러의 재활용은 이미 저승으로 가버렸고 그렇다면 남은건 모델뿐인데 이게 의미가 있나? 라는 생각이 든다. 아키텍쳐 회원권 박탈해야한다.

어쨋든 뭐 그래서 이런것들을 여태까지 학습한대로 좀더 좋은 방법으로 사용해본다면 나라면 contract를 이제 만들고 mvc를 만들것같다. MVP 패턴에서 많이들쓰이는(물론 contract가 강제는 아니라고 한다.) 이걸쓴다면 그래도 추상화가 한번되니까 다른 플렛폼이나 어떠한 환경으로 옮겨가도 조금 더 유연하게 대처할수있다고 생각해서(책임주도 개발이 좀 더 다가오는건 보너스) 적용 해볼것같다.

그래서 이책에서는 뭐라고했는가를 정리해보면

모델: 일반적으로 생성하는 커스텀 클래스이며 데이터와 비지니스 로직을 갖는다고 한다.

뷰: 화면에서 볼수있는 것 이라는데 이건 좀 잘못된 것 같다. 화면이 없더라도 액티비티를 제외한 다른 4대 컴포넌트들도 뷰로 분리해야하니까

이런것에 대한 코치님들의 공통적인 분류법

웹과 서버에서 도입된 개념들도 많으니 웹과 서버에서는 어디에 속하는지 생각해보자
세 분류에다가 다 일단 넣는다고 생각해보자 -> 아닌것들이 직관적으로 다가온다.

컨트롤러: 일반적으로 액티비티나 프래그먼트의 서브 클래스라고 한다. -> 여기 여기서도 액티비티나 프래그먼트를 컨트롤러로 써야한다고 반쯤 힘줘서 이야기하고있다.

그리고 전체적으로 프로그램을 대할때 MVC를 적용한다면 모든 클래스는 모델,뷰,컨트롤러 중 하나로 분류된다고 한다. 이것을 생각한다면 뷰,모델,컨트롤러가 한 클래스에 혼재되지 않고 깔끔하게 나누게 될것이다,