일반 DAO - "절대 사용하지 마십시오!"

Question

필자는 인터넷을 통해 일반적인 dao의 사용법을 보았습니다.

public interface GenericDao <T, PK extends Serializable> {} 

public class GenericDaoHibernateImpl <T, PK extends Serializable> 
implements GenericDao<T, PK> 

새로운 클래스

가 나타나 당신은 꼭 사랑? 문제 없음 :

public interface NewClassDao extends GenericDao<NewClass, Long> 

모든 설정이 완료되었습니다. 내가 가서 "전체 일반 '과 같은 것을 할 경우

지금, 그것을 어떻게 나쁜 : (! 주조와 객체의) 지금은 하나의 DAO를 사용할 수 있습니다

public interface FullGenericDao 

public class FullGenericDaoHibernateImpl 

을

새로운 수업이 다시 등장 했나요? 문제 :

NewClassApperedAgain newClassAppeared = (NewClassApperedAgain) FullGenericDao.getItemById(20, NewClassApperedAgain.class); 

두 가지 질문이 마음에 온다 :

1)은 "전체 제네릭"가서 실제로 이러한 DAO를 만들 수도 있습니까? 나는 왜 dao의 모든 메소드를 className에 전달하지 않고 그냥 주조해야하는지 알지 못한다는 것을 의미합니까? save (object, className); 삭제 (object, className);

2) 그런 연습의 단점은 무엇입니까?

감사합니다.

Answer 1

DAO 개체에는 지속성 계층과 연결된 도메인 모델 관련 논리가 들어 있습니다.

당신은 전체 일반 갈 수 있지만, 당신은 같은 질문에 직면해야 : I (예를 들어 WHERE 절을 건설) 검색과 연결 논리를 넣어해야

• 를?
  • User findUserByOrganizationId(Serializable organizationId)
• 는 어디에서 일부 특정 매핑 기능 (예를 들어, 집계 쿼리)를 배치해야합니까?

• Map<Organization, Integer> findUserCountPerOrganization()
나는 다른 논리/건축 문제가 꽤 확신합니다. 또한 제네릭은 런타임 중에 지워질 것이므로 모든 메소드 서명에 도메인 객체 Class<?>을 포함시킬 필요성을 소개했습니다.

TL : DR "완전 일반"으로 설정할 수 있지만 비공유 지속성 논리를 상위 수준으로 이동해야합니다. 일부 AbstractDaoImpl에서 공유 일반 로직을 수행 한 다음 서브 클래스를 작성하는 것이 좋습니다. 비어있는 구현으로 끝날 수도 있지만 (일반 수퍼 클래스에는 필요한 모든 것이있을 수 있습니다), 향후 도메인 모델 특정 메소드를위한 장소를 갖게 될 것입니다.