2014-06-22 2 views
-1

주에서 나는 MVC를 사용하여 MVC의 진정한 설명과 구현을 찾고 있었지만, 주목할만한 점은 모든 개발자가 다르게 구현한다는 점이다. 유용한 링크 또는 전자 서적에 대한 답변이 필요합니다.자바에서 MVC의 진정한 구현

  • 모달을 관찰 할 수 없으므로보기에서 변경 사항에 대한 정보를 알려주는 방법은 무엇입니까?
  • 항목을 추가하기 위해 컨트롤러 처리기에서 발생하며 컨트롤러를 관찰 할 수 없기 때문에 변경 사항을 콜렉션에 대해 알리는 방법 (arraylist에 항목 추가)은 어떻게됩니까?
  • 큰 프로젝트에서 MVC와 함께 작동해야합니까?
+2

모델은 관찰 가능 * 및 * 관찰자 일 수 있습니다. 또한 모델의 변경은 컨트롤러에 의해 트리거되지만 모델에서 변경 사항이 발생하고 모델에서 뷰를 알릴 수 있습니다. – Smutje

+2

"Model-View-Controller"는 이론에 따라 거의 구현되지 않는 개념이며 매우 자주 이론을보다 가깝게 만들기 위해 코드가 심각하게 왜곡된다는 것을 이해하는 것이 중요합니다. 일반적인 구조 개념으로 사용하지만 꼬리가 개를 움직이지 않게하십시오. –

+1

모델 - 뷰 - 컨트롤러 (Model-View-Controller)는 사람들이 이해하지 못하거나 적용되지 않는 부분을 쓰더라도 사람들이 구현한다고 말한 것처럼 느껴지는 유행이되었습니다. 우리 업계는 사람들이 현재의 유행을 알지 못한다는 사실을 인정한 것에 대해 불이익을주기 때문에 많은 사람들이 MVC 기술이라고 주장하는 것을 약간 읽거나 다른 사람들에게 지시하기도합니다. 좋은 소프트웨어 디자인으로서의 아이디어, 취업 면접을위한 하나의 학업 설명을 뿜어 낼 수 있다는 점, 그리고 그렇지 않으면 걱정할 필요가 없다는 점입니다. – arcy

답변

0

기본적인 아이디어는 다음 변경

  1. 트리거 컨트롤러 (예컨대 키보드/마우스의 클릭과 같은 사용자 입력을위한 = 응답 코드) 또는 애플리케이션 판정 일 수있다. 예 : 가격을 나타내는 텍스트 필드가있는 경우이를 변경하는 트리거는 명시적인 사용자 입력이거나 은행의 메시지 일 수 있습니다.
  2. 이러한 각 트리거는 모델 (모델 만 해당)을 업데이트합니다. 내 가격의 예에서는 모델을 변경하여 텍스트 필드를 백업합니다. "보기에 일어날 변화 모델에 통보"할 필요가 없습니다 : - 변경에
  3. 모델은 첫 번째 질문에,보기가 따라서

를 다시 렌더링하게 이벤트를 발생시킵니다. 보기 자체가 변경되어서는 안됩니다. 닫는 것은 키보드/마우스 클릭이다. 이것은 CONTROLLER를 호출 할 것이다. 두 번째 질문 : "컬렉션에서 변경 사항을 확인하는 방법"- 컬렉션이 모델에 있어야합니다. 컨트롤러는 뷰에 대한 이벤트를 발생시키는 "model.addItem"을 수행 할 것입니다.

