계층화 된/계층화 된 아키텍처 - 코드 분리

Question

지난 몇 달 동안 나는 spring-mvc으로 엔터프라이즈 응용 프로그램을 작성했습니다. 이 레이어들/계층들에 대한 3 계층 아키텍처에 대해 들었습니다 - UI, 비즈니스 로직 및 DAO.이 아키텍처는 저에게 알려져 있습니다. 그러나 일부 spring-mvc 기업 프로젝트에서 작업하는 동안 나는 (코드 흐름에 따라)이 같은 일부 층을 발견했다 -

Controller 
    | 
    v 
Service 
    | 
    v 
Manager 
    | 
    v 
    Dao 

나는 3 층 구조에 비해 조금 혼란 위 layerd 구조를 발견했다. 왜냐하면 나는 서비스과 관리자 층 모두로 작성된 비즈니스 로직을 발견했기 때문입니다. 혼란은 배려 부족으로 야기 될 수도 있고, 오히려 이것을하는 다른 옵션이 없을 수도 있습니다. 그러나 3 계층 아키텍처와 마찬가지로 각 계층 뒤에는 몇 가지 이유가있을 수 있습니다. 누군가가 왜이 계층을 설명 할 수 있습니까?

아마 이것은 stackoverflow의 사양을 기준으로 좋은 질문이 아닙니다. 그러나 이것은 나 같은 새로운 개발자를위한 제안/팁만큼이나 도움이 될 것입니다.
감사합니다.

Answer 1

당신이 설명하는 것과 매우 유사한 디자인을 구현했습니다. 배후에있는 나의 추론은 "관리자"레이어가 특정 데이터 액세스 코드를 추상화하여 서비스 계층에서 벗어나는 것을 도울 것이라고했습니다.

그래서이 (의사 코드)처럼 보였다 서비스 :

function getCustomer(id) { 
    sql = "select * from customer where id = @id"; 
    return db->execute(sql, id); 
} 

이처럼 보이는 결국 :

function getCustomer(id) { 
    return dbo->getCustomerById(id); 
} 

이 추가 레이어 내 프로젝트에 대한 몇 가지를했다. 모든 데이터 액세스를 중앙 집중화하여 다른 프로젝트에서 관리자 클래스를 사용할 수있게했습니다. 또한 내 서비스 계층 코드를 변경하지 않고도 다른 데이터 저장 전략 (구조화 된 SQL -> nosql) 사이를 쉽게 전환 할 수있는 옵션 (천국 금지)을 제공했습니다.

Answer 2

이것은 오래된 (그러나 여전히 널리 사용되는) 데이터 - 비즈니스 로직 - UI 모델이 아니라 MVC (모델 - 뷰 - 컨트롤러) 아키텍처입니다. 그것들은 단순히 다른 아키텍처 모델이며 비교가 가능하고 대조되는 동안 가장 명확하게 서로를 매핑하지 않습니다. MVC를 사용하는 프로젝트에서 일하고 있다면 MVC (또는 특히 Spring-MVC)에 대한 책을 찾고 공부하는 것이 좋습니다.