프로젝트에서 DAO 디자인 패턴을 구현하려고하는데, 이것이 데이터베이스와 통신하는 데 가장 일반적으로 사용된다는 것을 알고 있습니다.HTTP와 데이터베이스 모두를위한 DAO 패턴
하지만 일반적으로 인터페이스와 구현이 있기 때문에 HTTP가 사용될 수 있다고 생각하는 데 도움이되지 않습니다. 즉, 데이터베이스에 대한 CRUD를위한 DAO 구현과 CRUD API에 액세스하기위한 다른 DAO 구현이 있습니다. 그러나이 기능도 이와 같이 사용되면 API에 대한 삭제 권한이없는 문제를 해결하는 일반적인 방법은 무엇입니까?
맞습니까? 아니면이 인터페이스를 사용해야하는 이유가 무엇입니까? 아니면 데이터베이스 구현을 쉽게 변경할 수 있도록 허용하는 것입니까?
DAO 패턴은 일반적으로 다양한 형태의 데이터 표현을 분리하는 데 사용됩니다. 예를 들어 데이터베이스 스키마를 Java 응용 프로그램 논리와 분리 할 수 있습니다. 인터페이스 (당신이 논의하고 있다고 생각하는 의미에서)는 전형적으로 Java 로직의 구현을 구현과 분리하는 데 사용됩니다. 이러한 두 가지 형태의 디커플링은 완전히 다르며, 디자인을보다 유지 보수적이고 표현력있게 만드는 경우 두 가지를 함께 사용하지 않아도됩니다. 비록 Java 코드가 일반적인 용도로 사용 되더라도 (예를 들어 재사용 가능한 라이브러리에서),이 시점에 대해서는 다른 견해가 있지만 인터페이스로 동작을 지정하는 것은 필수적이라고 생각하지 않습니다.
특정 질문과 관련하여 데이터에서 작동하는 Java 메소드가 있고 이러한 조작이 실패 할 수 있다면 일반적으로 예외가 발생합니다. DAO를 사용하고 있고 자바 로직의 일부가 데이터 스토리지 구현과 매우 분리되어있는 경우 해당 로직은 "액세스 거부"를 의미있는 개념으로 인식하지 못할 수도 있습니다. 그런 경우 예외도 분리해야하고 DAO 로직이 일반적인 "업데이트 실패"예외를 던져야합니다. 이 예외는 특정 스토리지 구현에서 호출자까지 제공된 원래 예외 ("액세스가 거부 됨")를 전달할 수 있습니다. 액세스가 거부 될 수도 있고 그렇지 않을 수도 있습니다. 광범위한 디커플링의 위험 요소 중 하나는 오류의 원인으로부터 멀어 질수록 오류 처리가 점점 더 구체화되지 않는다는 것입니다.