큰 프로젝트에서의 사용에 관해서는 아마 다른 의견을 갖게 될 것입니다. "원자"구성 요소는이 패턴을 엄격하게 준수 할 가능성이 큽니다 (버튼, 텍스트 필드 또는 유사한 사용자 지정 구성 요소). 논쟁은 복합/복합 자료가있는 더 큰 규모에 관한 것입니다. 예 : 내 메인 로직이 데이터베이스에있는 경우 어떻게하면 여러 화면에 변화가 생겼는지 알릴 수 있습니다. 화면과 데이터베이스 모두 복잡한 복합 데이터 (예 : 사용자 플러스 그의 제품 권장 사항 및 장바구니)를 보유하고 있으며 이벤트의 세분성을 결정해야합니다. 간단한 애플리케이션에서 '엔티티 수준 이벤트'를 전송하는 애플리케이션 계층에 대해 합의했습니다. (예 : '사용자 변경됨', '제품 변경됨') UI 레이어가 직접 등록되어 있으므로 100 % 클래식 MVC가 아닙니다. 다른 경우에는 화면 데이터를 정확히 반영하는 복합 모델을 작성하는 데 어려움을 겪었습니다.

0

첫 번째 부분은 위키 피 디아 페이지 Model–view–controller에서 시작하는 것이 좋습니다. 괜찮은 설명과 다른 링크를 찾을 수 있습니다.

첫 번째 질문에 대해서는 단순히 워크 플로에 대해 생각해야합니다. 사용자와의 상호 작용이 발생합니다. 그런 다음 사용자의 액션에서 컨트롤러는 입력을 취해 옵션의 형식을 다시 지정하고이를 모델에 알려진 형식으로 모델에 전달합니다. 이론적으로 모델은 뷰를 업데이트합니다 (웹 응용 프로그램에서 컨트롤러는 모델에서 데이터를 수집하여 뷰에 전달하므로 업데이트 모델 -> 뷰는 간접적입니다).

두 번째로 모델이보기 (데스크톱 응용 프로그램 또는 Java 애플릿과 같은 특수 구성 요소)에서 직접 업데이트 할 수있는 상황에있는 경우 문제가 없습니다. 모델이 직접 (웹 응용 프로그램의 일반적인)보기를 업데이트 할 수없는 경우 다음 상호 작용시 업데이트가 표시됩니다. 그리고 사실 정확한 값을 표시하는 게이지가있는 웹 페이지를 볼 때 정확히 이런 식으로 발생합니다. 브라우저는 javascript 또는 html 메타 태그를 통해 짧은 시간 간격으로 상태를 새로 고침합니다. 그러나 아이템을 추가하기 위해 라고 말하면 컨트롤러 핸들러에서 발생합니다. 이는 사용자의 상호 작용으로 인해 발생하는 것일뿐입니다 (뷰는 상태를 업데이트해야한다는 것을 알고 있습니다. 그래서 컨트롤러를 통해). 그러나 모델은 다른 많은 방법, 다른 사용자의 상호 작용, 실시간 프로브, 백 오피스 운영 등으로 수정할 수 있습니다.

세 번째 질문은 약간의 의견입니다. 서로 다른 층을 독립적으로 개발하고 테스트 할 수 있기 때문에 우려의 분리가 좋은 디자인으로 인식된다는 것은 사실입니다. 이러한 분리는 다른 레이어를 변경하지 않고 한 계층의 기술을 변경할 수있게 해줍니다 (이것이 종종 이론 일지라도). 그러나 IMHO가 가장 큰 이점은 MVC 패턴을 구현하는 많은 프레임 워크가 있다는 것입니다. 하나를 선택하면 보일러 플레이트 코드의 가장 큰 부분이 프레임 워크에서 작성하고 테스트하지 않아도 제공됩니다. 개발에 소요되는 시간과 실수 가능성을 줄이는 모든 것.

내 결론은 중요한 것은 MVC 패턴 및 관심 분리의 이론 과 이론상의 이점을 이해하는 것입니다. 그런 다음 개발해야하는 것과 환경 (알려진 기술 또는 알려진 기술)에 따라 보일러 플레이트 코드 작성을 면제하는 프레임 워크를 선택하고 절약 된 시간을 사용하여 필요한 모든 사항과 사용자가 기대하는 바를 신중하게 분석하십시오.