레이어드 아키텍쳐는 어떤 방식을 권장/선호 하나요?예시있습니다!

Question

전형적인 걸로는1. Controller > Service > ServiceImpl > Dao > DaoImpl(xml 호출) 이러한 방식이 있습니다.이번에 변경을 위하여 몇가지를 생각해보았는데2. Controller > Service > ServiceImpl(mapper 호출 + 비즈니스 로직)3. Controller > Service > ServiceImpl(Dao 호출 + 비즈니스 로직) + Dao(mapper 호출) 이렇게 2개를 생각하고 있습니다 .2번의 경우는 dao역할과 비즈니스 로직이 전부 serviceImpl에 들어가있다보니 gpt도 권장하지 않는 방식이고 저도 마음에 잘 들진 않는데 파일이나 소스의 양이 줄어든다는 장점이 있긴 해보입니다.솔직히 Controller > Service > ServiceImpl > Dao > DaoImpl 처럼 극단적으로 계층을 나누는 것도 생각해보았는데이렇게 극단적인 것보다는 3번이 나아보이긴 합니다.다들 몇 번을 권장하나요? 참고로 개인프로젝트입니다!기존엔 Controller > Service > ServiceImpl > Dao > DaoImpl(sqlSession.~ 호출) 방식을 사용했습니다.안정성을 위하여 mapper 방식으로 변경할 겸 구조도 변경하는 게 나아보여 질문드립니다!한가지더, Dao나 DaoImpl 명칭을 Repository.java, RepositoryImpl.java 로 변경하는 거에 대해선 어떻게 생각하시나요?

짱구올시다 · Answer

저는 Controller(Presentation) -> Service(Application) -> Repository(Domain) -> (implements) -> Dao전 이런 식으로 구현합니다. 아래 예시 코드 참고해보세요!https://github.com/gunkim/kotlin-realworldDao를 추상화한 네이밍으로 Repository(저장소) 이거의 구현체가 Dao(데이터 접근 객체)Repository는 저장한다는 개념만 가지고 가고, 이 데이터를 어디에 어떤 식으로 저장할지에 대한 구체적인 구현은 DAO로 들어갑니다.

초무쿤 · Answer

Service 에 Impl은 필요가 없어용. 옛날 방식(Proxy 문제로..) (Rest)Controller => Service => DAO(Repository|Mapper...)

Xellos Choi · Answer

위의 댓글이 틀린 건 아니지만 조금 위험한 얘기 같아 보여 답변을 하자면 인터페이스(Service)로 구현체(Serviceimpl)를 만드는 건 옛날 방식은 아닙니다.각자 장단점이 있기에 선택에 있어서 트레이드 오프 관계이지 실제로 Spring에서는 CGLib 방식보다 dynamic proxy 을 추천합니다.https://docs.spring.io/spring-framework/reference/core/aop/introduction-proxies.html잘 쓴 글은 아니지만 AOP 관련해서는 얼마 전 글을 쓴 게 있어서 첨부합니다.https://crazy-code.tistory.com/6어느 쪽으로 구현하든 그렇게 구현했을 때의 장점과 그 이유를 명확하게 알고 있으면 상황에 맞게 대처가 가능합니다. "파일이나 소스의 양이 줄어든다는 장점이 있긴 해 보입니다." 이런 형태의 접근이 더 좋아 보입니다.레이어드 아키텍처가 왜 나오게 된 건지 이유 좀 더 찾아보시면 위에서 고민하는 부분들에 대한 의문의 해소가 좀 더 되실꺼고 그 이유에 맞게 설계하는 방법을 고민하다보면 헥사고날 이나 DDD 와 같은 형태의 아키텍처 등장배경이 이해 되실껍니다.최근에 읽은 글 중에 참고 하실만한게 있어서 같이 공유 드립니다.https://kdh0518.tistory.com/61

레이어드 아키텍쳐는 어떤 방식을 권장/선호 하나요?예시있습니다!

3개의 답변

Q&A 목록