MVC에서 API 요청을 어디에 두어야합니까?

25

MVC 패턴을 사용하여 웹 응용 프로그램을 작성 중입니다. 이러한 종류의 아키텍처를 따르면 데이터베이스와 상호 작용하는 데 사용되는 모든 방법이 모델 에서 구현됨을 알 수 있습니다 .

그러나 웹상에서 다른 사람이 노출 한 서비스를 호출해야하는 경우 어떻게됩니까? 예를 들어, 내 페이지의 모든 팔로어를 얻기 위해 Facebook API에 액세스하고 싶습니다. 이러한 메소드를 어디에 두어야합니까?

분명히 뷰는 이 모듈을 발표하기 위해 최선을 다하고 있습니다 때문에 좋은 아이디어 아닙니다 컨트롤러가 데이터를 검색하는 데 사용되어서는 안하지만 모델은 보통 데이터베이스와 상호 작용하기 위해 최선을 다하고 있습니다.

그래서 그것에 대해 힌트를 줄 수 있습니까? MVC 아키텍처에 대해 실수를 저지르고 있는지 알려주세요.

mvc api

— Ema.jar
소스

2

MVC 응용 프로그램을 지원하는 데 사용하는 라이브러리 및 프레임 워크를 나열하면 사람들이 더 나은 답변을 제공 할 수 있다고 생각합니다. MVC 패턴은 기술에 구애받지 않지만 모든 프레임 워크가 명시 적으로 따르지는 않습니다. 또한 대부분의 성숙한 프레임 워크에는 이미 뛰어난 문서가 있으며 어떤 프레임 워크를 사용하고 있는지 알면 자신의 사고 방식을 따르는 기존 설명으로 쉽게 안내 할 수 있습니다.

— CLW

2

데이터 베이스? 데이터 소스? 단지 데이터입니다.

2

"MVC"가 무엇인지에 대한 의견이 너무 많아서이 질문에 대한 답이 너무 추상적입니다.

— RemcoGerlich

2

또한 프론트 엔드 Javascript 코드에서 API를 호출하고 백엔드 "MVC"항목에 전혀 영향을 미치지 않도록하십시오.

— RemcoGerlich

@Remcogerlich 그것이 내가보고있는 실제 구현의 추가를 제안한 이유입니다. 그는 mvc의 백엔드 및 프론트 엔드 구현을 처리 할 수 있습니다. 이러한 차이점을 더 잘 설명 할 수있는 다른 패턴이있을 수도 있습니다.

— CLW

37

모델은 데이터베이스와의 상호 작용에만 국한되지 않으며 데이터를 가져오고 조작하는 데 책임이 있습니다.

따라서 데이터가 데이터베이스 또는 웹 서비스에서 왔거나 심지어 완전히 임의적 인 경우 뷰와 컨트롤러에 차이가 없어야하므로 모델에서 수행해야합니다.

MVC는 다른 표현 레이어 만 분리하는 프리젠 테이션 패턴입니다.

그 모델이 스파게티 코드의 균일 한 혼란이어야한다는 의미는 아닙니다. 모델 자체도 계층화 할 수 있지만 컨트롤러는 데이터의 출처를 알 수 없습니다.

모델의 공용 메소드는 다음과 같이 구성 될 수 있으며 (의사 코드) 컨트롤러에서 호출 할 수 있습니다.

public MyDataClass getData(int id) {
    WebServiceData wsData = WebService->getData(id);
    DatabaseData dbData = ORM->getData(id);
    return new MyDataClass(wsData, dbData);
}

WebService그리고 ORM의존성 삽입 (Dependency Injection)을 통해 모의 객체로 대체 될 수있는 인터페이스의 인스턴스해야 할 수도 있습니다, 그러나 당신의 컨트롤러와 뷰는 테스트 목적 변경할 필요가 없습니다.

— 잔여
소스

8

모델에는 어떤 논리도 없어야하므로 어떤 것과도 직접 상호 작용하지 않아야합니다. MVC 패턴은 컨트롤러에 모든 로직을 배치해야합니다. 이 컨트롤러는 DB, API 등에 접속하여 필요에 따라 모델을 업데이트해야합니다. 이를 통해 모델 기술을 무시할 수 있으며 프리젠 테이션을 위해 다양한 뷰로 전달하고 추가 조작을 위해 컨트롤러에 전달할 수있는 스토리지 메커니즘을 제공합니다.

— CLW

3

@CLW : 모델! = 데이터 모델. 자세한 내용은 stackoverflow.com/a/14045514/124983

