MVC / MVP / MVVM 패턴 자료수집

 

https://tech.lonpeach.com/2020/11/09/Thinking-about-MVRP/

MV(R)P 설계에 대한 생각 - Lonpeach 기술 블로그 | Lonpeach Tech

https://academy.realm.io/kr/posts/eric-maxwell-mvc-mvp-and-mvvm-on-android/

 

 

각각의 목적에 따라 코드가 분리되어 있어, 유지보수 및 확장성이 뛰어납니다.

협업을 위한 아키텍처 패턴.

 

MVC (Model - View - Controller)

- Model : 데이터, 상태, 비즈니스 로직 (뷰나 컨트롤러에 묶이지 않아 재사용 가능)

  1. 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 한다.

  2. 뷰나 컨트롤러에 대해서 어떤 정보도 알지 말아야 한다.

  3. 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야만 한다.

 

- View : 디스플레이. 

  1. 모델이 가지고 있는 정보를 따로 저장해서는 안된다.

  2. 모델이나 컨트롤러와 같이 다른 구성요소들을 몰라야 된다.

  3. 변경이 일어나면 변경통지에 대한 처리방법을 구현해야만 한다.

 

- Controller : 여러 개의 컨트롤러(controller)를 가지고 있다. 사용자는 컨트롤러를 사용하여 모델의 상태를 바꾼다. 컨트롤러는 모델의 mutator 함수를 호출하여 상태를 바꾼다. 이때 모델의 상태가 바뀌면 모델은 등록된 뷰에 자신의 상태가 바뀌었다는 것을 알리고 뷰는 거기에 맞게 사용자에게 모델의 상태를 보여 준다.

  1. 모델이나 뷰에 대해서 알고 있어야 한다.

  2. 모델이나 뷰의 변경을 모니터링 해야 한다.

 

 

MVC는 View와 Model사이의 의존이 심하다.

MVC는 View가 Model로부터 직접 정보를 얻어와서 업데이트한다. 

View는 여러개의 Controller와 결합 될 수 있다.

Controller는 여러개의 View와 결합 될 수 있다.

Controller가 View에 강하게 결합되어있어서 View를 변경하면 Controller도 수정해야한다.

Controller가 비대해진다.

예를들면 View는 Text 레퍼런스만 가지고 있을뿐 어떻게 표시해야하는지를 알지못한다. Controller는 Model을 통해 로직을 수행하여 가공된 최종string을 전해준다.

View는 한개의 스크립트로 레퍼런스들을 들고있는 형태가 아니라 각각의 Text레퍼런스들이 View라고 볼 수도다.

 

MVP (Model - View - Presenter)

- Model : 데이터만을 담고있음

- View : 디스플레이

- Presenter : 로직과 Model-View간의 통신을 담당. 본질적으로는 MVC의 컨트롤러와 같지만, 뷰에 연결되는 것이 아니라 그냥 인터페이스라는 점이 다릅니다. Presenter는 View에서 분리되어있다. View를 interface를 통해 조작

 

MVP는 View와 Model의 의존은 없어지지만, View와 Presenter가 1:1로 강하게 의존한다.

일반적으로, View와 Presenter가 1:1로 매핑된다.

 

 

MVC와 MVP의 차이점!!

https://beomy.tistory.com/43

https://blog.canapio.com/92

 

가장 큰 차이점은 MVC는 뷰가 여러개이지만, MVP는 뷰가 1:1로 대응된다. MVP에서 View는 Presenter는 서로 직접 참조를 가지고 있어서, 강하게 결합된다.

MVC에서는 View는 표시할 방법을 모름. Controller가 표시할 방법을 직접 지시한다. MVP에서는 Controller가 View에게 표시할 내용만 전달하고, View는 알아서 표시함.

 

MVC는 유저가 View를 통해 인터페이스로 원하는 동작을 입력하면 Controller가 그를 받아 Model을 수정, Model은 수정되는 즉시 View에게 명령을 보내 View를 업데이트하는 방식.

MVP는 Model-View 간의 의존성을 끊고, View를 통한 입력 처리 + Model의 수정 + Model의 수정에 따른 View 업데이트를 모두 Presenter 혼자서 처리함. 

 

 

MVC 패턴

