2011-08-12 3 views
5

"철학적"측면 이외에 내 컨트롤러를 내 모델로 삼는 것이 좋지 않은가요?MVC : 모델, 뷰 및 컨트롤러를 분리하는 이유는 무엇입니까?

프로그래밍 시간이 절약 된 것 같습니다. 나는 컨트롤러와 모델 사이에 로직을 만들 필요가 없다. 왜냐하면 똑같은 것이기 때문이다. 그리고 저는 직접 그 견해와 상호 작용할 수 있습니다.

M과 C를 분리하는 이유는 무엇입니까? 모듈성, 즉 하나의 모델과 컨트롤러 세트를 다른 세트로 교체 할 수있는 능력 - 분리 할 수있는 유일한 이유는 무엇입니까? 모델에서 뭔가가 변하기 때문에 "스와핑 (swapping)"모듈은 모델과 컨트롤러를 모두 업데이트해야하는 것보다 훨씬 적게 발생합니다.


간단한 계산기, MVC의 개념에 따르면, 컨트롤러와 설정에 대한 뷰 (기본 설정과 같은, 또는 무언가)를 모두 가져야한다고 이상한 것 같다. 나는 이것이 간단한 예제라는 것을 알고 있지만, 모든 경우에 적용되는 것으로 보인다 (어쩌면 프레임 워크 제외).

+0

'mvc'이외의 태그를 모두 제거하는 것이 좋습니다.이 질문과 관련이 없습니다. –

답변

4

주된 이유는 코드 재사용 가능성 때문입니다. 전문 직업에 한 가지 프로그램 만 쓰려고한다면 아마도 중요하지 않습니다. 당신이 그것의 경력을 만들 계획이라면, 재사용 할 수있는 조각을 갖는 것은 가치가있다.잘 설계된 모델, 컨트롤러 및 뷰 클래스는 다른 프로그램에 손쉽게 놓을 수 있습니다. 나는 항상 이것을한다.

컨트롤러 인 UITableViewController을 고려하십시오. 이제 뮤직 트랙 (모델)을 처리하도록 독점적으로 설계된 경우를 상상해보십시오. 다른 작업을 원할 때는 완전히 다른 테이블 관리 클래스를 만들어야했습니다. 이 악몽을 피하는 것은 MVC가 Cocoa에서 많이 사용되는 이유입니다.

여러 가지 방법으로 분할 할 수 있습니다. 일부 언어는 위임보다는 과중한 하위 클래스입니다. 그러나 코코아에서 프로그램을 분할하는 주된 수단은 MVC이며 매우 잘 작동합니다.

편집 : 상업용 앱을 개발하는 세계에서 더 많은 이유가 있습니다.

  • MVC에서는 메모리 처리가 훨씬 쉽습니다. 모델 객체를 고정시키고 화면 밖에있을 때 뷰 객체 (및 많은 컨트롤러 객체)를 버릴 수 있습니다.

  • 컨트롤러와 뷰로 묶이지 않은 모델 객체를 직렬화하는 것이 더 쉽고 동일한 데이터를 여러 가지 방법으로 표시하는 것이 훨씬 쉽습니다. "간단한"텍스트 편집기에서도 분할 된 화면을 만들거나 동일한 문서를 보여주는 여러 개의 창을 만들 수 있습니다. MVC에서 매우 쉽습니다.

현재 또는 미래에 유연성이 필요하지 않으면 많은 아키텍처가 필요하지 않습니다. 그러나 대부분의 실제 프로젝트는 그렇게 간단하지 않습니다. MVC는 대규모 프로그램을 작성하고 모든 것이 함께 던져지면서 어려움을 겪었던 Xerox의 경험에서 자랐습니다.


편집 2 : 나는 당신의 이전 편집을보고했다 : "간단한 계산기, MVC의 개념에 따르면, 컨트롤러 및 기본 설정 등의 설정에 대한 뷰 (모두 가지고해야한다는 이상한 것 같다 , 또는 무언가). "

이것이 바로 MVC의 이유입니다. 계산기 응용 프로그램을 위해 특별히 사용자 설정을 저장하는 데 필요한 모든 것을 다시 코딩해야하는 것은 미친 것처럼 보일 것입니다. UI와 완전히 별개로 재사용 할 수있는 일반적인 "저장 사용자 설정"을 원할 수 있습니다. OS X에서는 NSUserDefaults이고, Calculator 앱은 정확하게이 방식으로 구성을 저장합니다.

+0

UITableViewController는 프레임 워크의 일부입니다. 프레임 워크가 MVC를 사용하는 것이 왜 좋은지 이해합니다. 그렇다면 개별 프로젝트에서 MVC를 사용해야하는 이유는 무엇입니까? – David

+0

