esbae

iOS 개발자들이 Combine을 뷰와 뷰모델 간의 데이터바인딩 용도로도 사용하는 것이 Combine이 데이터바인딩을 지원하기 위해 만들어진 것임을 의미하지는 않습니다. RxSwift와 마찬가지로 Combine은 보다 다양한 용도로 사용하는 API입니다.공식문서에는 Combine을 다음과 같이 한 줄로 소개하고 있습니다.Customize handling of asynchronous events by combining event-processing operators.Combine을 굳이 특정 패러다임이나 아키텍처와 연관지어서 설명해야 한다면 MVVM 보다는 리액티브 프로그래밍과 연관지어서 설명하는 것이 타당합니다. 그리고 제가 모르는 내용이 있을수도 있겠지만 리액티브 프로그래밍과 MVVM은 직접적인 관계를 찾기 어렵습니다.

MVVM in iOS - 리액티브 프로그래밍, 자동바인딩과 수동바인딩에서 질문이있습니다

안녕하세요, 진영님.MVC의 본질을 이해하는 것이 도움이 되는 이유는 유저친화적인 애플리케이션을 만들 수 있기 때문이라기 보다는 같은 MVC라는 이름을 가지고 있다고 하더라도, 입력을 받는 것이 뷰인 환경도 있는가 하면 컨트롤러인 환경도 있고, 컨트롤러가 중재자 역할을 하는 환경도 있고, 뷰를 위한 별도의 모델이 존재하거나 전략 패턴, 컴포지트 패턴, 커맨드 패턴, 옵저버 패턴 등 다양한 디자인 패턴을 사용하는 등 수많은 형태의 MVC가 있기 때문입니다. 그럼 이렇게 다양한 형태의 MVC가 존재한다면 자연스럽게 '도대체 MVC라는게 무엇이냐. 이것이 MVC다라고 한마디로 정의내릴 수 있는 것이 있기는 한 것이냐'라는 물음이 생겨날 수 있고 여기에 대한 답이 될 수 있는 것이 모델 계층을 바라보는 시각이 될 수 있는 것입니다. 과거에는 모델이 뷰나 컨트롤러 같은 프레젠테이션 계층과 분리되지 않은 개발환경도 있었는데, 그런 개발방식을 잘못된 분리라고 생각했기 때문에 모델을 프레젠테이션 계층으로부터 분리시키는 것이 중요하다고 생각했고, 개발환경마다 상황에 따른 지엽적인 차이는 있을 수 있지만 이런 원칙을 지킨다면 MVC라고 할 수 있다라는 것을 강조하는 의미로 받아들이시면 되겠습니다.

MVC의 본질에 대한 질문

iOS에서 일반적으로 하위뷰에서 상위뷰로 데이터를 전달할 때는 Delegate 패턴을 사용합니다.<ol><li>PostsViewController에 PostTableViewCellDelegate 프로토콜을 만들어 뷰 간에 처리할 작업을 함수로 명시하고(ex. did~ 처리할 작업을 잘 나타내는 함수명으로 지으시면 됩니다)</li><li>PostsViewController가 이 프로토콜을 구현하도록 만들고</li><li>PostTableViewCell에 delegate라는 프로퍼티를 PostTableViewCellDelegate 타입으로 만든 뒤</li><li>PostsViewController에서 PostTableViewCell을 생성할 때 PostTableViewCell이 가진 delegate 프로퍼티에 자신의 참조(self)를 넘겨주고</li><li>PostTableViewCell에서 어떤 입력이 발생했을 때 delegate의 메서드를 사용해서 동기화하면 되지 않을까 합니다.</li></ol>이렇게하면 하위뷰인 PostTableViewCell이 상위뷰인 PostsViewController를 직접 참조하거나 상위뷰의 뷰모델인 PostsViewModel을 알지 않아도 됩니다. 그리고 의존관계를 쉽게 관리하려면 하나의 뷰모델은 하나의 뷰 컨트롤러에서만 의존하도록 만드는 것이 좋습니다.

MVVM 템플릿2 관련

안녕하세요 이준복님. 별도로 제공되는 강의 자료는 없습니다. 추가로 궁금하신 점 있으시면 편하게 질문해주세요.감사합니다.

강의자료같은게 따로 있나요 ??