• 컨트롤러는 행동 기반이고, 뷰를 통해 공유될 수 있다.
• 표시를 위해 어떤 뷰를 선택할지 결정하는 책임일 수 있다.

MVP 패턴

• 뷰가 모델에 더 느슨하게 연결되있다. 프레젠터는 모델을 뷰에 바인딩할 책임을 가진다.
• 뷰와의 인터렉션이 인터페이스를 통하기 때문에 유닛테스트하기 더 쉽다.
• 보통 뷰:프레젠터는 1:1로 맵핑된다. 복잡한 뷰는 여러 프레젠터를 가질 것이다.

MVP 예시 3가지

1. View를 개별 Text, Transform 등으로 사용한 경우. (View를 따로 선언 안함)

    추가적으로 다른 Representer와 협업하는 방법을 보여줌.

GitHub - keidroid/UnityMVP: UnityでMVPパターンのサンプル

2. 정석대로 View에서 Presenter 레퍼런스를 가지고 있고, 인터페이스로 연결함

GitHub - saparkhid/Unity-MVP-Example: implementing the MVP pattern in unity.

3. 내가 지향하는 방향과 제일 유사함

GitHub - ulaph/Unity_MVP_Sample: Unity MVP Sample

 

 

 

 

MV(R)P

- 기존 MVP 에서 View의 Presenter참조를 삭제함.

- View의 Observable을 노출시켜 Model쪽에서 참조함. 

 

MVVM (Model - View - ViewModel)

- Model : 데이터만을 담고있음. 실제 게임에서 사용하는 데이터.

- View : 디스플레이

- ViewModel : View에 표현하기위한 데이터.

뷰 모델과 MVP 패턴에 있는 프리젠터 사이의 주요한 차이점은 프리젠터는 뷰에 대한 참조를 가지고 있는 반면, 뷰 모델은 그렇지 않다는 것이다. 그 대신, 뷰는 뷰 모델의 속성에 직접 '연결된(binds)' 채로 업데이트를 주고 받는다. (인자로 넘겨준다는 이야기)

 

View는 인풋을 관리하고, 인풋에 반응해 ViewModel을 호출함.

ViewModel은 Model의 데이터를 사용하여 데이터를 가공함.

View는 ViewModel의 값이 변하면 DataBinding에 반응하여 즉각적으로 변한다.

View와 Model 사이의 의존성이 없습니다.

Data Binding을 이용하여 View와 ViewModel 사이의 의존성이 없습니다.

하나의 ViewModel을 여러 View가 공유하는 것도 가능하다!

 

유니티에서의 MVP

Model과 View는 직접 참조를 가지고 있지않음이 중요하다.

View가 삭제되더라도 컴파일되어야 패턴을 준수한 것이다.

1. View

 - MonoBehaviour로 구현.

 

2. Model

 - C# 객체로 구현. (Mono로 생성하면 메모리가 엄청날 듯)

 

