Spring
메서드 오버로딩을 통한 요청 줄이기
요청 URL 예시: mypage.do, my.do, mypagePage.do
GET 요청: 페이지 이동
POST 요청: 마이페이지 내용 업데이트
@RequestMapping(value="/insertBoard.do", method=RequestMethod.GET)
public String insertBoard() {
return "insertBoard";
}
@RequestMapping(value="/insertBoard.do", method=RequestMethod.POST)
public String insertBoard(BoardDTO boardDTO) {
boolean flag=boardService.insert(boardDTO);
System.out.println("insertBoard ["+flag+"]");
return "redirect:main.do";
}
GET - 페이지 이동
POST - 글작성
GET 요청의 보안
GET 요청은 보안상 취약하기 때문에, 일반적으로 페이지 이동에 사용
ModelAndView vs String
String 사용의 장점:
ModelAndView보다 String을 경량화 할 수 있음 == 성능 개선
페이지 이동 방식
리다이렉트가 없는 경우
VR(ViewResolver)이 개입하며, 포워드가 기본으로 사용됨
데이터 전송이 가능하며, V(View)로 이동
리다이렉트가 있는 경우
VR(ViewResolver) 이 개입하지 않고, 리다이렉트 방식임
데이터 전송이 불가능하며, C(Controller)로 이동
데이터 전달
JSP가 컴파일되면 자바 파일로 변환되어 JVM 메모리에 올라감
커맨드 객체를 사용할 수 있지만, 주로 model을 사용
성능 개선
성능을 개선하는 과정에서 중요한 부분은 결합도를 낮추고 코드의 유연성을 높이는 것
@RequestMapping(value="/mypage.do")
public String mypage(HttpSession session, MemberDAO memberDAO, MemberDTO memberDTO, Model model) {
위 처럼 메서드 인자가 많아지면 결합도가 높아짐 == 성능이 좋지 않음
메서드가 특정 DAO에 종속됐을 때
데이터베이스 시스템(DBMS)이 변경될 경우 해당 메서드뿐만 아니라
이 DAO를 사용하는 모든 코드에서 수정을 해야 함
- MySQL BoardDAO
- Oracle BoardOracleDAO
- MariaDB BoardMariaDAO
예를 들어, MySQL에서 Oracle로 DBMS를 이관할 때 다음과 같은 다양한 DAO가 필요해짐
매번 DAO를 매개변수로 전달하면 이관 작업이 번거롭고, 코드 변경이 잦아져 유지보수가 어려워
DAO를 멤버 변수로
DAO를 메서드의 매개변수로 사용하는 대신, 클래스의 멤버 변수로 선언하는 방식으로 변경
- 코드 가독성 향상: DAO가 클래스의 멤버 변수로 존재하므로,
해당 클래스 내에서 DAO를 반복적으로 선언할 필요가 없음
하지만 DAO를 멤버 변수로 설정하더라도, DBMS 이관 시 여전히 변경이 필요함
컴파일 시점에서 코드 변경이 필요하므로 결합도가 완전히 낮아지지는 않음
Service를 멤버 변수로
결합도를 더욱 낮추기 위해 Service 레이어를 추가하는 방법이 더 효과적임
Service를 멤버 변수로 설정: DAO를 포함한 Service 객체를 클래스의 멤버 변수로 두면,
직접적으로 DAO에 의존하지 않고, 서비스 레이어를 통해 데이터베이스와 상호작용하게 됨
@Controller
public class BoardController {
@Autowired
private BoardService boardService;
이관 작업의 용이함: 데이터베이스 이관 시 Controller나 Service 클래스에서 DAO 변경 사항 최소화
만약 DBMS를 변경하더라도, Service 클래스만 수정하면 되므로 전체적인 코드 변경이 줄어듬
그렇기 때문에
DAO와 service는 메서드 시그니처를 꼭 맞춰야됨
[ 2-Layered 아키텍처]
컨트롤러에 멤버 변수로 서비스 객체를 만든다는 것은
서비스 레이어를 끼워 넣는다는 뜻인데
2-Layered 아키텍처라는 걸 대체로 씀
2-Layered는 new 순서를 컨트롤 하기 위해 고안된 아키텍처(구조)
1) Service 레이어를 추가했으니
2) @Service == new Service 를 먼저 해주면 어떨까?
3) 또 다른 스프링 컨테이너(== 루트 컨테이너)를 추가
web.xml 서블릿 컨테이너(== 톰캣)
ds-servlet.xml 스프링 컨테이너
applicationContext.xml 스프링 컨테이너(== 루트 컨테이너)
4) /WEB-INF/applicationContext.xml 를 참고하여 돌아가는
루트 컨테이너
1 - WEB-INF 하위에 xml 파일을 생성
2 - applicatoinContext.xml 이 저장된 위치를 알려주기 ◀
웬만하면 2번을 씀
경로 - classpath:applicationContext.xml
classpath는 src/main/resource
컨테이너가 인지를 하고 있어야 service 객체를 생성할 수 있기때문에
톰캣이 시작되는 것을 감지하는 리스너를 이용해
먼저 service 객체를 생성
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:applicationContext.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
분리
'javaboiii의 Spring' 카테고리의 다른 글
Spring - AOP 관점 지향 프로그래밍 (1) | 2024.10.15 |
---|---|
Spring - 비동기 처리 (0) | 2024.10.14 |
Spring - ViewResolver와 요청 처리 흐름 (feat.@controller) (0) | 2024.10.08 |
Spring - SpringFramework구조의 흐름 (1) | 2024.10.07 |
Spring - 개념 복습 / 어노테이션 (0) | 2024.10.04 |