안녕하세요.아키텍처 패턴을 공부하다보면 한번쯤은 'MVC랑 MVP랑 MVVM이랑 결국 뭐가 다른거지?'라는 의문에 빠지는게 당연하다고 생각합니다. 국내에서 유명한 회사(ex. 네카라쿠배) 출신 개발자들도 발표하는 내용들을 보면 Passive View를 구현해놓고 MVC나 MVVM이라고 말하는 경우도 많아서 다른 자료들까지 보셨다면 더 혼란스러웠을 것 같습니다.제가 강의에서 설명한 바와 같이 GUI 아키텍처들의 근간에는 PDS라는 사상이 있고, 이 사상에 따라 P를 View로 D를 Model로 환원할 수 있습니다. 여기까지는 대부분이 문제없이 이해하나, 혼란의 원인이 되는 것은 M과 V의 뒤에 붙는 C(Controller), P(Presenter), VM(ViewModel)입니다.제가 강의 내에서 지속적으로 개발환경에 따른 차이를 강조하며 다양한 개발환경에서 존재했던 패턴들을 설명한 내용이 기억나실지 모르겠습니다. 그렇게 했던것은 C, P, VM 간의 차이를 이해하려면 결국 개발환경에 따른 차이를 이해하지 않고서는 그 차이를 구별할 수 없기 때문입니다. 초기에 Controller가 등장했던 Smalltalk 환경에서는 Controller가 유저의 입력장치(마우스, 키보드 등)로부터 들어오는 입력을 해석해주는 Input Controller였습니다. 하지만 Presenter가 등장한 Taligent나 Dolphin 등의 개발환경에서는 Smalltalk와 같은 IC를 도저히 구현할 수 없었기 때문에 다른 형태의 아키텍처를 고안할 수 밖에 없었고, 그 결과 새로운 명칭의 아키텍처가 등장한 것입니다. ViewModel은 WPF를 설계한 아키텍트들의 의도에 맞게 디자이너들이 쉽게 접근할 수 있는 View 개발환경을 만들고, 이것을 어떻게 프로그래머들이 작업한 결과물들과 연결시킬 수 있을까라는 문제의식에서 탄생한 것입니다. 그렇다고 꼭 이름을 바꿔야 했는지, 아니면 다른 문제의식에서 탄생한만큼 이름이 다른 것이 당연하다라고 말해야 할지는 모르겠습니다. 디자이너와 프로그래머가 협업해야 한다면 뷰를 최대한 프로그래밍 지식이 없어도 개발할 수 있는 환경으로 만들어줘야 하며(ex. 마크업 랭귀지), 동시에 프로그래머가 작업해야 하는 별도의 공간을 만들어줘야 합니다. 이렇게 서로 분리된 개발환경을 연결가능하게 만들어주는 것이 데이터 바인딩(Data Binding)입니다. MVVM의 두드러지는 특징이 데이터 바인딩인만큼 이 점을 꼭 기억해주셨으면 합니다.말씀하신 것처럼 해결해야 하는 문제가 많아지면 복잡성은 올라갈 수밖에 없습니다. 이것은 특정 아키텍처 선정만으로는 근본적으로 해소할 수 없는 문제입니다. 다만 아키텍처 패턴이 애플리케이션에 일정한 규칙을 부여함으로써 기존 코드를 파악하거나 새로운 코드를 작성할 때, 어떤 방식으로 되어 있는지 그리고 어떻게 작성해야 하는지 부담을 덜어주는 정도의 역할은 할 수 있습니다.질문에 작성하신 형태만 보고는 MVVM인지 아닌지 파악이 어렵습니다. 일단 전역 상태를 관리하는 용도로 Store를 두는 것은 MVC에 있었던 Dependents와 유사하며 MVVM과는 상관이 없습니다. 그리고 뷰와 관련된 로직을 어디에서 처리하고 있는지는 모르겠습니다만, 만약 해당작업들을 처리하기 위해 ViewModel을 만들어 View와 데이터 바인딩으로 연결한다면 어느 정도는 MVVM과 닮아있다고 말할 수는 있다고 생각합니다. 하지만 여기서도 반드시 고민해보셨으면 하는 것은 UIKit이나 SwiftUI의 뷰(UIViewController, View)를 WPF의 XAML 같은 마크업 랭귀지로 작성된 뷰처럼 개발해야 할 이유가 무엇인가라는 점입니다. 유별나게 iOS 개발자들은 Reactive Programming을 좋아하는 사람들이 많고, 그러한 사람들이 자신들이 개발하는 방식을 MVVM이라고 부르는 경우들을 많이 보곤 합니다. 하지만 본래 MVVM과 Reactive Programming은 상관이 없습니다. Rx도 마찬가지로 마이크로소프트의 개발환경(.NET)에서 만들어진 것이지만 WPF나 Silverlight에서는 MVVM을 구현하기 위해 Rx를 쓰지 않습니다. 게다가 WPF의 아키텍트인 John Gossman은 옵저버 패턴을 활용하는 방식들에 대하여 부정적인 의견을 밝히기도 했습니다. 그런 방식에 부정적이었기 때문에 시스템에 내장된 데이터 바인딩 엔진을 만든 것이기도 합니다. 반면에 Rx는 태생부터 Iterator Pattern, Observer Pattern, Functional Programming의 영향을 강하게 받은 것이기에 오히려 본래의 MVVM의 맥락과는 배치된다고 저는 생각합니다. 답변이 되었나 모르겠습니다. 추가적인 질문이 있으면 코멘트 남겨주시면 되겠습니다.

