최근에 MVP에 대한 기사를 읽었습니다. MVP 모델이 무엇인지 소개하는 내용은 아주 간단합니다.
하지만 MVC와 MVP의 차이는 실제로 명확하지 않습니다. 읽고 나면 "MVP는 좀 더 엄격한 사양을 갖춘 MVC일 뿐이라는 생각이 듭니다."
MVP에서 프레젠터는 어떤 역할을 하나요?
MVP에 대한 정보를 좀 찾아봤습니다. MVC의 Controller에 비해 Presenter에는 Model과 View를 완전히 분리하는 기능이 추가되어 있다고 합니다. 하지만 실제로 내 개념(일상 응용 프로그램)에서는 MVC의 모델과 뷰가 분리될 수 있습니다. 일반적인 개발에서는 모델에 제공된 데이터를 컨트롤러에서 처리한 다음 이를 페이지에 렌더링합니다. 즉, MVC는 실제로 많은 경우 V와 M을 분리할 수 있습니다. 그렇다면 MVP 모델을 제안하는 목적이나 포인트는 무엇인가?
저에게 의견을 주시면 감사하겠습니다!
나는 나쁜 질문은 없고 오직 나쁜 대답만 있을 뿐이라는을 굳게 믿습니다.
처음에는 명령줄만 있었습니다.
소프트웨어 엔지니어의 영혼은 셸에서 실행됩니다.
Xerox는 "GUI가 필요하다"고 말했습니다...
1. 데스크톱 소프트웨어용 MVC
스몰토크에 감사드립니다. GUI 덕분입니다.
2. B/S 아키텍처를 사용한 MVC
나중에 인터넷이 발달하면서 프로그래머들은 자신의 프로그램을 서버에 올려서 실행하게 되었습니다. 이때 GUI가 바뀌었습니다. 모든 인터페이스(View 레이어)의 현실은 브라우저(HTML)로 대체됩니다.
이때 BS 아키텍처에 MVC가 도입되었습니다. 고마워요 태양. 고마워요 스트럿츠.
3. 프론트엔드 MVP
이후에는 브라우저가 점점 더 강력해지면서 많은 비즈니스가 브라우저에서 실행되었습니다.
그래서 프로그래머들은 MVC를 뷰 레이어로 가져왔습니다. 그러나 HTML+CSS+JS를 디스플레이 레이어로 사용하는 것은 기존 데스크톱 GUI와 매우 다릅니다. 그래서 js언어의 특성을 최대한 살리기 위해 MVP가 등장하게 되었습니다.
아키텍처 프리젠테이션 패턴 MVP(SC),MVP(PV),PM,MVVM 및 MVC 비교
[번역] MVP(SC), MVP(PV), PM, MVVM 및 MVC 성능 모델 아키텍처 비교
건축의 진화:
MVC 모드:
View <-> 컨트롤러 <-> 컨트롤러는 라우팅뿐만 아니라 비즈니스 계층과 프레젠테이션 계층 간의 연결도 담당합니다. 개발. 개발 중에는 MVP만큼 직관적이지 않고, 집중력이 덜한 MVP에서는 더 간결합니다.
MVP 모드:
View <-> Presenter(컨트롤러 <-> 이벤트) <--> Model은 라우팅 및 컨트롤러 부분을 숨기므로 개발 시 라우팅 및 제어에 대해 걱정할 필요가 없습니다. 메시지 레이어를 각 메시지에 의해 트리거된 이벤트에 넣고 해당 이벤트에서 비즈니스 작업을 수행합니다. 개발을 더욱 간단하고 직관적으로 만들지만 컨트롤러 레이어 작업의 유연성을 희생합니다.
MVVM 모드:
View <-> ViewModel <-> ViewModel은 MVP에서 발표자 기능을 수행할 뿐만 아니라 View를 적극적으로 업데이트할 수 있습니다. View에 의해 트리거되는 단일 백그라운드 업데이트 대신. MVVM은 MVP의 향상된 버전이라고 할 수 있습니다