Java 웹 애플리케이션에서 패키지 구조를 설정하는 가장 좋은 방법은 무엇입니까?
src, 단위 테스트 코드 등을 어떻게 설정 하시겠습니까?
답변
maven의 표준 프로젝트 레이아웃을 따를 수 있습니다. 실제로 maven을 사용할 필요는 없지만 필요한 경우 향후 전환이 더 쉬워 질 것입니다. 또한 많은 오픈 소스 프로젝트가 이런 방식으로 배치되기 때문에 다른 개발자가 해당 레이아웃을 보는 데 익숙해 질 것입니다.
답변
확인할 수있는 몇 가지 기존 리소스가 있습니다.
그만한 가치에 대해 제가 사용하는 개인적인 지침은 다음과 같습니다.
- 역 도메인 (예 : “com.mycompany”)으로 시작하십시오.
- 제품 이름을 사용하십시오 (예 : “myproduct”). 어떤 경우에는 특정 제품에 속하지 않는 공통 패키지가있는 경향이 있습니다. 이것은 “io”, “util”, “ui”등과 같은 공통 클래스의 기능에 따라 분류됩니다.
- 이 후에는 더 자유 형식이됩니다. 일반적으로 프로젝트, 기능 영역, 배포 등에 따라 그룹화합니다. 예를 들어 “project1”, “project2”, “ui”, “client”등이있을 수 있습니다.
다른 몇 가지 사항 :
- 패키지 이름이 디자인 문서에서 흘러 나오도록 작업 한 프로젝트에서는 매우 일반적입니다. 일반적으로 제품은 이미 기능 또는 목적 영역으로 구분됩니다.
- 일반적인 기능을 더 높은 패키지에 즉시 적용하는 것에 너무 많은 스트레스를주지 마십시오. 프로젝트, 제품 등에서 필요가있을 때까지 기다린 다음 리팩터링하십시오.
- 패키지 간 종속성을 확인하십시오. 모두 나쁘지는 않지만 별도의 장치 사이의 긴밀한 결합을 의미 할 수 있습니다. 이를 추적하는 데 도움이되는 도구가 있습니다.
답변
구현 계층이 아닌 기능별로 패키지 구조를 만드는 것이 좋습니다. 이에 대한 좋은 글은 Java 프랙티스입니다. 레이어가 아닌 기능별 패키지
답변
나는 일반적으로 다음을 좋아합니다.
- bin (바이너리)
- doc (문서)
- inf (정보)
- lib (라이브러리)
- res (자원)
- src (소스)
- tst (테스트)
이것은 틀에 얽매이지 않는 것으로 간주 될 수 있지만, 사물을 정리하는 데 아주 좋은 방법이라고 생각합니다.
답변
The way I usually organise is
- src
- main
- java
- groovy
- resources
- test
- java
- groovy
- lib
- build
- test
- reports
- classes
- doc답변
내가 일반적으로 폴더 계층 구조를 갖는 방식-
- 프로젝트 이름
- src
- 큰 상자
- 테스트
- libs
- 문서
답변
또 다른 방법은 API, 서비스 및 엔터티를 다른 패키지로 분리하는 것입니다.
