패키지 구조, 클래스 명명 및 서비스 다중 구현 등의 적용 점검 허용 범위 문의
- 작성자 :
- 문*자
- 작성일 :
- 2024-05-13 22:14:39
- 조회수 :
- 427
- 구분 :
- 적용지원(적용점검)
- 진행상태 :
- 완료
Q
https://www.egovframe.go.kr/home/sub.do?menuNo=67
링크에 있는 가이드 PDF 파일 및 개발 환경 4.2 기준 스프링 부트 템플릿 프로젝트를 살펴보다 궁금증이 생겨 문의 드립니다.
1. 패키지 구조를 '4.2 개발환경 기준 스프링 부트 템플릿 프로젝트'와 동일하게 하여야 하는지 궁금합니다.
- 샘플 프로젝트를 살펴보면 패키지 구조가 다음과 같은 것으로 보입니다.
├─service: VO, Service interface
│ └─impl: EgovAbstractServiceImpl 확장 및 Service 구현 클래스, EgovAbstractMapper 확장 클래스
└─web: 컨트롤러 클래스
- 위와 같은 패키지 구조 및 클래스 위치가 제한되는 것인지 아니면 아래 예시와 같은 구조로 패키지를 구상하여도 무관한지 궁금합니다.
├─application : VO, Service interface
│ └─impl: EgovAbstractServiceImpl 확장 및 Service 구현 클래스
└─presentation: 컨트롤러 클래스
│ └─request: 요청(post)에 대한 DTO 클래스
└─persistence: EgovAbstractMapper 확장 클래스, Entity 클래스 (*JPA 적용시)
2. ~Service 라는 명명을 ~Usecase 와 같이 변경하여 클래스를 명명하여도 괜찮은지 궁금합니다.
- 예제상 명명:
- - <interface>SampleService
- - SampleServiceImpl
- 문의한 내용의 명명:
- - <interface>SampleUsecase
- - SampleUsecaseImpl 혹은 SampleService
3. 여러 interface를 다중 구현 하는 서비스 구현체가 허용되는지 궁금합니다.
- 예시
- - <interface>SampleGenerateService
- - <interface>SampleFindService
- - SampleServiceImpl 에서 위 인터페이스를 다중 구현
링크에 있는 가이드 PDF 파일 및 개발 환경 4.2 기준 스프링 부트 템플릿 프로젝트를 살펴보다 궁금증이 생겨 문의 드립니다.
1. 패키지 구조를 '4.2 개발환경 기준 스프링 부트 템플릿 프로젝트'와 동일하게 하여야 하는지 궁금합니다.
- 샘플 프로젝트를 살펴보면 패키지 구조가 다음과 같은 것으로 보입니다.
├─service: VO, Service interface
│ └─impl: EgovAbstractServiceImpl 확장 및 Service 구현 클래스, EgovAbstractMapper 확장 클래스
└─web: 컨트롤러 클래스
- 위와 같은 패키지 구조 및 클래스 위치가 제한되는 것인지 아니면 아래 예시와 같은 구조로 패키지를 구상하여도 무관한지 궁금합니다.
├─application : VO, Service interface
│ └─impl: EgovAbstractServiceImpl 확장 및 Service 구현 클래스
└─presentation: 컨트롤러 클래스
│ └─request: 요청(post)에 대한 DTO 클래스
└─persistence: EgovAbstractMapper 확장 클래스, Entity 클래스 (*JPA 적용시)
2. ~Service 라는 명명을 ~Usecase 와 같이 변경하여 클래스를 명명하여도 괜찮은지 궁금합니다.
- 예제상 명명:
- - <interface>SampleService
- - SampleServiceImpl
- 문의한 내용의 명명:
- - <interface>SampleUsecase
- - SampleUsecaseImpl 혹은 SampleService
3. 여러 interface를 다중 구현 하는 서비스 구현체가 허용되는지 궁금합니다.
- 예시
- - <interface>SampleGenerateService
- - <interface>SampleFindService
- - SampleServiceImpl 에서 위 인터페이스를 다중 구현
환경정보
-
- OS 정보 :
- 표준프레임워크 버전 :
- JDK(JRE) 정보 :
- WAS 정보 :
- DB 정보 :
- 기타 환경 정보 :
A
안녕하세요.
프레임워크센터입니다.
1, 2. 표준프레임워크 적용 시 아키텍쳐 부분은
[Annotation 기반의 Spring MVC 및 Layered architecture 준수] 규칙을 준수해야 합니다.
따라서, Presentation Layer, Business Layer, Data Access Layer 로 나눠져야 하며
각 레이어의 클래스는 @Controller, @Service, @Repository를 선언해서 구분해야 합니다.
또한, 가이드에서 [Hibernate/JPA 혹은 Spring Data JPA 방식의 경우, 정해진 규칙 없음] 로
안내하고 있으므로 이런 경우는 각각의 환경에 맞게 구성하실 수 있습니다.
3. 서비스 클래스로 사용되는 클래스들이 표준프레임워크 실행환경의 AbstractServiceImpl을 확장하여야 한다는 규칙과,
클래스간 결합도를 낮추기 위하여 서비스 클래스들은 특정한 인터페이스를 선언하고
해당 인터페이스를 확장하여야 한다는 규칙이 있으므로
이에 맞게 구성하시기 바랍니다.
그리고, AbstractServiceImpl의 활용이 프로젝트에 부적합한 경우, 해당 클래스를 상속받은
공통 추상 서비스 클래스를 작성하여 해당 클래스를 상속받는 형태로 활용할 수 있으니
참고하시기 바랍니다.
감사합니다.
프레임워크센터입니다.
1, 2. 표준프레임워크 적용 시 아키텍쳐 부분은
[Annotation 기반의 Spring MVC 및 Layered architecture 준수] 규칙을 준수해야 합니다.
따라서, Presentation Layer, Business Layer, Data Access Layer 로 나눠져야 하며
각 레이어의 클래스는 @Controller, @Service, @Repository를 선언해서 구분해야 합니다.
또한, 가이드에서 [Hibernate/JPA 혹은 Spring Data JPA 방식의 경우, 정해진 규칙 없음] 로
안내하고 있으므로 이런 경우는 각각의 환경에 맞게 구성하실 수 있습니다.
3. 서비스 클래스로 사용되는 클래스들이 표준프레임워크 실행환경의 AbstractServiceImpl을 확장하여야 한다는 규칙과,
클래스간 결합도를 낮추기 위하여 서비스 클래스들은 특정한 인터페이스를 선언하고
해당 인터페이스를 확장하여야 한다는 규칙이 있으므로
이에 맞게 구성하시기 바랍니다.
그리고, AbstractServiceImpl의 활용이 프로젝트에 부적합한 경우, 해당 클래스를 상속받은
공통 추상 서비스 클래스를 작성하여 해당 클래스를 상속받는 형태로 활용할 수 있으니
참고하시기 바랍니다.
감사합니다.
