"올바른 방법은 무엇입니까?"에 대한 일반적인 대답 또는 "이것이 올바른 방법입니까?" ..... 그것은 달려있다 .
내가 할 수있는 것은 당신에게 특정 아이디어에 대한 장단점을 알려주는 것입니다. 다음은 100 % 내 의견입니다. 특정 요구 사항이나 규칙을 모르겠습니다. 누군가 나에게 동의하지 않을 것입니다.
JSP
JSP를 WEB-INF에 넣을지 여부에 대해 작업 해 봅시다.
WEB-INF에 JSP를 넣는 장점 :
- JSP 실행 방법을 제어합니다. JSP를 매개 변수화하고 재사용 할 수 있기를 원한다면 (어쨌든 JSP로는 어렵습니다) WEB-INF에 넣고 서블릿 또는 Struts 액션 컨트롤러 또는 다른 프론트 컨트롤러를 사용하여 사전 처리를 수행 할 수 있습니다 그런 다음 제어를 JSP에 전달하고 올바른 환경 컨텍스트 (예 : 요청 속성, 보안 검사, 매개 변수 위생 등)를 전달합니다.
- 프로그래밍 방식으로 또는 방화벽 또는 IDS 수준에서 HTTP 요청을 * .jsp로 차단하여 누군가 JSP를 웹 루트에 업로드 한 다음 웹 서버로 코드를 실행할 수있는 가능성을 줄입니다. 기존 JSP를 덮어 써야합니다. 큰 보안 이점은 아니지만 타협을 약간 어렵게 만듭니다.
- MVC, 프론트 컨트롤러, 서블릿 필터, 의존성 주입 등과 같은 좋은 습관을 강요하여 모든 작업 자체를 수행하고 읽기 / 유지하기 어려운 거대한 괴물 JSP와는 대조적입니다.
WEB-INF에 JSP를 배치하는 단점 :
- 선행 처리가 필요없는 단순한 독립형 페이지 인 경우에도 페이지에 직접 액세스 할 수 없습니다. / WEB-INF 아래의 파일은 서블릿 컨테이너에서 제공 할 수 없기 때문입니다.
정적 파일
HTML, 이미지, 스타일 시트, 자바 스크립트 등과 같은 순수 정적 파일의 관점에서 파일을 웹 루트 (귀하의 경우 my_app) 아래에 두지 만 NOT / WEB-INF (액세스 할 수 없기 때문에).
전체 레이아웃
전체 디렉토리 레이아웃은 빌드 프로세스에 따라 다릅니다. 나는 "src"또는 "source"에 모든 것을 저장하는 것을 좋아한다. 왜냐하면 어떤 파일을 빌드하여 어떤 파일이 생성되고 어떤 것이 순수한 소스 파일인지 명확하게하기 때문이다. main
junit 클래스와 같은 테스트 코드를 기본 소스 코드와 분리하면 좋습니다. 그러나 단위 테스트가 없다면 (아뇨!) 무의미한 구별입니다.
반면에 빌드 도중 웹 루트를 전혀 조작하지 않으면 (예 : 모든 JSP 및 정적 파일 인 경우) 웹 루트를 최상위 레벨로 유지 /webroot
하거나 /deploy
필요에 따라 파일을 복사 하거나 복사합니다. .class 또는 .jar 파일. 인간 (특히 개발자)이 과도하게 조직하는 습관입니다. 초과 구성의 좋은 신호는 하나의 하위 폴더 만있는 폴더가 많이 있다는 것입니다.
당신이 보여준 것
maven에서 설정 한 규칙을 따르고 있음을 나타내므로 이미 maven을 사용하는 경우 해당 레이아웃을 사용하십시오. 설명 한 레이아웃에는 아무런 문제가 없습니다.