— Residuum

2

@CLW : 비즈니스 로직 은 M, V 또는 C 로되어서 는 안됩니다 . 모델은 데이터 저장소의 추상화이며 뷰와 컨트롤러는 사용자 인터페이스입니다. 그것들은 당신이 구축하고있는 실제 어플리케이션의 주변부이며, "코드 만"이어야하며, 데이터베이스 나 웹과 같은 것에 대해 알 필요가 없습니다.

— RemcoGerlich

2

"모델"부분은 수백 가지의 다른 방식으로 해석됩니다. 나는 항상 모델이 대표적이라는 것을 배웠다. 모형 열차는 실제 열차와 유사하게 움직이는 작은 부분이있는 실제 열차를 나타냅니다. 마찬가지로 앱의 모델은 소프트웨어를 대체 할 시스템과 프로세스를 나타냅니다. 따라서 모델에는 동작이 있습니다 . 그 행동은 "비즈니스 로직"을 통합합니다. 따라서 순수한 CRUD 데이터 액세스, UI 및 interop을 무시할 때 남은 것은 아마도 "모델"일 것입니다. 도메인 클래스, 비즈니스 규칙 등

— anaximander

1

@RemcoGerlich 나는 비즈니스 로직에 대해 아무 말도하지 않았다. MVC에 대한 대부분의 해석은 모델을 요구하는 것은 애플리케이션 상태를 나타내는 단순한 구조체 일 뿐이므로 DB, API 등을 접촉하는 책임은 모델 내에 두지 않아야한다고 언급했습니다. 로직 프리. 데이터베이스와 통신하는 의무는 컨트롤러 또는 컨트롤러가 관리하는 다른 개체에 해당해야합니다.

— CLW

12

M, V 및 C가 무엇인지에 대한 일반적인 (의도적 인?) 오해가 있습니다. 아니 역할에 대해 그들이 가지고,하지만 있습니다 그들은.

MVC의 원래 데스크탑 GUI 정의에서는 모듈 이었습니다. 일반적으로 응용 프로그램에는 여러 가지가 있으며 때로는 삼중으로 작동하며 때로는 일부 컨트롤러가 혼합하고 일치시킬 수있는 다양한 뷰와 모델이 있습니다.

웹 프레임 워크 인 OTOH에서는 레이어 로 표시되는 경향이 있습니다. 각 레이어 중 하나 일 뿐이며 대부분 하위 계층 추상화 수준을 다루는 데 주로 중점을 둡니다. "모델 레이어는 데이터베이스를 추상화합니다", "뷰 레이어는 프레젠테이션을 구현합니다", "컨트롤러 레이어는 사용자 입력을 처리합니다. "

따라서 이미 데이터베이스와의 상호 작용에 전념 하는 모델이 있으며 이제 소스 API를 처리 하기 위해 다른 모델 을 만들어야 합니다. 가능한 한 유사하게 만들면 대부분의 컨트롤러 및 뷰 코드가 두 모델에서 완벽하게 작동 할 수 있습니다.

— 하비에르
소스

1

동의 함 : 모델은 항상 전체 문제 영역이어야합니다. 복잡한 앱에서는 항상 코드의 대부분이어야합니다. 사용자 인터페이스를 변경해도 웹 사이트에서 GUI 또는 명령 줄 응용 프로그램으로 변경하더라도 변경되지 않는 모든 코드로 구성되었습니다. 컴파일러를 생각해보십시오. 명령 행 UI에서 GUI 또는 웹 UI로 이동하면 코드의 아주 작은 부분 만 변경됩니다. 이러한 응용 프로그램의 모든 내장은 모델입니다.

— Kevin Cathcart

1

용어의 원래 스몰 토크 사용 에서 인터페이스의 모든 UI 컨트롤에는 고유 한 모델, 뷰 및 컨트롤러가있었습니다.

— RemcoGerlich

5

MVC에 대한 토론에서 어려움의 일부는 다른 그룹이 다른 것을 의미하기 위해 다른 그룹이 그것을 채택했다는 것입니다. Rails 앱에서 사용되는 MVC의 구현은 Swing 앱을 작성하는 사람에게는 거의 인식되지 않을 것입니다. MVC가 여전히 잘 정의되어있는 한, 그것은 여러 가지로 구현 될 수있는 일련의 지침 원칙 (핵심 응용 프로그램을 시각적 표현과 분리하고 두 가지를 함께 연결할 수있는 유연한 메커니즘 제공)에 가깝습니다. 방법.

