Java 웹 애플리케이션 예제에서 SpringMVC, Hibernate 및 일부 데이터베이스를 사용하고 있습니다.
이 작업을 수행하는 몇 가지 다른 방법이 있지만이 Spring 3 및 최대 절전 모드 통합 자습서 에는 모델 클래스, 뷰 (jsp) 및 컨트롤러의 서비스 및 dao 클래스가 있습니다.
내 질문은 서비스와 DAO 클래스가 똑같은 일을하지 않습니까? 왜 둘 다 필요합니까?
이것은 내가 실제로 사용하고있는 자습서였습니다 : http://fruzenshtein.com/spring-mvc-security-mysql-hibernate/
답변:
일반적으로 DAO는 가능한 한 가볍고 DB에 대한 연결을 제공하기 위해서만 존재하며 때로는 추상화되어 다른 DB 백엔드를 사용할 수도 있습니다.
서비스 계층은 DAO 및 클라이언트와주고받는 데이터에 대해 작동하는 논리를 제공하기 위해 존재합니다. 종종이 두 조각은 동일한 모듈로, 때로는 동일한 코드로 묶여 있지만 여전히 고유 한 논리 엔티티로 볼 수 있습니다.
또 다른 이유는 보안입니다. DB와 관련이없는 서비스 계층을 제공하면 서비스를 제외하고 클라이언트에서 DB에 액세스하는 것이 더 어렵습니다. DB가 클라이언트에서 직접 액세스 할 수없고 (서비스로 작동하는 사소한 DAO 모듈이없는 경우), 클라이언트를 인계 한 모든 공격자는 서비스 계층을 해킹하기 전에 서비스 계층을 해킹하려고 시도 할 수 있습니다. 가장 위생적인 데이터 액세스.
나는 문제의 글을 쓴 작가입니다. 다른 기술과 다른 아키텍처에서 일하는 것에 대한 공평한 분배를 얻었습니다. 위의 내용을 토대로 서비스 계층과 dao 계층을 갖는 것이 항상 좋은 생각이라고 안전하게 말할 수 있습니다. DAO는 데이터베이스에 /로부터 엔티티 개체를 추가 / 업데이트 / 삽입 / 선택만으로 제한되어야합니다. 로직 측면에서 추가 작업을 수행하려면 서비스 계층에 추가하십시오. 이를 통해 데이터베이스를 교체 할 때 (일부 데이터의 경우) 코드를 모듈화하고 쉽게 교체 할 수 있습니다. 이는 데이터베이스에서 데이터를 가져온 후에도 논리가 많은 보고서가 포함 된 응용 프로그램에 특히 적용됩니다.
또한 봄에는 서비스 계층에서 보안이 이상적으로 적용됩니다. 이 방법으로 변경하고 싶지 않습니다.
Adam Bien은 그의 책에서 JPA EntityManager가 DAO의 보편적 인 구현이라는 사실을 지적합니다.
Java EE 세계에서는 JPA 구현에 하나가 포함되어 있으므로 자체 DAO를 작성할 필요가 거의 없습니다. 서비스 계층 만 작성하면됩니다.
자신의 DAO 계층을 구현하는 것은 실제로 15 년 전의 매우 열악한 J2EE 아키텍처로 인한 숙취이지만 많은 사람들이 여전히 그렇게해야한다고 느낍니다. 이러한 사용자 지정 DAO 계층은 종종 EntityManager에서 해당 메소드를 호출하는 전달 함수 이상의 기능을 제공하지 않습니다.
따라서 귀하의 질문에 대답하려면 예, 서비스 계층과 DAO가 필요하지만 서비스 계층 만 작성하면됩니다.
서비스 계층이 대부분의 경우 불필요한 복잡성을 추가한다는 것을 알았습니다. 이론적으로는 비즈니스 계층을 dao 계층에 두는 것을 피하는 것이지만 결국 혼란을 초래할 수 있습니다. 일부 사람들조차도 가치를 추가하지 않는다고 생각하여 dao 계층을 완전히 제거하지 않았습니다. http://ayende.com/blog/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer
그러나 비즈니스 로직이 여러 개인 경우 예, 좋습니다. 서비스 계층을 만드는 것이 얼마나 중요합니까?
IMHO 서비스 계층은 컨트롤러와 DAO 계층 사이의 계층으로 간주 될 수 있습니다. 이 서비스 계층은 비즈니스 로직을 추가하고 뷰에 의해 렌더링되어야하는 것에 특정한 반환 객체를 생성 할 수있는 곳입니다.