본문으로 건너뛰기
黯羽轻扬매일 조금씩

자신이 이해하는 프론트엔드 MV*

무료2015-08-26#Mind#Design_Pattern#Front-End#MVC图解#MVP图解#MVVM图解#MV*#前端MV*#前端MVVM#前端MVC

MV* 에 대해 말하는 글은 많지만, 무엇이 맞고 무엇이 틀린지를 명확히 이해하는 것은 쉽지 않습니다. 본 글에서는 필자가 많은 블로그 글을 본 후 MV* 에 대한 자신의 이해를 자세히 설명합니다

서론

필자가 처음 MVC 를 접한 것은 Java 에서였습니다. ssh 등의 대규모 것이 아니라, 단순히 계층화 개발로, 코드 구조를 더 명확하게 하기 위함이었습니다

  • V(View) Java 에서 swt, swing 으로 만든 GUI 가 될 수 있습니다. 물론, jsp 가 생성한 페이지도 될 수 있습니다

    View 는 순수한 인터페이스로, 사용자에게 데이터를 우호적인 형태로 표시하는 책임이 있습니다

  • M(Model) 은 순수한 Java Bean(단순한 Bean, 커스텀 데이터 구조와 getter/setter 만) 일 수도 있고, 일부 데이터 검증 로직을 포함할 수도 있습니다

    데이터 검증 로직을 V 또는 C 안에 배치하는 것도 있으며, 구체적인 시나리오에 따라 다릅니다. 예를 들어 jsp 애플리케이션에서는 데이터 검증 로직을 V 안에 배치하는 것이 적합하여 요청을 줄일 수 있습니다

  • C(Controller) 는 비즈니스 로직이 집약되는 층으로, 모든 중요한 비즈니스 로직이 C 안에 있습니다

    C 는 V 로부터 전달된 사용자 입력을 받아 처리 완료 후 M 을 업데이트하고, M 이 V 에 업데이트를 알립니다. 하나의 V 가 하나의 C 에 대응 (의존) 할 수도 있고, 여러 개의 V 가 하나의 C 에 대응할 수도 있습니다 (여러 페이지의 비즈니스 로직이 기본적으로 같은 경우). 그러나 하나의 V 가 여러 개의 C 에 대응해서는 안 됩니다. 왜냐하면 이 의존 관계는 밀결합이기 때문입니다. M 과 V 의 대응 관계는 구현 방식에 따라 다릅니다. 고전적인 옵저버 패턴인지 퍼블리시/서브스크라이브 패턴인지의 차이로, 전자는 M 이 직접 V 에 업데이트를 알리고, 후자는 M 이 C 를 통해서만 V 를 업데이트할 수 있습니다

나중에 데이터베이스 조작 (C 에 둠?) 이나 설정 데이터/상수 (V 에 둠?) 등, 어디에 두어도 적합하지 않은 로직이 있다는 것을 발견했습니다. 그래서 Core 를 추가하여 상수를 배치하고, DAO 층을 두어 데이터베이스 조작을 배치하며, 이 모두를 C 의 보조 층으로 삼았습니다

MVP 와 MVVM 의 이념은 이와 다르며, 층을 늘리거나 줄이는 것이 아니라, 층의 직능을 재분할한 것이며, 물론 재분할 후 다른 보조 층도 추가되었습니다

일.MVC

입력에서 출력까지, 데이터 흐름 (무리하게 데이터 흐름도라고 부르겠습니다. 阮은 이를 통신 방식도라고 부릅니다) 은 다음과 같습니다:

[caption id="attachment_730" align="alignnone" width="889"]MVC 数据流 MVC 数据流 [/caption]