3. Presenter

 - MonoBehaviour로 구현. (C# 객체로도 가능함)

 - View를 SerializedField로 선언해놓고 인스펙터를 통해 참조 

 - Model은 코드를 통해 참조 (일반적으로는 직접 new함)

 

 

 

초기화는 어떻게?

View가 Presenter를 생성하고, Presenter가 Model을 생성함.

public class MyView : MonoBehaviour, IFunnyRectView 
{     
    private MyPresenter _presenter;
    
    public void Awake()
    {
        _presenter = new MyPresenter(this);
        _presenter.Bind();
    }
}

 

 

 

모델이 거대해지면 이런식으로 나눌 수 있다.

class Model
{
    public PlayerModel player;  // Container of the Player data.
    public GameModel game;      // Container of the Game data.
}

 

 

 

 

https://unionassets.com/blog/add-the-mvp-in-the-game-for-unity3d-436

Add the MVP in the game for Unity3D | Blog | Union Assets - Dev Assets Marketplace

https://anshul-vyas380.medium.com/model-view-presenter-b7ece803203c

Model View Presenter

https://light11.hatenadiary.com/entry/2019/01/23/231828

【Unity】MVPとMV(R)Pの実装例といろんな実装方法の考察 - LIGHT11

 

 

 

 

 

 

 

 

 

http://1st.gamecodi.com/board/zboard.php?id=GAMECODI_Talkdev&no=3991 

UniRX, MVP 패턴을 적용하여 프로젝트를 진행하신분 있으신가요?

http://1st.gamecodi.com/board/zboard.php?id=GAMECODI_Talkdev&no=3488 

클라이언트 프로젝트 구조를 어떻게 잡으시나요?

https://riptutorial.com/unity3d/example/32513/model-view-controller--mvc--design-pattern

unity3d Tutorial => Model View Controller (MVC) Design Pattern

 

https://www.toptal.com/unity-unity3d/unity-with-mvc-how-to-level-up-your-game-development

Unity with MVC: How to Level Up Your Game Development

https://www.jacksondunstan.com/articles/3092

JacksonDunstan.com | A Model-View-Controller (MVC) Pattern for Unity

 

 

 

자동 MVP 스크립트생성

https://github.com/MasaKoha/MVPScriptGenerator4Unity

 

 

 

 

일본쪽.... MVP 내용

https://orotiyamatano.hatenablog.com/entry/2019/08/19/Unity%E3%81%AEMVP%E3%80%81MV%28R%29P%E3%82%92%E8%AA%BF%E3%81%B9%E3%81%9F%E3%81%91%E3%81%A9%E3%80%81%E3%81%A9%E3%82%8C%E3%81%8C%E6%AD%A3%E3%81%97%E3%81%84%E3%82%93%E3%81%A0%EF%BC%9F? 

UnityのMVP、MV(R)Pを調べたけど、どれが正しいんだ？ - YAMADA TAISHI’s diary

 

 

 

MVP의 경우 유아이가 호출되면, 데이터를 가져와서, View에 각각 직접 넣어줬다.

MVVM 패턴의 경우 다음과 같이 구현. (rootContext가 viewModel)

 - 이건 ViewModel에 대한 코드임. View가 언제 가져갈지는 모르지만 업데이트 해놓는다.

Context주소는 아래랑 같이 페이지 기준으로!

데이터 바인딩은 이런 에셋도있는데 깃허브에 무료도 많음.

 

Path쪽에 HomePageCOntext.AppTitle 로 string으로 입력함

지금은 상위 오브젝트에 상대경로로 바꿔주는 DataMaster가 존재해서 선택하는걸로 보임.

 

 

 

 

 

 

코드가 어디붙어있어?

 -> 근데 이 예시는 게임로직에 대한부분. UI들은 그냥 별도로 있어도 될 것 같다.

https://gamecodi.com/4787/unity-%EB%8C%80%EC%B2%B4-%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8%EB%A5%BC-%EC%96%B4%EB%94%94%EC%97%90-%EB%B6%99%EC%97%AC%EC%95%BC-%ED%95%98%EB%8A%94%EA%B0%80?show=4797#a4797 

Unity 대체 스크립트를 어디에 붙여야 하는가 - 게임코디

클래스별로 분류해보면

UserManager(모델)

- 유저관련 클래스들.

- Account

- Inventory

- Skill

 

DataManager(모델)

- 게임 데이터 모음(캐릭터, 몬스터, 맵, 아이템, 스킬...)

 

GameManager(로직)

- 각종 로직 클래스들 모음

 

UIManager(뷰)

- 주로 UI팝업 클래스들 관리

 

 

하다보면 자잘하게 바뀔때도 있지만 제일 큰 목적은 

복잡도를 낮추고 최대한 편하게 코딩 하자

누가봐도 구조만 파악하면 뭐를 어디에 넣어야 할지 바로 알 수 있게 하자

입니다.

한마디로 유연하면서 규격화된(?) 구조로 가는 거죠.

 

데이터 접근은 UserManager

UI접근은 UIManager

로직 접근은 GameManager

 

여기에 협업까지 생각한다면 로직 부분을 좀 더 세분화 합니다.

수많은 로직들을 담당하는 각 클래스들을 GameManager밑에 두고

지들끼리는 메시지(Enum)로 통신하게 하는 겁니다. (유니티의 SendMessage보다는 pub/sub로 자체 구현)

이렇게 구성해 놓으면 메시지만 정의해 놓고 각 작업자들이 따로 작업한 뒤 나중에 연동하는것도 가능해지죠.

같은 GameManager밑에 붙어있지만 GetComponent안쓰고 메시지로 주고 받도록 규칙을 정하는 겁니다.