2013-04-26 6 views
6

저는 주로 백엔드/데이터베이스의 데이터 CRUD 작업을 구성하는 웹 응용 프로그램을 작성하고 있습니다. 비즈니스 로직을 작성해야하는 경우가 있습니다 (개발을 위해 더 많은 비즈니스 로직을 구축해야합니다). 현재 각 UI 화면마다 모델 클래스, 서비스 클래스, DAO 클래스, 컨트롤러 (본질적으로 서블릿) 및 JSP 페이지 묶음을 만듭니다. 대부분의 경우 서비스 클래스는 DAO의 메소드를 호출하여 모델 객체를 전달합니다. 본질적으로 우리는 모델 클래스를 사용하여 UI 화면에서 데이터를 매핑합니다. 따라서 컨트롤러는 양식을 제출할 때 모델 객체를 채 웁니다. 웹 레이어에서 DAO 레이어로 분리 레이어를 유지하기 위해 서비스 클래스를 사용하기 시작했습니다. 하지만 때로는 서비스 클래스가 API 호출의 불필요한 레벨을 추가하는 것 같아서, 나는 DAO를 Controller에 삽입하고 작업을 더 빨리 완료 할 수 있다고 생각할 것입니다. 수행 할 추가 비즈니스 로직이있는 경우에만 서비스 클래스를 사용하려고합니다. 컨트롤러 -> DAO 대 컨트롤러 -> 서비스 -> DAO 제어 흐름을 고려하여 어떤 요소를 고려해야합니까?spring mvc 컨트롤러의 서비스 및 DAO 사용

+1

내가 현재 일을 시작할 때 이미 기존 프로젝트에 들어갔다. 나는 1 년 조금 넘게 여기에 왔습니다. 솔직히, 나는 DAO를 주입하기위한 별도의 레이어가 있어야만한다는 것을 깨달았습니다. 이 프로젝트는 단지 컨트롤러에 주입하는 것입니다. 이제이 사실을 알고 원 자성의 이점에 대해 준비 했으므로 응용 프로그램 전체에 걸쳐 여러 상호 작용하는 엔터티가 있으므로 서비스 계층이 좋았을 것입니다. – theblang

답변

11

DAO는 하나의 특정 엔티티를보다 세부적으로 처리합니다. 서비스는 매크로 수준 기능을 제공하며 둘 이상의 DAO를 사용하여 종료 될 수 있습니다. 일반적으로 서비스는 원 자성을 얻기 위해 트랜잭션 경계를 정의하는 데 사용됩니다. 즉, 여러 DAO를 사용하여 여러 테이블을 업데이트하는 경우 서비스 경계에서 트랜잭션 경계를 정의하면 DB에 수행 된 모든 변경 사항을 커밋하거나 롤백하는 데 도움이됩니다.

디자인에서 주로 다양한 엔터티에 대해 CRUD를 수행하므로 서비스가 많은 가치를 부여하지 않는 것처럼 보일 수 있습니다. 그러나 데이터를 업데이트하는 한 가지 방법으로 웹 기반 프론트 엔드를 생각해보십시오. 서비스를 사용하면 나중에 웹 서비스와 동일한 기능을 제 3 자 통합 업체와 같은 다른 형태의 클라이언트에 노출 할 수 있습니다.

요약하면 디자인은 기존 방식과 일치하는 것으로 보입니다. 코드의 오버 헤드를 줄일 수있는 공통된 주제에 따라 여러 서비스를 하나로 결합 할 수 있다고 생각한다면 먼저 진행해야합니다. 결국, 궁극적 인 목표는 필요가 발생할 때 아무도 변경을 두려워하지 않는 유지 보수 가능한 코드를 만드는 것입니다.

+1

"서비스 사용"당신은 간단한 목록을 반환/crud 수행하거나 편안한 API로 노출 서비스 클래스가 필요하지 않습니다. 상호 작용하는 여러 엔터티를 조작 할 때 serpate 서비스 클래스가 필요합니다. – NimChimpsky

+0

외부 앱도 제공 할 때 서비스를 원할 것입니다. Android 앱용 데이터를 제공하는 웹 서비스가 있다고 가정 해 보겠습니다. 데이터를 가져와 REST 요청을 처리하는 어댑터 계층의 DTO (데이터 전송 객체)를 반환하고 JSON 또는 XML의 DTO를 변형하여 Android 앱에 보낼 서비스 레이어를 만들 수 있습니다. – dgimenes

0

내가 here

길고 그것의 짧은 서비스 레이어를 사용의 장점은 내 대답은 참조하는 것입니다 그것은 당신에게 당신이 봄 보안 및 역할과 아무것도 할 경우 미래의 이동 공간을 제공합니다 트랜잭션을 더 원자 단위로 처리 할 수있게 해주 며, Spring 자체는 트랜잭션을 아주 잘 처리한다.

+0

그러면 컨트롤러에서 DAO 문제를 해결할 수 있습니다. 컨트롤러가 DAO에 많이 연결되어 있다면, 서비스 레이어를 아직 만들지 않았다면 앞으로 더 많은 작업이 필요합니다. – david99world

+0

서비스가 http://en.wikipedia.org/wiki/Separation_of_concerns와 관련된 우려를 제공해야하기 때문입니다. 이 서비스 외관을 무시하고 서비스 레이어를 도입 한 경우 컨트롤러에서 DAO로 직접 이동하는 것은 좋지 않은 습관입니다. 초기에 서비스 레이어가 필요 없으므로 DRY 규칙을 깨뜨릴 수는 있지만, SoC가 향후 리팩터링에 큰 고통이 될 수 있습니다. – david99world

+0

난 그냥 여기에두고 갈거야 http://stackoverflow.com/questions/3688664/simple-spring-app-why-use-service-layer#answer-3688779 그것은 기본적으로 내 추론을 요약하기 때문에 복잡성이 증가 할 수있는 응용 프로그램의 서비스 계층은 좋은 아이디어입니다. – david99world

0

두 개 이상의 aggregate root을 다룰 때 서비스 클래스를 사용하십시오.

리포지토리 (일명 컬렉션을 반환하는 DAO) 또는 DAO를 컨트롤러에 직접 삽입 할 수 있으므로 기본 레이어를 추가 할 레이어/클래스가 필요하지 않습니다.

필요한 경우 서비스 클래스 만 사용하십시오. 그렇지 않으면 필요한 코드의 두 배가됩니다.

리포지토리를 일반화하고 트랜잭션을 시행하는 @Transactional(propagation = Propagation.REQUIRED)으로 annoatoate 할 수 있지만 이미 존재하는 경우 새로운 트랜잭션을 생성하지는 않습니다. 따라서 나중에 하나의 서비스 클래스 메소드에서 다중 리포지토리를 사용하면 하나의 트랜잭션 만 갖게됩니다.JPA2와 컨트롤러 프로 - 봄-3가 선 아래 언급 한 책에서

1

Once the EntityManagerFactory had been properly configured, injecting it into your service layer 
classes is very simple. 

그들은 다음과 같이 서비스 및 저장소와 같은 클래스를 사용하고 있습니다 :

package com.apress.prospring3.ch10.service.jpa; 
// Import statements omitted 
@Service("jpaContactService") 
@Repository 
@Transactional 
public class ContactServiceImpl implements ContactService { 
private Log log = LogFactory.getLog(ContactServiceImpl.class); 
@PersistenceContext 
private EntityManager em; 
// Other code omitted 
} 

봄 데이터 CRUDRepository 또는 JPARepository를 사용하려는 경우 DAO가 Interface가되고 코드를 처리 할 서비스 계층을 만들어야합니다.

관련 문제