주의: 의존 관계도가 아닙니다. 의존 관계로 보면, M 과 V 는 옵저버 패턴 관계로, V 가 M 에 의존해야 합니다 (Observer 는 Subject 의 존재와 그 공개된 인터페이스를 알고 있음). M 은 V 에 의존하지 않습니다 (Subject 는 누가 자신을 关注하는지 알지 못하며, 신경 쓰지도 않음). 상호작용 관계 (데이터 흐름) 로 보면, M 이 V 를 업데이트합니다 (Subject 가 변하면, 자동으로 모든 Observer 에게 알림). V 는 직접 M 을 업데이트할 방법이 없습니다.

의존 관계는 구체적인 구현에 따라 다릅니다. 개인적으로 Trygve Reenskaug 의 당초 구현에 집착하는 것은 의미가 없다고 생각합니다. 따라서 의존 관계도는 그릴 수 없습니다. 게다가 몇 년 후면 위의 데이터 흐름도도 틀릴 수 있습니다. 당초의 C 가 사용자 입력을 받는 것에서, 현재의 V 도 받을 수 있게 되기까지, 미래의 변화를 누가 알겠습니까?

(가십: 이것이 winter 와 阮의 이견 있는 곳입니다. 阮眼中的인 MVC 는 광의의 것으로, 일종의 계층화 사상입니다. 반면 winter 는 MVC 는 79 년의 것을 말하며, 기타는 모두 MVC 로 간주할 수 없다고 생각합니다... 두 편의 블로그 글은 하단 참고 자료에 모두 나열되어 있으니, 관심 있으면 보러 가십시오)

(잡담:1979 년 Trygve Reenskaug 이 MVC 를 제안했습니다. 이것이 정품이라고 합니다. ��시 사용자 입력은 C 만으로 취득할 수 있었고, V 의 기능은 매우 약했으며, 입력 박스 위의 커서조차 C 가 V 에게 그리기를 제어했습니다. 따라서 C 는 하나만 존재할 수 있고, 모든 로직은 C 를 경유해야 한다고 규정했습니다. 번잡한 인터페이스 표시를 제어하기 쉽게 하기 위함입니다. 현재는 사용자 입력을 V 가 직접 취득할 수 있고, 커서 그리기 등의 작업은 운영 체제가 자동으로 완료합니다. C 가 하나만 존재할 수 있다는 것에 집착하는 것은 완전히 어리석은 일입니다)

###Backbone.js

backbone 는 프론트엔드 MVC 의 프레임워크 예로, MVC 구현과 기본 도구를 제공하며, 자유도가 매우 높습니다. 실제 응용에서는 다른 도구와 조합해야 합니다. 예를 들어 underscore, jQuery/zepto 는 필수품입니다

Backbone 은 척추로, 가장 중요한 프레임워크 구현만 제공하고, 나머지 부분은 매우 자유롭다는 것을 나타냅니다. Backbone 에 대한 더 많은 정보는 하단 참고 자료를 확인하십시오

이.MVP

당초의 MVP 도식은 다음과 같습니다:

[caption id="attachment_731" align="alignnone" width="690"]mvp mvp[/caption]

MVC 와 비교하여, 최대의 차이는 C 가 P(Presenter) 로 개명된 것이 아니며, M 에서 V 로의 선이 하나 늘어난 것도 아닙니다. 잠시만요. 옵저버 패턴이 아니었습니까? 왜 M 이 직접 V 에 액세스할 수 있습니까 (Subject 가 직접 Observer 에 액세스)? 잠시 후 논의하겠습니다. 가장 중요한 차이는P 는 단일 객체가 아니며, 도중의 interactor, command 및 selection 을 합친 것이 P 라고 불리며, 즉 P 는 존재하지 않으며, P 는 "interactor, command 및 selection"으로 분해되었다는 것입니다

