MVC 아키텍처 의 wikipedia 페이지에 따르면 뷰는 모델에 의해 무료로 통지되며 모델의 현재 상태에 대해 자유롭게 쿼리 할 수 있습니다. 그러나 Stanford의 iOS 5에 관한 Paul Hegarty의 강의 1, 강의 1, 18 페이지에서는 모든 상호 작용이 컨트롤러를 거쳐야합니다. 헤가 티의 진술이 과정을 단순화하기위한 것인지 분명하지 않지만, 그가 디자인을 그렇게 의도한다고 말하고 싶습니다.
이 두 가지 반대 관점을 어떻게 설명합니까?
답변:
이것은 MVC / MVVM에서 논란이되는 주제입니다. 어떤 사람들은 뷰가 모델에 직접 액세스하는 것이 좋다고 말하고 다른 사람들은 뷰에서 모델을 추상화하기 위해 ViewModels에 모델을 포장해야한다고 말합니다. 나는 개인적으로 두 가지 접근법의 팬이 아닙니다.
MVC / MVVM의 주요 목표 중 하나는 UI, 비즈니스 로직 및 데이터를 분리하는 것입니다. 따라서 이러한 개념을 염두에두고 View가 모델에 직접 액세스 할 수있게하면 원하지 않는 종속성이 생성됩니다. 반면에 ViewModels에서 모델을 래핑하는 것은 종종 지루하며 ViewModel이 단순히 모델에 대한 통과 역할을하는 경향이 있기 때문에 유용하지 않습니다.
모델이 특정 인터페이스를 구현하는 방식이 마음에 듭니다. IModel이라고합니다. 그런 다음 ViewModel 클래스는 View 소비를 위해 IModel을 구현하는 객체의 인스턴스를 제공 할 수 있습니다. View는 단순히 ViewModel에서 가져온 IModel 객체와 함께 작동한다는 것을 알고 있습니다. 이렇게하면 불필요한 ViewModel 래퍼 코드가 제거되고 IModel의 구체적인 구현이 View에서 숨겨집니다. 나중에 View 1 비트에 영향을주지 않고 IModel 구현을 다른 것으로 교체 할 수 있습니다.
웹에서 모든 사람은 디커플링 MVC를 호출합니다.
C #과 같은 일부 기술은 MVVM을 사용합니다. View와 다른 것 사이에 링크가 없기 때문에 모든 것이 서비스 로케이터를 통과하여 변수를 바인딩합니다.
순수한 MVC에서 View는 모델과 직접 대화하고 그 반대도 마찬가지입니다. 컨트롤러는 변경이있을 때만 존재합니다.
그리고 PAC (Presentation Abstraction Control)라는 것이 있습니다. 이 아키텍처에서 뷰와 모델은 서로 대화하지 않습니다. Controller는 View 또는 Model로 무엇이든 할 수있는 유일한 컨트롤러입니다. 사람들은 종종 이것을 MVC와 혼동합니다.
여기에 더 나은 설명이 있습니다 : http://www.garfieldtech.com/blog/mvc-vs-pac
에서 MVC , 폴 Hegarty은 잘못된 것입니다. 컨트롤러는 모델 간 통신이 아니라 사용자 이벤트에 관한 것입니다. 고전적인 MVC 에서, 뷰 (들)는 모델 (Observer pattern)을 관찰한다.
조정을 수행하는 사이에 사람이 있으면 패턴을 MVP 라고해야합니다 . 실제로 오늘날 MVC로 표시되는 대부분은 실제로 MVP에 더 가깝습니다.
그런 다음 MVVM 이 있습니다. 둘 다 비슷하지만 조금 다릅니다. 오래 전에 존재했습니다 ... viewmodel 객체를 통해 함께 묶인 두 개의 MVC / MVP로 보는 것이 가장 좋습니다. "클라이언트"MVC에는 viewmodel이 모델과 "서버"MVC에는 뷰 모델이 뷰로 있습니다.
특히 스탠포드 강의의 내용에 대해 질문하고 있으므로 헤가 티의 입장에 대해 두 가지를 고려해 볼 가치가 있습니다.
나는 Paul Hegarty에 동의하며 View가 모델에 대해 알지 않아야한다고 믿습니다. 달성하기는 어렵지 않지만 설계 및 향후 유연성에 추가적인 이점을 제공합니다.
"더미"ViewModel 클래스를 피하고 일을 단순하게 유지하려는 작은 응용 프로그램 (일반적으로 데스크톱)에서는 IModel 인터페이스를 사용하고 (위의 답변 참조) Model이 View에 대해 전혀 모르는 것을 관리합니다 (구독자 사용) 고전적인 MVC에서와 같이).
또한이 경우 컨트롤러는보기와 상당히 결합되어 있으며 단순성을 위해 항상 명확하게 분리하지는 않습니다.
동일한 모델에 대해 여러 개의 뷰가있을 때 두 번째 "단순화 된"접근 방식은 정상이지만 다른 모델에 대해 동일한 뷰를 사용하려는 경우에는 권장하지 않습니다. 다른 점에서 나는 기본 모델을“따르는”JUnit 테스트 클래스뿐만 아니라 본질적으로 다른 것을 의미합니다.
나는 이것에 대한 단단하고 빠른 규칙이 없다고 믿습니다. 그것은 전적으로 당신의 필요에 달려 있습니다.
당신은 다른 믿음을 가진 사람들을 찾을 것입니다. 아키텍처는 더 나은 솔루션을 디자인하는 데 도움이되는 개념입니다.
모델 뷰 커뮤니케이션 외에도 MVC의 비즈니스 로직에 대한 모순이 하나 더 있습니다. 많은 사람들은 모든 비즈니스 로직이 하나의 모델이어야한다고 생각합니다 ( 이 SO 질문 참조 ). 반면에 Florian이 공유 한 링크는 비즈니스 로직이 컨트롤러에 있어야한다고 말합니다.
이 외에도 비즈니스 로직을 애플리케이션 로직 (컨트롤러에 놓음)과 도메인 로그인 (모델에 놓음)으로 나눌 가능성이 있습니다.
따라서 이야기의 교훈은 MVC는 모델, 뷰 및 컨트롤러가 분리되어야 함을 의미합니다. 그 외에는 당신에게 가장 잘 맞는 것입니다.
모델 뷰 통신에 DTO를 사용합니다.
예를 들어 :
많은 상황에서 뷰와 모델이 서로 다른 상황에서 자유롭게 상호 작용해야하는 이유와 방법에 대해 제안했지만 컨트롤러를 만드는 iOS의 주된 이유는 코드 기반에서 모델과 뷰의 종속성을 피하고 재사용 할 수 있도록하는 것입니다. iOS의 진화에 따른 요구 사항에 따라 모델 또는 뷰.
UI / UX 또는 모델 또는 둘 다에서 앱에 대한 업데이트를 유지해야 할 수도 있으므로 모델과 뷰간에 모드 종속성 코드를 생성하지 않아야합니다. 앱의 프레젠테이션 계층을 변경하려면 변경 한 후에도 여전히 동일한 모델을 재사용 할 수 있으며 그 반대도 가능합니다.
iOS의 MVC는 다양한 로직을 가진 거대한 ViewController를 생성하고 의도 된 것 이외의 모든 종류를 처리한다는 데 동의하지만 코드베이스를보다 유연하고 쉽게 만들기 위해 MVVM 또는 Presentation Controls를 사용하는 것이 좋습니다 더 작은 ViewController로 읽고 유지할 수 있습니다.
이것은 iOS에서 더 작은 ViewController를 찾는 사람들에게 도움이 될 수 있습니다.
http://blog.xebia.com/simplification-of-ios-view-controllers-mvvm-or-presentation-controls/