프레임 워크가하는 것과 같은 이유로. 따라서 코드를 재사용 할 수 있으므로 문제의 일부분에 코드를 집중적으로 적용 할 수 있으므로 리팩터링이 쉬워집니다. 다시 한번 말하지만, 평생 동안 다른 프로그램을 쓰지 않고 오랫동안이 프로그램을 유지할 계획이 없다면, 모든 것을 함께 던지면 괜찮을 것입니다. 그러나 리팩토링하기 쉬운 재사용 가능한 코드와 프로젝트 모음은 장기간 전문 개발자 툴킷의 중요한 부분입니다. –

+0

하지만 그 논리로 코드베이스가 폭발합니다. 에디터에 대한 견해를 가지고 있어야합니다. 그런 다음 편집기 용 컨트롤러가 있어야합니다. 그런 다음 모델에 대한 제어권을 갖춰야합니다 (올바르게 작성되었는지, 유효성이 검증되었는지 등). 그런 다음 컨트롤러를 모델에 맞추어 붙입니다. – David

1

작동하는 경우 작동합니다. 기간. 모델, 뷰 및 컨트롤러를 분리하는 이유는 개발자 팀이 엔터프라이즈 응용 프로그램의 대부분의 개발을 수행한다는 아이디어를 중심으로 이루어집니다.

컨트롤러에서 작업하려고하는 개발자가 10 명 있다고 상상해보십시오. 그러나 그들이 원하는 것은 모델에 무언가를 추가하는 것입니다. 이제 컨트롤러가 고장 났습니까? 그들은 무엇을 했습니까?

1

모델은 일반적으로 컨트롤러간에 재사용 할 수있는 별도의 구성 요소입니다. 만약 당신이 이라면 절대적으로 여러 컨트롤러에서 모델을 재사용하지 않을 것입니다. 나는 이러한 걱정을 혼합하는 데 정말로 문제가 없습니다.

당신이 편향을 계획하고 있다면 MVC 디자인을 사용하는 이유도 있습니다. 어쩌면 상황에 따라 더 적합한 패턴이있을 수 있습니다. 컨트롤러가 모델 인 곳에서 한 일의 예를 들어 줄 수 있습니까? 그것은 우리가 당신이 더 잘하려고 노력하는 것을 이해하는 데 도움이 될 것입니다.

+0

기본 텍스트 편집기 인 경우에도 M과 C를 구분하는 것은 이치에 맞지 않습니다. 왜 편집기의 내부 데이터에 실제 문서가 포함되어서는 안됩니까? – David

+0

"간단한"텍스트 편집기에서도 동일한 텍스트 파일을 보여주는 여러 개의 창 또는 동일한 창에서 다른 부분을 보여주는 여러 개의보기가 필요할 수 있습니다. 당신이 섞으면 힘들어요. 분리하면 쉽게. –

3

MVC는 개발 커뮤니티에서 잘 이해되는 표준 패턴입니다. 이 분리로 인해 각각의 책임 영역이있는 개별 구성 요소로서 읽기 쉽고, 문제 해결하기 쉽고, 찾기 쉽고, 테스트하기 쉽습니다.

사용 하시겠습니까? 당연히 아니지. 그러나 부품을 분리하여 보관하는 것은 일반적으로 좋은 생각으로 간주됩니다.

2

컨트롤러는 특정보기를 모델에 연결하는 방법을 알고 있습니다. 모델과 컨트롤러의 분리는 문서 및 유지 보수성 향상과 별도로 복잡한보기를 추가하지 않고도 여러 뷰에서 모델의 동일한 정보를 표시 할 수있는 즉각적인 이점이 있습니다.

동일한 애플리케이션의 여러 뷰뿐만 아니라 여러 버전의 애플리케이션에서 볼 수있는 여러 변형에도 적용됩니다. 귀하의 모델은 절연되어 있으며 논리적으로 깨끗합니다.

모델과 컨트롤러를 결합하는 것은 제 생각에는 고전적인 잘못된 경제입니다. 몇 분을 절약하는 것처럼 느낄 수 있지만 응용 프로그램이 개발되고 성장함에 따라 비용이 많이 듭니다.

0

MVC는 모두 관리 (데이터 분리, 표현 및 비즈니스 논리 분리)에 관한 것입니다. 이렇게 그것은 이렇게 : 작은 회사를 운영하는 경우에, MS 크기 관리가 진짜 끌기 일 것입니다. 그러나 당신이 거대 기업이라면, 큰 중간 관리자가 없다는 것은 불가능합니다.

정직하게도, 대부분의 대학 프로 그래밍 과제에서 필자는 모델링과 컨트롤러를 결합했다. 분리에 대한 필요성을 알지 못했기 때문이다. 그러나 큰 프로젝트를하고 있습니까? 결점은 당신이 분리하지 않으려 고하면 아주 분명합니다. 당신이 옳다고 느끼는 것을하십시오.

0

모델은보기와 컨트롤러에 의존하지 않습니다. 이것이 분리의 주요 이점 중 하나입니다. 이러한 구분은 모델을 시각적 표현과 독립적으로 구축하고 테스트 할 수있게합니다.

관련 문제