본래의 M 과 V 의 옵저버 관계 하에서는, V 가 직접 M 에 액세스할 수 없고, C 경유로 전달할 수밖에 없어 사용하기 불편했습니다 (아마도 효율성 또는 사용성 면에서 불편함). 그 후 V 를 강화하여 V 가 직접 M 에 액세스할 수 있도록 했습니다 (V 가 사용자 입력을 받을 수 있는 것도 강화입니다. 당초의 MVC 에서는 C 만으로 사용자 입력을 취득할 수 있었고, 사용자는 직접 C 와 교섭했습니다. 커서나 입력 문자 등은 C 가 V 에게 표시를 제어했습니다). 그리고 C 를 P 로 개명하여 MVC 와 구별했습니다. 실제로는 M(뚱뚱한 V)C 도 괜찮습니다. V 가 두꺼워지면, C 는 얇아집니다 (단순한 데이터 표시는 V 에게 맡기고, 직접 M 의 데이터를 취득하여 표시합니다 (데이터와 뷰의 바인딩?). 물론, 위의 도식에서 V 는 M 을 읽기만 할 수 있고, 쓰기는 C 경유로 해야 함을 알 수 있습니다). 따라서 P 는 일종의 C 라고 말하는 사람도 있으며, 정확히는 더 얇은 C 라고 합니다

MVP 에는 적합한 예 프레임워크가 없습니다. MVP 에 대한 이해에 논쟁이 있기 때문입니다. 어떤 글에서는 P 는 강화된 V 라고 하고, 또 P 안에는 표시 로직만 배치된다고 합니다... 그러면 비즈니스 로직은 어디에 배치합니까? 단순히 Presenter 라는 글자 면에서 이해하고, 당연하게 해석해서는 안 됩니다

(MVP 는 1996 년에 제안되었습니다. 1979 년의 MVC 는 이미 적합하지 않다고 생각하는 사람이 있었기 때문입니다. MVC 의 이념은 여전히 존재하지만, 당초의 경직된 규칙, 예를 들어 C 는 하나만, C 만으로 사용자 입력을 취득할 수 있다는 등의 관념은 시대에 뒤떨어졌습니다. MVP 자체도 과도기의 산물일 수 있습니다. 유용한 것은 배후의 이념뿐입니다. 예를 들어 계층화 개발, 모듈화, 이벤트 구동 등입니다)

삼.MVVM

MVVM 은 마이크로소프트가 WPF 를推出할 때 제안된 패턴입니다. WPF 의 특징은 강력한 컨트롤러로, 예를 들어 DataGrid 는 직접 데이터 테이블과 바인딩될 수 있어, 단순한 데이터 테이블 표시 작업량을 대폭 줄입니다. wpf 의 View 는 XAML 로 정의되며, 컨트롤러의 기본 기능, 예를 들어 입력 데이터 검증은, 간단한 XAML 설정으로 실현할 수 있습니다. 이것이 MVVM 의 최대 특징입니다:V 와 M 의 양방향 바인딩

MVVM 의 이점은 V 를 더욱 분리하여, V 가 다른 언어 (XAML) 로 기술되는 것조차 있게 하여, 컨트롤러의 재사용성을 대폭 강화합니다. 이전 프로젝트의 커스텀 컨트롤러의 XAML 코드를 그대로 가져와 사용할 수 있고, 원 프로젝트에서 로직 코드를 조심스럽게 박리할 필요가 없습니다

winter 가 제시한 도식은 다음과 같습니다:

[caption id="attachment_732" align="alignnone" width="690"]mvvm mvvm[/caption]

즉, MVVM 내의 V 는 매우 강력하고, 매우 완성되어 있고, 매우 두꺼운 V 입니다. 이 V = V + C + E 이기 때문입니다. 데이터 바인딩에 대해서는, 사용의 각도에서 보면 V 와 M 이 바인딩됩니다. 예를 들어 TextBox 의 값은 자동으로 Model 데이터와 동기화됩니다. 위의 도식에서 보면 V 와 VM 간의 데이터 바인딩으로, VM 은 "명령"을 통해 V 를 조작할 수 있습니다. 예를 들어 xx.close() 등입니다. 더 자세한 설명은 다음과 같습니다:

