MVC는 디자인 패턴 또는 아키텍처 패턴입니까?

MVC는 디자인 패턴 또는 아키텍처 패턴입니까?

---

Sun 과 Msdn 에 따르면 디자인 패턴입니다.

Wikipedia 에 따르면 건축 패턴입니다.

디자인 패턴에 비해 아키텍처 패턴은 규모가 더 큽니다. (Wikipedia- 건축 패턴 )

아니면 디자인 패턴이있는 건축 패턴일까요?

어느 것이 사실입니까?

---

MVC는 아키텍처 패턴에 가깝지만 완전한 응용 프로그램은 아닙니다. MVC는 대부분 응용 프로그램의 UI / 상호 작용 레이어와 관련이 있습니다. 여전히 비즈니스 로직 레이어, 아마도 일부 서비스 레이어 및 데이터 액세스 레이어가 필요할 것입니다. 즉, n 계층 접근 방식을 사용하는 경우입니다.

---

왜 그들 중 하나가 사실이어야합니까?

관점에 따라 둘 다 사실 일 수 있습니다.

MVC는 애플리케이션 아키텍처의 기반을 형성하는 경우 아키텍처 패턴이 될 수 있습니다.

또한 모든 애플리케이션에 적용 할 수있는 추상적 인 개념 인 단순한 디자인 패턴으로도 볼 수 있습니다.

---

디자인 패턴 은 코드를 효과적으로 작성하는 방법을 알려줍니다 ( 코드 메트릭 고려 ).

몇 가지 이점 :

1. 쉽게 유지 보수 가능
2. 높은 재사용 성
3. 추상화로 인해 읽기 가능

아키텍처 패턴 은 리소스를 효과적으로 활용하는 방법을 말합니다.

1. 프로그래머 및 그래픽 디자이너와 같은 병렬 작업 실행은 병렬로 작업 할 수 있습니다.
2. 여러 기술을 활용하여 소프트웨어를 구축 할 수 있습니다.

MVC에서 a). 자바 스크립트 템플릿을 사용하여 뷰를 만들 수 있으며 html도 사용할 수 있습니다 . b). 컨트롤러는 .NET 프레임 워크로 작성 될 수 있으며 c). 모델은 Java로 작성할 수 있습니다. json 데이터 만 반환하는 Java 서비스를 사용할 수 있습니다.

디자인 패턴에서는 Java의 AdminUser 클래스, C #의 Customer 클래스, Php의 Partners 클래스 및 Ruby의 팩토리 패턴과 같은 여러 기술로 코드를 작성할 수 있는 패턴 을 구현할 수 없습니다 . 흠 .. 너무 쉬워요? :)

---

얼마 전에 답변을 받았지만 아직 MVC를 유명하게 만든 책을 언급 한 사람은 아무도 없습니다 : 패턴 지향 소프트웨어 아키텍처 (POSA), Buschmann 등이 1996 년에 출판했습니다. 디자인 패턴 책만큼 널리 읽히지는 않지만 , Gamma 등이 작성한 POSA는 패턴 커뮤니티에서 사용하는 기본 책 중 하나입니다.

아, 그리고 POSA는 MVC를 아키텍처 패턴으로 매우 명확하게 식별합니다. 내 직감은 MS와 Sun이 엉성하고 모든 패턴을 "디자인 패턴"이라고 부르는 것입니다.

---

둘 다 사실이라고 생각합니다. Ruby on Rails와 같은 프레임 워크에서 MVC 의 특정 인스턴스화 를 보고있는 경우 해당 인스턴스화는 디자인 패턴에 가깝습니다. MVC를 일반적인 개념 으로 보면 아키텍처 패턴에 가깝습니다.

---

MVC는 항상 소프트웨어 아키텍처 책에서 프레젠테이션 레이어로 언급되고 소개되었습니다.

다음 책을 읽으십시오.

1. 기업용 Microsoft.NET 솔루션 설계 (Microsoft Press)

2. 전문 ASP.NET 디자인 패턴 (Wrox)

3. Microsoft.NET을 사용한 엔터프라이즈 솔루션 패턴 (Microsoft press)

4. 엔터프라이즈 애플리케이션 아키텍처의 패턴 (Addison Wesley)

5. 엔터프라이즈 아키텍처에 대한 실용 가이드 (연습 관)

---

10 명의 소프트웨어 아키텍트를 방에 배치하고 그들에게 모델-뷰-컨트롤러 패턴이 무엇인지 토론하게한다면, 결국 12 개의 다른 의견을 갖게 될 것입니다. … 일부 순수 주의자들은 내가“MVC”라고 부르는 것에 필연적으로 불만을 품을 것입니다. 이 웹 페이지 하단의 게시판에 불타는 댓글을 남겨주세요. 나는 MVC가 의미하는 바에 대해 다른 관점을 기꺼이 즐겁게 할 것이지만, 나는 상관하지 않는다는 것을 명심하십시오.

조쉬 스미스

---

MVC (모델 / 뷰 / 컨트롤러) 트라이어드 클래스 내부의 디자인 패턴에는 다음이 포함되며 이에 국한되지 않을 수 있습니다.

• Observer , 하나 (모델)에 대한 변경 사항이 변경된 개체 (모델)가 다른 개체 (뷰)의 세부 정보를 알 필요없이 다른 개수 (뷰)에 영향을 미칠 수 있도록 개체를 분리합니다.

• Composite , 개별 객체 (뷰 구성 요소) 중 하나를 처리하는 것처럼 그룹 객체 (복합 뷰)를 처리 할 수 ​​있습니다.

• Strategy , 뷰가 Controller 하위 클래스의 인스턴스를 사용하여 특정 응답 전략을 구현하는 경우 다른 전략을 구현하려면 인스턴스를 다른 종류의 컨트롤러로 교체하면됩니다.

• 뷰에 대한 기본 컨트롤러 클래스를 지정하는 Factory Method .

• 데코레이터 ,보기에 스크롤링 추가.

---

참고

• 4-6 페이지 (섹션 1.2 Smalltalk MVC의 디자인 패턴)
• 293 ~ 304 페이지 (관찰자 디자인 패턴)
• 163 ~ 174 페이지 (복합 디자인 패턴)
• 315 ~ 324 페이지 (전략 디자인 패턴)
• 107 ~ 116 페이지 (Factory Method 디자인 패턴)
• 175 ~ 185 페이지 (데코레이터 디자인 패턴)

Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, MA, 1994.

---

And according to Martin Fowler they are GUI architectures: Martin Fowler-GUI architectures

It depends on the size of the application, as it only affects GUI related classes, in a small one (mostly GUI) it could be considered an architectural pattern whereas in a huge one it would just be a design pattern that you apply to the GUI code (could be 10% of the apps code).

---

MVC is architecture pattern. Very clearly stated and shown at http://molecularsciences.org/zend/mvc_model_view_controller

참고URL : https://stackoverflow.com/questions/1866821/is-mvc-a-design-pattern-or-architectural-pattern