찾다

 >  Q&A  >  본문

mvc - 웹이 아닌 그래픽 응용 프로그램에서 모델 보기와 다른 요소 간의 관계를 처리하는 방법은 무엇입니까?

오늘 항의하고 웨이보 올렸습니다:
http://weibo.com/1651843872/B09Wxlokv?mod=weibotime

지금 돌이켜보면 jQuery의 인터페이스는 대규모 애플리케이션에 해로울 수도 있습니다. MVC의 개념은 대체로 명확한 Model을 추상화하고 있으며, View는 Model을 기반으로 하는 인터페이스에 동기화되어 직접 작동됩니다. 모델.. 내내 헷갈렸어요

웹 플랫폼에서 그래픽 인터페이스를 개발하는 것이 매우 저렴하다는 것을 깨달았기 때문에 프론트엔드를 배웠습니다.
그래픽 애플리케이션의 복잡성을 진정으로 깨닫기 시작한 것은 애플리케이션 작업을 시작하고 나서였습니다..
제 기억으로는 이 학습 과정이 거의 jQuery를 사용하는 것에 대한 단계별 투쟁이었습니다..
모델, 뷰 및 기타 구성 요소와 해당 부분의 분리는 점차 현실화될 수 있습니다.

웹은 매우 지저분합니다. 왜냐하면 DOM에는 이미 추상화 계층이 있고 제공 측면에서도 일부 길을 차단하기 때문입니다.
그렇다면 DOM이 없는 다른 플랫폼의 그래픽 개발에서 뷰와 모델 간의 관계를 어떻게 처리할 수 있을까요?

예를 들어 Webkit 도구 라이브러리의 기본 구현은 모델과 뷰를 유지합니다.
Unity3D, Flash 등도 있는데 이런 부분은 어떻게 이해하시나요?

질문이 좀 일반적인데요. 조언 부탁드립니다.

習慣沉默習慣沉默2811일 전568

모든 응답(1)나는 대답할 것이다

  • 世界只因有你

    世界只因有你2017-05-16 17:08:34

    잠깐만요, 왜 JQ에 반대하나요? jQ는 DOM 작업 캡슐화이며 MVC와 거의 관련이 없습니다. 총과 대포를 모두 사용하여 싸우는 것과 마찬가지로 "대포는 한 발에 벙커를 폭파할 수 있다는 것을 알고 있으므로 소총을 사용하는 것은 전장에 해롭다"고 말할 수는 없습니다

    사실 AngularJS는 jq를 옹호하지 않지만 핵심은 jqLite를 사용하기 쉽게 만드는 것이고 Backbone은 자연스럽게 pro-jQ입니다. 대규모 애플리케이션에는 구조가 전혀 없습니다. jQ에서 하드 코딩하는 것은 확실히 잘못된 방법이지만 단순히 jQ 없이 MVC를 구현하는 것은 올바른 생각이 아니라고 생각합니다.

    참고용으로 작년 백본 리뷰를 올려보겠습니다. 사실, 지금은 "관리 인터페이스" 유형 애플리케이션, Backbone 또는 Backbone 유사 모델 메커니즘, 특히 Backbone.sync用处不大。因为浏览器端的JS天生不『拥有』任何数据,不会负责数据的简单CURD式的落地(H5涉及离线本地存储另说)。浏览器端JS可能更需要的是维护数据和DOM绑定,也就是所谓ViewModel이 아닌 이상 KnockoutJS

    을 참조한다고 생각합니다.

    웹 이외의 경험이 없어서 죄송합니다.

    회신하다
    0
  • 취소회신하다