실제로 다른 MVC 파생 디자인에 다른 이름 을 부여하거나 (이에 대한 논의는 Martin Fowler 의이 기사 참조 ) 심지어 정확한 이름 지정 을 포기하는 경향 이 있습니다. 뼈대.

따라서 사용중인 "MVC"버전을 모른 채 대답하기가 어렵습니다. 그러나 API 요청은 일반적으로 핵심 응용 프로그램 (다른 시각적 표현을 사용하기로 결정한 경우 변경해서는 안되는 부분)의 일부이며, 많은 구현에서 전체적으로 모델 내에 포함됩니다.

— James_pic
소스

2

여기서 모델은 다음과 같이 설명됩니다.

모델은 컨트롤러로 검색되어보기에 표시되는 데이터를 저장합니다. 데이터가 변경 될 때마다 컨트롤러에 의해 업데이트됩니다.

컨트롤러가 서비스 호출 논리를 포함하거나 별도의 Service객체를 호출한다고 말하고 싶습니다 . 서비스가 분리되어 있으면 테스트를보다 쉽게 만들 수 있습니다. 예를 들어 네트워크를 통해 서비스에 연결할 수없는 경우 로컬 TestService에서 응답을 제공 할 수 Service있습니다.

또한 컨트롤러가 서비스를 호출 함을 나타내는이 답변을 확인하십시오.

— 없는
소스

2

모델에는 실제 코드가 포함되어서는 안되며 컨트롤러에서 조작하고 뷰에 의해 표시되는 컨텐츠를 관리하는 데 사용되는 더 많은 메시지 또는 구조체로 간주되어야합니다.

컨트롤러는 API, 데이터베이스, 서비스 등에 문의하여 변경을 요청하고 모델에 필요한 업데이트를 관리해야합니다.

MVC 패턴의 전체 장점은 로직 (컨트롤러)을 뷰 및 상태 (모델)에서 분리한다는 것입니다. 그렇게하면 뷰와 모델을 변경할 수 없으므로 컨트롤러의 코드 만 부작용을 만들 수 있습니다.

또한 다양한 컨트롤러와 뷰간에 모델을 공유 할 수 있으므로 코드를 더 잘 재사용 할 수 있습니다.

— CLW
소스

4

여기서 "모델"이라고 말할 때 IMO가 별도 인 "viewmodel"을 말하는 것 같습니다. 뷰 모델은 컨트롤러에서 뷰로 데이터를 가져 오며, 뷰의 구현 세부 사항이거나 실제로 뷰에 맞지 않는 뷰와 컨트롤러 간의 통신 측면입니다 (표시 방법에 따라 다름). MVC의 "모델"은 데이터, 구조 및 동작을 통합 한 시스템을 나타내는 시스템 모델을 나타냅니다. 모델은 상태와 논리입니다. Controller는 View가 조작 될 때 로직이 실행되고 상태가 변경되는 원인입니다.

— anaximander

@anaximander 아니요 MVC를 상당히 엄격하게 해석하여 모델을 언급하고 있습니다 (Wikipedia, Microsoft MVC, Head First Design 패턴 등 참조). 이러한 경우 모델은 데이터 전달을위한 단순한 구조체에 지나지 않습니다. 뷰 모델과 같은 것은 없습니다. Microsoft MVC 구현은 모델에 다양한 속성을 추가하지만 이는 무엇보다 편리합니다. 결국 MVC 패턴의 목적은 코드 분리를 잘 연습하고 부작용을 제한하는 것이 었습니다.

— CLW

1

여기서 나아갈 수도 있지만, 이것이 WebApp에 대해 생각하고 [복잡한] 원격 API로 작업하는 경우가 많습니다.

모델 (즉, 데이터 완화 함수 스택) 대신 클래스 (즉, 데이터 완화 메소드 라이브러리)로 만들 것입니다. 그것은 더 투명하고 더 논리 / 스키마에 독립적으로 작동하는 것처럼 보이며, 사용할 때마다 모델 / 컨트롤러 자체를로드-> 호출하지 않고도 어디서나 사용할 수 있습니다. 논리는 여전히 분리되어 있으며 데이터 포인트는 여전히 유연하며 클라이언트 AJAX-> appJSON-> appLIB-> remoteAPI-> remoteJSON 스태킹과 같은 이상한 경우 상호 운용성을 위해 더 열려있어 엔드 포인트를 간접적으로 폴링합니다.

— 다우 핀
소스