MVC에서는 DAO가 컨트롤러 또는 모델에서 호출되어야합니다.


14

Controller 클래스에서 직접 DAO가 호출되고 Model 클래스에서 DAO가 호출되는 DAO에 대한 다양한 주장을 보았습니다. 사실 개인적으로 MVC 패턴을 따르는 경우 컨트롤러가 DAO와 결합해서는 안되지만 Model 클래스는 내부에서 DAO를 호출하고 컨트롤러가 모델 클래스를 호출해야합니다. 왜냐하면, 우리는 웹 애플리케이션과 분리하여 모델 클래스를 분리하고 REST 서비스가 모델 클래스를 사용하는 것과 같은 다양한 방법으로 기능을 노출 할 수 있습니다.

컨트롤러에서 DAO 호출을 작성하면 REST 서비스가 기능을 올바르게 재사용 할 수 없습니까? 아래 두 가지 접근 방식을 요약했습니다.

접근법 # 1

  public class CustomerController extends HttpServlet {

    proctected void doPost(....)  {

            Customer customer = new Customer("xxxxx","23",1);
            new CustomerDAO().save(customer);

    }


 }

접근법 # 2

  public class CustomerController extends HttpServlet {

    proctected void doPost(....)  {

            Customer customer = new Customer("xxxxx","23",1);
            customer.save(customer);

    }


 }

 public class Customer {

   ...........

   private void save(Customer customer){

        new CustomerDAO().save(customer);

   }

}

참고 -

Model 정의는 다음과 같습니다.

모델 : 모델은 응용 프로그램 도메인의 동작 및 데이터를 관리하고 해당 상태에 대한 정보 요청 (일반적으로보기)에 응답하고 상태 변경에 대한 지시 (일반적으로 컨트롤러)에 응답합니다.

이벤트 중심 시스템에서 모델은 정보가 변경 될 때 관찰자 (일반적으로보기)에게 반응 할 수 있도록 알립니다.

나는 # 1 또는 # 2를 사용하는 많은 사람들을 발견하기 때문에 이것에 대한 전문가 의견이 필요할 것입니다.


1
컨트롤러는 모델에서 모든 것을로드하고 뷰로 전달해야합니다.
jgauffin

당신은 제안 접근 # 2입니까?

1
"컨트롤러는 뷰의 모델 표현을 변경하기 위해 명령을 관련 뷰로 전송할 수 있습니다 (예 : 문서를 스크롤하여). 모델의 상태를 업데이트 (예 : 문서 편집)하기 위해 명령을 모델로 전송할 수 있습니다." .. 음 .. 컨트롤러가 데이터를 추출하거나 전달해야한다고 어디에서 말합니까?
mefisto

답변:


31

제 생각에는 MVC 패턴과 3 계층 아키텍처를 구별해야합니다. 요약하면 :

3 계층 아키텍처 :

  • 데이터 : 지속 데이터;
  • 서비스 : 응용 프로그램의 논리적 부분;
  • 프리젠 테이션 : hmi, webservice ...

MVC 패턴은 위의 아키텍처의 프리젠 테이션 계층에서 발생합니다 (웹 앱용).

  • 데이터 : ...;
  • 서비스 : ...;
  • 표시:
    • 컨트롤러 : HTTP 요청을 차단하고 HTTP 응답을 반환합니다.
    • 모델 : 표시 / 처리 할 데이터를 저장합니다.
    • 보기 : 출력 / 표시를 구성합니다.

일반적인 HTTP 요청 의 수명주기 :

  1. 사용자는 HTTP 요청을 보냅니다.
  2. 컨트롤러가이를 가로 챈다.
  3. 컨트롤러는 적절한 서비스를 호출합니다.
  4. 서비스는 적절한 dao를 호출하여 일부 지속 데이터를 반환합니다 (예 :).
  5. 서비스는 데이터를 처리하고 컨트롤러에 데이터를 반환합니다.
  6. 컨트롤러는 데이터를 적절한 모델에 저장하고 적절한 뷰를 호출합니다.
  7. 뷰 는 모델의 데이터로 인스턴스화 되고 HTTP 응답으로 반환됩니다.

1
"일반적인 HTTP 요청의 수명주기" 라고 부르는 것은 MVC가 아닙니다. 또한 DAO는 도메인 논리와 지속성 간의 상호 작용 / 번역을 용이하게하는 개체 일뿐입니다. 활성 레코드의 다른 이름 이 아닙니다 . 또한 .. 언제 모델이 프레젠테이션의 일부가 되었습니까?!
mefisto

1
@teresko 1) 예, MVC이지만 3 계층 구조입니다. 그렇지 않다면 왜? 2) 당신 말이 맞았습니다. 3) 전체 MVC 패턴이 프리젠 테이션 단계에서 발생하기 때문이다. 전형적인 예 : 스프링 MVC. 모델은 키-값 쌍을 포함하는 맵만입니다. SpringFuse 도이 선택을했습니다.
sp00m

2
나는 여기에서 @ sp00m에 동의해야합니다 ... 전형적인 HTTP 요청에 대한 그의 설명은 MVC 웹 응용 프로그램에 대해 정확하며 프레젠테이션 계층의 일부로 모델 (MVC에서 'M')의 위치도 정확합니다. . n- 계층 MVC 앱에서 '모델'은 일반적으로 아래의 나머지 계층에 대한 프리젠 테이션 계층의 정면입니다.
Eric King

8

모델 레이어에서.

더 정확하게 말하면 모델 계층에 포함 된 서비스에서 도메인 개체와 스토리지 논리 추상화 간의 상호 작용을 제어하기 때문입니다.

컨트롤러는 모델 레이어의 상태 변경에만 책임이 있습니다. DAO는 지속성 메커니즘의 일부입니다. 이것은 도메인 비즈니스 및 응용 프로그램 논리의 일부를 구성합니다. 컨트롤러에서 DAO와 상호 작용을 시작하면 프레젠테이션 계층 에서 도메인 논리가 유출 될 수 있습니다 .


서비스 계층을 사용하려면 DDD 패턴이어야합니까? 틀린 점 있으면 지적 해주세요. MVC에 서비스 계층이 있습니까?

당신은 할 수 있습니다. 서비스는 도메인 논리를 응용 프로그램 논리와 분리하는 데 사용됩니다. 이것이 필요 해지면 순수한 CRUD 도메인 구조 (활성 레코드)에서 스토리지 로직과 도메인 로직을 분리하는 것으로 이동합니다. 완전히 실현 된 모델 계층에는 지속성, 도메인 및 애플리케이션이라는 세 가지 논리적 분리가 있습니다.
mefisto

3

공식 MVC 패턴이 무엇을 요구하는지 잘 모르겠지만, 일반적으로 컨트롤러와 DAO 사이에 "서비스"계층이 있습니다. 컨트롤러는 요청에서 데이터를 가져와 해당 서비스 클래스로 전달합니다. 서비스 클래스는 모델 클래스를 전달하는 하나 이상의 DAO를 호출합니다. 그런 다음 해당 모델 클래스는 컨트롤러로 다시 전송되어 뷰 계층으로 전송됩니다. 여러 컨트롤러가 동일한 서비스 계층 방법을 사용할 수 있으므로 서비스 계층을 사용하면 재사용에 도움이됩니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.