Model1
- 뷰와 로직을 JSP페이지로 처리하는 구조로 구조가 단순하다.
단점
1) JSP안에서 html, css, javascript, java코드가 다 있어서 개발자들이 쓰기엔 좋으나 디자이너들에게는 접근성이 좋지 않다.
2) JSP안에서 html, css, javascript, java코드가 다 있어서 분업이 어렵다.
3) 보안에 문제가 있다 (DB연결을 직접적으로 할 경우 노출 가능성이 높음)
Model2(MVC)
- MVC (Model - View - Controller)
Model : database관리 / View : 사용자가 보는 화면 / Controller : View와 model관리
- request요청을 받음 -> front controller : 요청을 받는 주체
서버로 들어오는 모든 요청을 처리하는 컨트롤러 서블릿으로 구성되어 있고 model에 있는 DB정보를 다 받아서
ViewPage와 연결해서 set을 만들어서 방출코드가 간단하다.
- 뷰와 로직처리 분업이 가능하다.
단점
- 구조가 복잡하고 습득하기 어려우며 작업량이 많다.
Spring MVC
Spring Framework가 제공하는 class(3)
1) DispatcherServlet
- Spring Framework가 제공하는 Servlet클래스
- front controller : 서버로 들어오는 모든 요청을 처리하는 컨트롤러
- 받은 요청은 HandlerMapping으로 전달된다.
2) HandlerMapping
- 사용자의 요청 URL을 맵핑할 컨트롤러를 찾는다.
- 요청 URL에 해당하는 Controller정보를 저장하는 table를 가진다
(즉, 클래스에 @RequestMapping("/url") annotation을 명시하면 해당 URL에 대한 요청이 들어왔을 때 table에 저장된 정보에 따라 해당 클래스 또는 메서드에 mapping한다.)
3) ViewResolver
- 컨트롤러가 반환한 View Name(the logical names)에 prefix,suffix를 적용하여 View Object(the physical view files)를 반환한다.
(예를 들어 view name : home , prefix : /WEB-INF/views/ , suffix : .jsp는 "/WEB-INf/views/home.jsp"라는 위치의 View(JSP)에 Controller에게 받은 Model을 전달한다. 이 후 해당 View에서 이 model data를 이용해 적절한 페이지를 만들어 사용자에게 보여준다.)
POJO (Plain Old Java Object)
- 오래된 방식의 단순 자바 객체 (클래스나 인터페이스 등에 종속되지 않는 일반적인 java객체)
- pojo의 조건
1) 특정 규약에 종속되지 않는다.
2) 특정 환경에 종속되지 않는다.
3) 단일 책임 원칙을 지키는 클래스
=> 책임과 역할이 각기 다른 코드를 하나의 클래스에 넣는 경우 진정한 POJO라고 할 수 없다.
즉, POJO는 객체지향적인 원리에 충실하면서, 특정 환경과 규약에 종속되지 않아 필요에 따라
재사용될 수 있는 방식으로 설계된 오브젝트
- Spring에서의 POJO
스프링 프레임워크는 IoC컨테이너 안에서 POJO를 구성 및 관리하는 것이 가장 핵심으로 POJO를 매우 잘 다루는 프레임워크가 스프링 프레임워크이다.
[참조]
https://hatreasuree.tistory.com/10
'차근차근 > Spring' 카테고리의 다른 글
2.용어정리(4)-ViewResolver,prefix,suffix (0) | 2021.12.09 |
---|---|
2.용어정리(3)-AOP (0) | 2021.12.08 |
1.스프링의 구조 (0) | 2021.12.08 |
mybatis-spring SqlSessionTemplate Public Methods (0) | 2021.12.07 |
ibatis (0) | 2021.12.06 |