소개
프로그래머
문의: eonsu.work@gmail.com
강의
전체 1수강평
- 감사합니다
jw9622
2023.09.20
0
게시글
질문&답변
2024.02.26
MVVM in iOS - 리액티브 프로그래밍, 자동바인딩과 수동바인딩에서 질문이있습니다
iOS 개발자들이 Combine을 뷰와 뷰모델 간의 데이터바인딩 용도로도 사용하는 것이 Combine이 데이터바인딩을 지원하기 위해 만들어진 것임을 의미하지는 않습니다. RxSwift와 마찬가지로 Combine은 보다 다양한 용도로 사용하는 API입니다.공식문서에는 Combine을 다음과 같이 한 줄로 소개하고 있습니다.Customize handling of asynchronous events by combining event-processing operators.Combine을 굳이 특정 패러다임이나 아키텍처와 연관지어서 설명해야 한다면 MVVM 보다는 리액티브 프로그래밍과 연관지어서 설명하는 것이 타당합니다. 그리고 제가 모르는 내용이 있을수도 있겠지만 리액티브 프로그래밍과 MVVM은 직접적인 관계를 찾기 어렵습니다.
- 0
- 1
- 195
질문&답변
2024.01.06
MVC의 본질에 대한 질문
안녕하세요, 진영님.MVC의 본질을 이해하는 것이 도움이 되는 이유는 유저친화적인 애플리케이션을 만들 수 있기 때문이라기 보다는 같은 MVC라는 이름을 가지고 있다고 하더라도, 입력을 받는 것이 뷰인 환경도 있는가 하면 컨트롤러인 환경도 있고, 컨트롤러가 중재자 역할을 하는 환경도 있고, 뷰를 위한 별도의 모델이 존재하거나 전략 패턴, 컴포지트 패턴, 커맨드 패턴, 옵저버 패턴 등 다양한 디자인 패턴을 사용하는 등 수많은 형태의 MVC가 있기 때문입니다. 그럼 이렇게 다양한 형태의 MVC가 존재한다면 자연스럽게 '도대체 MVC라는게 무엇이냐. 이것이 MVC다라고 한마디로 정의내릴 수 있는 것이 있기는 한 것이냐'라는 물음이 생겨날 수 있고 여기에 대한 답이 될 수 있는 것이 모델 계층을 바라보는 시각이 될 수 있는 것입니다. 과거에는 모델이 뷰나 컨트롤러 같은 프레젠테이션 계층과 분리되지 않은 개발환경도 있었는데, 그런 개발방식을 잘못된 분리라고 생각했기 때문에 모델을 프레젠테이션 계층으로부터 분리시키는 것이 중요하다고 생각했고, 개발환경마다 상황에 따른 지엽적인 차이는 있을 수 있지만 이런 원칙을 지킨다면 MVC라고 할 수 있다라는 것을 강조하는 의미로 받아들이시면 되겠습니다.
- 0
- 1
- 284
질문&답변
2023.07.03
MVVM 템플릿2 관련
iOS에서 일반적으로 하위뷰에서 상위뷰로 데이터를 전달할 때는 Delegate 패턴을 사용합니다.PostsViewController에 PostTableViewCellDelegate 프로토콜을 만들어 뷰 간에 처리할 작업을 함수로 명시하고(ex. did~ 처리할 작업을 잘 나타내는 함수명으로 지으시면 됩니다)PostsViewController가 이 프로토콜을 구현하도록 만들고PostTableViewCell에 delegate라는 프로퍼티를 PostTableViewCellDelegate 타입으로 만든 뒤PostsViewController에서 PostTableViewCell을 생성할 때 PostTableViewCell이 가진 delegate 프로퍼티에 자신의 참조(self)를 넘겨주고PostTableViewCell에서 어떤 입력이 발생했을 때 delegate의 메서드를 사용해서 동기화하면 되지 않을까 합니다.이렇게하면 하위뷰인 PostTableViewCell이 상위뷰인 PostsViewController를 직접 참조하거나 상위뷰의 뷰모델인 PostsViewModel을 알지 않아도 됩니다. 그리고 의존관계를 쉽게 관리하려면 하나의 뷰모델은 하나의 뷰 컨트롤러에서만 의존하도록 만드는 것이 좋습니다.
- 0
- 1
- 372
질문&답변
2023.06.29
강의자료같은게 따로 있나요 ??
안녕하세요 이준복님. 별도로 제공되는 강의 자료는 없습니다. 추가로 궁금하신 점 있으시면 편하게 질문해주세요.감사합니다.
- 0
- 1
- 393
질문&답변
2023.04.01
제가 이해한게 맞는지 궁금합니다.
안녕하세요.아키텍처 패턴을 공부하다보면 한번쯤은 '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의 맥락과는 배치된다고 저는 생각합니다. 답변이 되었나 모르겠습니다. 추가적인 질문이 있으면 코멘트 남겨주시면 되겠습니다.
- 0
- 1
- 567