제가 이해한게 맞는지 궁금합니다.

답변이 올라가기 직전에 질문이 수정되었네요.말씀하신대로 도메인 영역의 작업이 맞습니다.Cocoa MVC에서도 모델이 처리하는 작업이며, Cocoa MVC에서 파생된 아키텍처 패턴은 없습니다. Cocoa MVC는 옵저버 패턴으로 모델과 뷰가 연결되어 있는 것이 뷰와 모델의 재사용성을 떨어뜨린다고 생각했기 때문에 뷰와 모델 간의 통신을 컨트롤러를 통하게끔 만든 아키텍처일 뿐입니다.

질문 드려요!

안녕하세요.네트워크 통신이나 데이터베이스 활용은 비즈니스 로직에 해당되는 것이고 기본적으로 비즈니스 로직의 처리는 모델 계층의 책임입니다. 비즈니스 로직의 처리를 담당할 계층을 명시적으로 제시하는 등 베스트 프랙티스를 자체적으로 제공하려는 개발환경도 있고 전혀 언급하지 않는 개발환경도 있습니다. 굳이 언급이 없어도 프레젠테이션 레이어와 비즈니스 레이어를 분리하는 것은 일반적인 내용이므로 그런 명시적인 언급이 없다는 것 자체를 개발환경의 영향이라고 보기는 어렵습니다.MVP나 MVVM에서도 앞서 설명한 내용들은 동일합니다. MVP나 MVVM이 탄생한 이유는 각각의 섹션을 참고해주세요.

안녕하세요. 다소 헷갈릴 수 있는 부분인데 올려주신 그림에서 뷰 -> 뷰모델 방향의 화살표는 데이터 바인딩의 방향이 아닌 의존성의 방향이라고 생각하시면 됩니다. 올려주신 사진처럼 MVVM에서는 데이터 바인딩을 통해서 View만 ViewModel에 의존하고 ViewModel은 View에 의존하지 않습니다. MVP의 Passive View에서는 뷰와 프레젠터가 서로 의존하며 View -> Presenter 방향으로 이벤트를 전달하고 Presenter -> View 방향으로 UI를 갱신하는 방식으로 동작했었죠? 그럼 MVVM에서는 뷰모델이 뷰를 모르는데 뷰모델에서 변경이 생겼을 때 UI에 변경된 값이 어떻게 반영이 되는가라는 문제를 해결해주는 것이 데이터 바인딩입니다. Passive View에서는 프레젠터가 프레젠터 안에서 수동적으로 뷰에 갱신하라는 명령을 내렸지만, MVVM에서는 뷰 안에 갱신작업을 bind 메서드를 통해 바인딩했으므로 뷰모델은 뷰를 몰라도 되는 것입니다. 데이터 바인딩의 방향 자체는 상황에 따라서 단일방향일수도 양방향일수도 있습니다.<img src="https://cdn.inflearn.com/public/comments/4b80f790-729a-4ab8-9419-8aa27af73b94/databinding-dataflow.png" alt="image" title="image">UI가 UILabel처럼 읽기전용(Read Only)인 경우 UILabel이 뷰모델의 특정 프로퍼티의 변화만 추적하도록 OneWay 바인딩을 하면 될 것이고, 이벤트를 발생시키는 어떤 UI의 값과 뷰모델의 특정 프로퍼티를 항상 일치시키려면 TwoWay 바인딩을 하면 되겠죠? 그리고 UI에서 어떤 입력이 발생했을 때 그 입력을 뷰모델에 전달만 하면 된다면 OneWayToSource를 하면되겠죠? 물론 WPF와 다르게 애초에 UIKit에서는 데이터 바인딩을 지원해주지 않기 때문에 엄밀하게 용어를 구분해서 사용하지는 않는 것 같습니다. 그저 상황에 따라서 입력은 뷰모델이 처리하도록 위임하고(생성자를 통해서든, transform 같은 함수를 통해서든, 뷰모델이 소유한 input 같은 프로퍼티를 public으로 공개하든), 출력해야할 값을 bind 메서드로 특정 UI에 바인딩한다 이런 메커니즘으로 동작한다고 이해하시는게 편하지 않을까 생각합니다.