DAO 및 서비스 계층(JPA/하이버네이트 + 스프링)

DAO 및 서비스 계층(JPA/하이버네이트 + 스프링)

이 질문에는 이미 다음과 같은 답이 있습니다.

Java EE 아키텍처 - JPA 2와 같은 ORM을 사용할 때 DAO가 여전히 권장됩니까? (2개 답변)

마감됨6년 전에.

저는 JPA/Hibernate, Spring, Wicket 기반의 새로운 앱을 설계하고 있습니다.DAO 계층과 서비스 계층의 차이는 명확하지 않습니다.위키백과에 따르면 DAO는

데이터베이스의 세부 정보를 노출하지 않고 특정 작업을 제공하는 데이터베이스 유형 또는 지속성 메커니즘에 대한 추상적 인터페이스를 제공하는 개체입니다.

DAO에 데이터 액세스와 별로 관련이 없는 방법이 포함될 수 있는지 궁금했는데, 쿼리를 사용하여 실행하는 것이 훨씬 더 쉽습니까?예를 들어, "특정 공항 집합에서 운항하는 모든 항공사의 목록을 얻으십시오"?서비스 계층 방식에 가깝다고 생각합니다만, JPA Entity Manager를 서비스 계층에서 사용하는 것이 모범 사례인지 잘 모르겠습니다.

DAO는 관련된 단일 데이터 소스에 대한 액세스를 제공해야 하며, 비즈니스 모델이 얼마나 복잡한지에 따라 완전한 비즈니스 개체 또는 단순한 데이터 개체를 반환합니다.어느 쪽이든 DAO 방법은 데이터베이스를 다소 가깝게 반영해야 합니다.

서비스는 비즈니스 객체를 처리할 뿐만 아니라 처음부터 객체에 액세스할 수 있는 보다 높은 수준의 인터페이스를 제공할 수 있습니다.서비스에서 비즈니스 개체를 가져오는 경우 해당 개체는 다른 데이터베이스(및 다른 DAO)에서 생성될 수 있으며 HTTP 요청에서 생성된 정보로 장식될 수 있습니다.여러 데이터 개체를 하나의 강력한 비즈니스 개체로 변환하는 특정 비즈니스 논리가 있을 수 있습니다.

저는 일반적으로 DAO를 작성합니다. DAO는 해당 데이터베이스나 비즈니스 관련 데이터 세트를 사용할 사람이라면 누구나 사용할 수 있다고 생각합니다. DAO는 데이터베이스 내에서 트리거, 기능 및 저장 프로시저 외에 문자 그대로 가장 낮은 수준의 코드입니다.

특정 질문에 대한 답변:

DAO에 데이터 액세스와 별로 관련이 없는 방법이 포함될 수 있는지 궁금했는데, 쿼리를 사용하여 실행하는 것이 훨씬 더 쉽습니까?

대부분의 경우 아니요, 서비스 계층에서 더 복잡한 비즈니스 로직, 즉 별도의 쿼리에서 데이터를 조합하는 것이 좋습니다.그러나 처리 속도가 걱정되는 경우 C++ 프로그래머가 특정 작업 속도를 높이기 위해 어셈블러 코드를 작성하는 것과 마찬가지로 서비스 계층이 모델의 미관을 깨뜨리더라도 DAO에 작업을 위임할 수 있습니다.

서비스 계층 방식에 가깝다고 생각합니다만, JPA Entity Manager를 서비스 계층에서 사용하는 것이 모범 사례인지 잘 모르겠습니다.

서비스에서 엔터티 관리자를 사용하려면 엔터티 관리자를 DAO로 생각해야 합니다. 바로 이와 같기 때문입니다.중복 쿼리 빌딩을 제거해야 하는 경우 서비스 클래스에서 제거하지 말고 엔티티 관리자를 사용하는 클래스로 추출하여 DAO로 만듭니다. 계층을 관리자 할 수 있습니다. 작업은 을 에 하는 것이기 입니다. 서비스가 수행하는 모든 작업은 호출을 전달하는 것이기 때문입니다.getAirplaneById()에.findAirplaneById()

업데이트 - 아래 논의와 관련하여 명확하게 설명하자면, 의견에 강조된 다양한 이유로 DAO 계층이 존재하는 대부분의 상황에서 서비스에서 엔티티 관리자를 사용하는 것은 최선의 결정이 아닙니다.하지만 제 생각에는 다음과 같은 점을 고려할 때 완벽하게 합리적일 것입니다.

1. 서비스는 서로 다른 데이터 집합과 상호 작용해야 합니다.
2. 하나 이상의 데이터 집합에 이미 DAO가 있습니다.
3. 서비스 클래스는 자체 DAO를 보장하지 않을 정도로 간단한 지속성이 필요한 모듈에 상주합니다.

