MVC와 Onion Archutecture의 구현을 제안하는 사람들을 보았습니다. 하지만 두 가지는 어떻게 공존 할 수 있습니까? 두 가지 별개의 아키텍처가 아닌가? 예를 들어 어니언 디자인의 컨트롤러는 어디에 있습니까?MVC는 어니언 아키텍처와 어떻게 공존 할 수 있습니까?
다른 목적 (동작, 생성 등)을 제공하고 시스템의 다른 모듈에서 독립적으로 구현 될 수 있기 때문에 하나 이상의 디자인 패턴 조합을 이해하지만 두 가지 구현 방법을 얻지는 않습니다 다른 아키텍처.
"양파 구조"는 주로 모델 계층과 그것이 포함하는 다양한 유형의 구조 (서비스, 리포지토리, 도메인 개체, 맵퍼, 작업 단위 등)에 주로 적용됩니다.
"어댑터"및 "생성자"또는 비즈니스 로직과 관련된 여러 가지 다른 이름으로 끝나지만 특정 표준에 적합하지 않은 다양한 사용자 지정 구조로 끝납니다. 그러나 그것들 모두는 (분명히) 별개의 층으로 끝납니다.
하지만 그 정도는 그렇습니다. 컨트롤러는 매우 간단한 구조로되어있다. 보기는 단지 조금 복잡합니다 ... 실제로는 presentation objects을 사용한다고 가정합니다.
TL : MVC가 양파 아키텍처와 공존하는 것을 막는 것은 없지만 MVC는 최대 규모로 기본으로 끝납니다.
MVC는 양파 외부에 살며 뷰/API 문제를 담당하여 양파 가운데 도메인 로직을 위임합니다.
누군가가 내 홈페이지를 방문한다고 가정합니다.이 홈페이지는보기를 반환하는 컨트롤러에 의해 처리됩니다. 모델은보기에 필요한 정보입니다. 일부 도메인 로직이 필요하다면 (일부 특별 제안이 홈페이지에 표시되었다고 가정 해 봅시다), 컨트롤러는이를 도메인에 위임합니다. 로직은 컨트롤러 자체 내에 있지 않습니다. 비슷하게, 도메인은 일종의 도메인 객체를 반환 할 것이고, 일반적으로 뷰에 의해 사용되는 모델로의 매핑이 필요할 것이다. 이보기는 응답에 리턴됩니다.
아직 작성하지 않았다면 기본적으로 같은 생각이므로 6 각형 아키텍처를 읽어보십시오.
양파 아키텍처에서 사용자 인터페이스는 외부 레이어에 명시 적으로 정의됩니다. 컨트롤러는 애플리케이션 인터페이스의 일부입니다. 그들은 모델을 향해 내면적으로 바깥에있을 것입니다. (모델을 감쌀 수있는 비즈니스 인터페이스를 따라 간다.) – David
질문을 던지면 ... MVC 패턴을 어니언 아키텍처에서 사용할 수 없다고 생각하게 만드는 이유는 무엇입니까? – David