如何呈現是 view 的事，調用方只用給 view 一個 data，view 就只負責這個 data 的顯示，調用者不用管 view 如何顯示，只負責將 data 傳遞，view 也不用管數據從何而來，只要將 data 以自己的方式呈現，并且時刻關注 data 的變化如何反映到 view 上來就好。

而雙向綁定，則是一個附加產品，畢竟只有像 textbox,form 等會改變數據的 UI 不多，大部分 UI 都只是單向的呈現數據而已。不過有雙向綁定在，則可以將 view 和調用方分離得更徹底，即獲取數據不必在意特別的 view，如一個日期是用戶在 textbox 中輸入，還是用 calendar 選取的無關緊要，因為那是 view 設計和安排的事。

###Angular.js

Angular 의 MVVM 은 거의 公认的입니다. MVVM 의 특징은 무거움입니다. wpf 가 사용하기 쉬운 것은 한整套의 강력한 상용 컨트롤러를 제공하기 때문으로, 상상할 수 있습니다

Angular 에 대한 더 많은 정보는 Angular 공식 사이트 를 확인하십시오. Angular 는 Google 이 만든 것으로, 아마도 MVC 의 발전 방향일 것입니다

사.MV* 프레임워크의 선택

不建议直接将业务库框架直接取来使用，更不建议使用过重的业务框架，最好是能明白框架想要解决的问题，与自己项目的实际需求，自己造轮子知根知底。

(浅谈移动前端的最佳实践 에서 인용)

이 말은 매우 이치에 맞아야 합니다. 창업 회사의 친구에 따르면, 회사는 Angular 의 사용을 요구하며, 조사도 없고, 토론도 없고,とにかく 사용한다고 합니다. 왜냐? 유행하기 때문입니다. 적합한지 여부, 사용하기 좋은지 여부는 중요하지 않습니다

자신의 내부 프레임워크는 물론量身裁衣로, 문제가 발생하면 누군가 해결하고, 해결책을 검색할 필요가 없으며, 사용하기 불편하면 자신이 수정할 수 있고, 수정이 좋으면 직접 ���장할 수 있으며, 너무 크면 정리하여, 자주 사용하지 않는 부분을 옵션 모듈로 추출할 수 있습니다... 자신의 것은 물론 남의 것보다 사용하기 좋고, 불편한 곳을 수정할 수 있습니다. 예를 들어 $() 의 문제는, 비즈니스 시나리오에 따라 잘 선택하여, document.querySelector 가 니즈를 충족할 수 있는지 확인하고, 안 되면 zepto 의 호환성이 충분한지 확인하고, 정말 안 될 경우에만 jQuery 를 사용합니다

오.왜 MV* 를 이해해야 하는가

更糟糕的是，今天无数经过演绎的 MVC 实现（如 backbone）和科普文，要么是原本作者概念已经很混乱，掺杂私货，要么为了适配现代的标记语言和控件模式，自己修改了经典 MVC 中的一些概念和耦合关系。实际上今天 MVC 已经没法作为一种交流的标准词汇了。

MV* 를 이해하기 위해 시간을 보내는 것은, 남이 무엇을 말하는지 이해할 수 있기 위함입니다. 그러나 위의 말처럼, MVC 는 이미 동업자 간에 순식간에 이해할 수 있는 표준 어휘가 아닙니다. 맞고 틀림은 중요하지 않을 수 있습니다. 만약 집착해야 한다면 N 편의 논문을 읽고, MV* 의 당초 구현 이념을 찾아야 합니다. 그러나 그렇게 할 필요는 없습니다. winter 가 이미 우리를 위해 해 주었기 때문입니다. 당초의 구현은 하나의 참조점으로, 다른 MV* 구현에 접할 때 대비하여 이해할 수 있지만, 맞고 틀림에 집착하지 않고, 사용하기 좋고 실용적이면 됩니다

참고 자료

댓글

아직 댓글이 없습니다

댓글 작성