예.

//some system that contains all our customers information
class PersonDao {
   findPersonBySSN( long ssn )
}

//some other system where we store pets
class PetDao {
   findPetsByAreaCode()
   findCatByFullName()
}

//some web portal your building has this service
class OurPortalPetLostAndFoundService {

   notifyOfLocalLostPets( Person p ) {
      Location l = ourPortalEntityManager.findSingle( PortalUser.class, p.getSSN() )
        .getOptions().getLocation();
      ... use other DAO's to get contact information and pets...
   }
}

한 가지 확실한 것은 서비스 계층에서 EntityManager를 사용하는 경우 dao 계층이 필요하지 않다는 것입니다. 단 한 계층만 구현 세부 정보를 알아야 합니다.그 외에도 다음과 같은 다양한 의견이 있습니다.

• 일부에서는 EntityManager가 필요한 모든 dao 기능을 제공하여 서비스 계층에 EntityManager를 주입한다고 말합니다.
• 인터페이스를 통해 지원되는 기존의 dao 계층이 있는 경우도 있습니다(따라서 서비스 계층은 구현 세부 정보와 관련이 없음).

두 번째 접근 방식은 우려 사항을 분리할 때 더 우아하고 지속성 기술을 다른 지속성 기술로 쉽게 전환할 수 있습니다(새로운 기술로 dao 인터페이스를 다시 구현해야 함). 하지만 아무것도 변하지 않을 것이라는 것을 안다면 첫 번째 접근 방식이 더 쉽습니다.

소규모 프로젝트의 경우 서비스 계층에서는 JPA를 사용하지만 대규모 프로젝트에서는 전용 DAO 계층을 사용합니다.

Adam Bien의 이 기사는 유용할 것입니다.

기존에는 서비스 계층과 데이터 계층 간의 계약을 정의하는 인터페이스를 작성했습니다.그런 다음 구현을 작성합니다. 이것이 DAO입니다.

당신의 예로 돌아가세요.공항과 항공사 간의 관계가 공항_id와 항공사_id가 포함된 표와 많은 표 사이에 있다고 가정하면 인터페이스가 있을 수 있습니다.

public interface AirportDAO
{
   public List<Airline> getAirlinesOperatingFrom(Set<Airport> airports);
}

..이에 대한 Hibernate 구현을 제공할 수 있습니다.

public class HibernateAirportDAO implements AirportDAO
{
   public List<Airline> getAirlinesOperatingFrom(Set<Airport> airports)
   {
      //implementation here using EntityManager.
   }
}

또한 항공사 엔티티에 목록을 작성하고 @ManyToMany JPA 주석을 사용하여 관계를 정의할 수도 있습니다.이렇게 하면 이 특정 DAO 방법을 함께 사용할 필요가 없어집니다.

DAO 공장을 작성하기 위한 추상 팩토리 패턴도 확인해 볼 수 있습니다.예를 들어,

public abstract class DAOFactory
{
   private static HibernateDAOFactory hdf = new HibernateDAOFactory();

   public abstract AirportDAO getAirlineDAO();

   public static DAOFactory getFactory()
   {
      //return a concrete implementation here, which implementation you
      //return might depend on some application configuration settings.
   }
}

public class HibernateDAOFactory extends DAOFactory
{
   private static EntityManagerFactory emFactory = Persistence.createEntityManagerFactory("myPersistenceUnit");

   public static EntityManager getEM()
   {
      return emFactory.createEntityManager();
   }

   public AirportDAO getAirportDAO()
   {
      return new HibernateAirportDAO();
   }
}

이 패턴은 최대 절전 모드 DA를 허용합니다.단일 EMF를 보유하고 개별 DAO 인스턴스를 EM과 함께 공급하는 공장. 운명의 길을 가기 싫다면 의존성 주입으로 DAO 인스턴스를 처리하는 데 탁월합니다.

편집: 몇 가지 가정을 명확히 했습니다.

Dao는 데이터 액세스 개체입니다.데이터베이스에 엔터티를 저장/업데이트/선택합니다.엔티티 관리자 개체가 이에 사용됩니다(최소한 열린 jpa에서).이 엔티티 관리자를 사용하여 쿼리를 실행할 수도 있습니다.sql이 아니라 jpQL(Java persistence query language)입니다.

간단한 예:

emf = Persistence.createEntityManagerFactory("localDB");
em = emf.createEntityManager();

Query q = em.createQuery("select u from Users as u where u.username = :username", Users.class);
q.setParameter("username", username);

List<Users> results = q.getResultList();

em.close();
emf.close();

언급URL : https://stackoverflow.com/questions/3882108/dao-and-service-layers-jpa-hibernate-spring