프리젠 테이션, 나는이 질문에 대해 많이 생각하지만,이에 대한 몇 가지 분명한 답을 찾을 수없는

Question

서비스 및 DAO 계층 관계 :

내가 마지막에 이해 한 것처럼

, 비즈니스 계층은해야에만 작동 모델 개체. 우리가 어떻게이 데이터를 가져 왔는지에 관해서는 아무것도 알지 못합니다. DAO와는 별도로 비즈니스 레이어 API를 사용할 수 있습니다.

그래서 서비스 레이어 내에서 DAO 메소드 호출을 사용하는 것이 정상적인가요? 그렇지 않으면 이들 사이의 의존성을 줄이려고합니다. 따라서, I는 층들 사이의 관계 2 개 변형 참조 :

1. 컨트롤러 -> 서비스 -> 다오
2. 1 단계 : modelObject = 컨트롤러 -> 다오
   2 단계 : 컨트롤러 -> 서비스 (modelObject)

그래서 어떤 변형이 맞습니까?

Answer 1

이전 아키텍처에는 2 개의 계층 클라이언트와 서버가 있었지만 모든 데이터베이스 정보와 로직을 포함하고있었습니다.하지만 3 계층 아키텍처는 명확한 캡슐화와 계층 간 명확한 추상화를 가져 왔습니다. 두 계층 아키텍처에는 우수한 캡슐화가 없었습니다 추상화와 유지 보수성의 정도는 계층간에 명확한 캡슐화와 추상화가 없기 때문에 문제가되었습니다. 클라이언트 계층은 서비스를 직접 호출하지 않습니다. 대신 프록시를 사용하여 서비스를 호출합니다. 클라이언트의 경우 로컬 컴퓨터 프로그램에서 서비스를 호출 할 수 있습니다. 중간 계층에있는 서버의 프록시 호출 서비스를 통해 클라이언트. 컨트롤러, 서비스, serviceImpl, 모델과 관련된 데이터베이스가없는 중간 계층에 있다고 가정 할 수 있습니다. 중간 계층에있을 수 있습니다. 요점은 DB를 망칠해서는 안됩니다. 세 번째 계층에는 d가 있습니다. atabase dao는 db 관련 결과를 반환하는 컨테이너로 사용합니다. 클라이언트는 서비스를 통해 호출을 전달해야하며 DAO는 결과를 클라이언트에게 서비스를 통해 전달해야합니다.