MVC 란 무엇이며 그 장점은 무엇입니까?[닫은]
-
09-06-2019 - |
문제
mvp 및 mvc 란 무엇이며차이는 있지만 실제로이 질문에 답하지 않았습니다.
저는 MVC가 저와 제 작업 파트너가 사용할 프레임 워크의 일부이기 때문에 최근에 MVC를 사용하기 시작했습니다.프로세스가 쉽고 디스플레이와 분리되어 보였기 때문에 선택했습니다.이 외에도 우리가 알지 못하거나 놓칠 수있는 장점이 있습니까?
장점
- 디스플레이와 처리가 분리됨
단점- 지금까지 없음
해결책
MVC는 m odel, v iew 및 c ontroller를 분리 한 것입니다. 그것은 단순히 패러다임입니다. 수업을 디자인 할 때 염두에 두어야 할 이상입니다. 세 가지 범주의 코드를 하나의 클래스로 혼합하지 마십시오.
예를 들어, 표 그리드 보기 는 일단 표시된 데이터를 분명히 나타내야하지만 데이터를 검색 할 위치 또는 기본 구조 ( model )은 같습니다. 마찬가지로 열을 합산하는 기능이있을 수 있지만 실제 합산은 컨트롤러 에서 발생합니다.
'파일 저장'대화 상자 (보기 )는 사용자가 선택한 경로를 컨트롤러 로 전달한 다음 모델을 묻습니다. 데이터를 저장하고 실제 저장을 수행합니다.
이렇게 분리 된 책임 덕분에 길을 유연하게 조정할 수 있습니다. 예를 들어, 뷰는 기본 모델을 고려하지 않기 때문에 여러 파일 형식을 지원하는 것이 더 쉽습니다. 각각에 대해 모델 하위 클래스를 추가하기 만하면됩니다.
다른 팁
문제의 분리가 가장 큽니다.
이러한 구성 요소를 구분할 수 있으면 코드를 더 쉽게 재사용하고 독립적으로 테스트 할 수 있습니다.MVC가 실제로 무엇인지 모르는 경우 "모델"이 무엇인지 (비즈니스 개체 / DataSets / DataTables인지 또는 기본 서비스를 나타내는 지 여부에 관계없이) 여전히 약간의 논쟁이 있기 때문에 사람들의 의견을 이해하려고 노력할 때주의하십시오.레이어).
자신을 MVC라고 부르지 만 정확하지 않고 Jeff의 기사 에 따르면 MVC는 개발자가 완전히 동의하지 않을 것이라고 생각하는 논쟁의 여지가 있습니다.
다른 모든 MVC 유형에 대한 좋은 요약은 여기에서 확인할 수 있습니다..
MVC 패턴 사용의 또 다른 이점은 MVP / 발표자 우선 및 기타 여러 MV * 패턴과 같이 디자인에 대한 다른 접근 방식 에 대한 문을 열어 준다는 점이라고 생각합니다.
디자인 "구성 요소"의 근본적인 분리가 없다면 이러한 기술의 채택은 훨씬 더 어려울 것입니다.
더 많은 인터페이스 기반 코드를 만드는 데 도움이된다고 생각합니다. 개별 프로젝트 내 에서뿐만 아니라 사용 된 "grunt"코드를 훨씬 더 많이 템플릿 할 수 있다는 것을 의미하는 공통 "뷰"개발을 거의 시작할 수 있습니다.귀하의 응용 프로그램에서.예를 들어, 단순히 많은 데이터를 가져 와서 공통 그리드 레이아웃에 던지는 매우 추상적 인 "데이터보기"입니다.
수정 :
제가 생각할 수있는 한 가지 단점은 뷰의 데이터 (예 : 뼈 위치와 같은 게임 애니메이션 데이터)에 정말 빠르게 액세스해야하는 경우입니다.이 경우 분리 레이어를 유지하는 것은 매우 비효율적입니다.
그렇지 않으면 그래픽 기반보다 데이터 기반이 더 많은 다른 대부분의 애플리케이션에서는 UI를 구동하는 논리적 방법처럼 보입니다.
스택 오버플로 팟 캐스트를 따라 가면 Jeff (및 Geoff?)가 그 위대함에 대해 이야기하는 것을들을 수 있습니다. http://blog.stackoverflow.com/2008/08/podcast-17/ .그러나 이러한 별도의 레이어를 사용한다는 것은 미래에는 일이 더 쉬워지고 지금은 더 어려워진다는 것을 의미합니다.레이어로 인해 작업 속도가 느려질 수 있습니다 .그리고 당신은 그것들이 필요하지 않을 수도 있습니다.그러나 그것이 무엇인지 배우는 것을 멈추게하지 마십시오. 크고 강력하며 수명이 긴 시스템을 구축 할 때 매우 중요합니다.
컨트롤러에 의해 제어되는 Model과 View를 분리하고, 모델에 관한 한, 귀하의 모델은 OO 아키텍처를 따라야하며, 향후 개선 사항 및 코드 기반의 기타 유지 관리가 매우 쉬워야하며 코드 기반을 재사용 할 수 있어야합니다.
동일한 모델은 임의의보기 수를 가질 수 있습니다. 예를 들어 동일한 정보를 다른 그래픽보기로 표시 할 수 있습니다. 동일한 뷰는 다른 모델 번호를 가질 수 있습니다. 예) 다른 상세 정보는 막대 그래프와 같이 단일 그래프로 표시 될 수 있습니다. 이것이 바로 View와 Model의 재사용 성입니다.
보기 향상 및보기 작성을위한 기타 새로운 기술 지원을 쉽게 구현할 수 있습니다.
뷰에 대해 작업하는 사람은 기본 모델 코드베이스와 아키텍처에 대해 알 필요가 없으며 모델의 경우도 마찬가지입니다.
MVC는 단순한 웹 앱 개발의 맥락에서 개발자가 클라이언트를 수신하고 처리하는 메서드와 별도로 앱의 프레젠테이션 레이어 (보기)에 HTML 마크 업을 쉽게 유지할 수 있도록하는 일반적인 디자인 패턴입니다. 요청 (컨트롤러) 및 뷰 (모델) 내에서 반환되는 데이터 표현. 문제의 분리, 즉 하나의 기능적 목적 (예 : 클라이언트 요청 처리)을 제공하는 코드를 완전히 다른 기능적 목적 (예 : 데이터 표현)을 제공하는 코드로부터 격리하는 것입니다.
웹 사이트를 구축하는 데 5 분 이상을 소비 한 사람이 HTML 마크 업, 자바 스크립트 및 CSS를 별도의 파일에 보관해야하는 필요성을 인식 할 수있는 이유에 대한 동일한 원칙입니다. 나중에 편집 할 수없는 스파게티로 끝납니다.
가능한 "단점"을 요청 했으므로 : 저는 소프트웨어 아키텍처 설계에 대한 권한이 없지만 MVC에서 개발 한 경험을 바탕으로 엄격한 규정을 따르는 것도 중요하다고 생각합니다. , 노 프릴 MVC 디자인 패턴은 1) 경량 웹 앱 또는 2) 대규모 엔터프라이즈 앱의 UI 레이어에 가장 유용합니다. MVC에는 비즈니스 로직, 도메인 모델 또는 앱의 데이터 액세스 레이어에있는 모든 것에 대한 명시적인 정의가 포함되어 있지 않기 때문에이 사양이 더 이상 언급되지 않은 것에 놀랐습니다. ASP.NET MVC에서 개발을 시작했을 때 (즉, 다른 소프트웨어 아키텍처가 존재한다는 사실을 알기 전에) 결국 매우 부풀어 오른 컨트롤러 나 심지어 엔터프라이즈 응용 프로그램에서 작업 했더라면 가질 수있는 비즈니스 논리로 가득 찬 뷰 모델을 보게 될 것입니다. 내 코드에 익숙하지 않은 다른 개발자가 수정하기 어렵게 만들었습니다 (예 : 더 많은 스파게티).
여기에서 언급하지 않은 MVC의 주요 장점 중 하나는 MVC가 SEO를 가능하게하는 RESTful URL을 제공한다는 것입니다.컨트롤러와 액션의 이름을 현명하게 지정하면 검색 엔진이 사이트 URL 만 살펴보면 사이트를 더 쉽게 찾을 수 있습니다.예를 들어, www.MyCarSale을 선택할 수있는 페이지를 참조하는 www.MyCarSale.com/product/6548 대신 자동차 판매 웹 사이트와 사용 가능한 Lamborghini Veneno 자동차를 표시하는 페이지가 있습니다.SEO 목적의 .com / SportCar / Lamborghini-Veneno URL
MVC 아키텍처의 주요 장점은 코드 재사용, 코드 유지 관리 및 유지 관리가 용이하도록 모델,보기 및 컨트롤러에서 프로젝트 계층을 차별화하는 것입니다.가장 좋은 점은 개발자가 프로젝트 유지 관리 사이에 코드를 추가하는 것이 기분이 좋다는 것입니다.
! [mvc 아키텍처] [1]
모델-뷰-컨트롤러 (MVC)는 사용자 인터페이스를 구현하기위한 소프트웨어 아키텍처 패턴입니다.주어진 소프트웨어 응용 프로그램을 상호 연결된 세 부분으로 나누어 정보의 내부 표현과 사용자에게 정보를 제공하거나 받아들이는 방식을 분리합니다.