안녕하세요. 궁금한게 있어서 여쭤보고 싶은데 Issue를 통해서 문의 드리는게 맞을까 싶네요 ^^;;

[godngu]

친절하면서 멋지게 작성된 소스 내용을 보던 중 의도가 너무 궁금해서 이렇게 문의 드립니다.
만약 불쾌함을 드렸다면 정말 사과 드립니다.

질문1. MemberFindDao에서 @repository가 아닌 @service를 사용하신 이유가 뭘까요?

질문2. MemberFindDao에 있는 두 개의 findBy* 메소드는�MemberRepository에서 제공이 가능 한데도 불구하고 DAO 클래스를 선언하신 이유는 뭔가요? (추측하기로 리턴값이 Optional.empty인 경우 적절한 exception 사용을 위한게 아닐까 생각했습니다.)

질문3. 만약 [질문2]에 대한 저의 추측이 맞다면, 비슷한 기능(?)을 하는 findById, findByEmail의 메소드는 두 군데(Dao, Repository)에 존재 하게 될테고 메소드가 사용되는 관점에서 봤을때 같은 혹은 비슷한 기능의 메소드가 중복으로 존재하는게 될텐데 의도하신 건가요?
(물론 리턴값(Optional, Member)이나 리턴되는 exception은 차이가 있지만 비즈니스는 유사해 보입니다.)

여기까지 읽어 주신것 만으로도 감사 드립니다 ^^
(후에 더 여쭤보고 싶은데 이메일이라도 알려주시면 감사하겠습니다 [email protected])

[cheese10yun]

@godngu

질문1. MemberFindDao에서 @repository가 아닌 @service를 사용하신 이유가 뭘까요?

@Repositroy, @Service 같은 어노테이션은 말 그대로 주석같은 의미로 특별한 의미는 없습니다. 물론 @Repositroy 으로 지정해서 Slice Test를 가능하게 할 수도 있겠지만 그런 의도는 아니였습니다.

@Service를 한 이유는 스프링 Bean으로 등록 시키는 어노테이션중에 비지니스 로직이 들어가는 Bean들에게 @service를 사용하기 때문에 사용했습니다.

질문2. MemberFindDao에 있는 두 개의 findBy* 메소드는�MemberRepository에서 제공이 가능 한데도 불구하고 DAO 클래스를 선언하신 이유는 뭔가요?

저는 Repositroy 패턴을 사용시 외부 객체에서 Repositroy에 대한 직접적인 접근을 하지 않아야 한다고 생각합니다. 특히 JPA를 사용중에 Repositroy는 해당 엔티티의 모든 변경을 데이터베이스에 조작할 수 있기 때문에 Repositroy는 서비스(우리 비지니스를 반영하는 코드)를 통해서 외부 객체에 서비스 해야한다고 생각합니다. 그러기 때문에 DAO 라는 서비스를 통해서 외부 객체에 서비스를 제공하고 있기에 그러한 구조가 된것입니다. 우리 비지니스를 반경하는 것중에 적절한 exception을 사용하는 것도 일부입니다.

질문은 이슈를 통해서 올려주시면 좋을거 같아요. 다른 분들도 볼 수 있고, 제가 틀린 부분이나 다른 분들의 생각들도 이슈를 통해서 이야기 할 수 있을거 같아서요

[godngu]

@cheese10yun 답변으로 인해 제 궁금증이 모두 해소되었습니다.
감사합니다 ^^