summary
https://www.notion.so/Spring-1-b5980823f7644e5e88fd2c71dfea2319
1-8 Controller의 역할
-
Servlet : 자바를 사용하여 웹페이지를 동적으로 생성하는 서버측 프로그램 혹은 그 사양
-
Servlet VS Controller
클라이언트 서버
Javascript <--- JSON ---> JAVA -
Servlet 대신 Controller를 사용하면 JSON<-->JAVA 측면에서 훨씬 더 효율적이다
1-9 AllInOneController의 문제점
- 절차 지향 프로그램 : 코드가 길어지면 관리하기 불편하다
1-10 객체지향 프로그래밍
-
Controller : 클라이언트로 부터 요청을 받고 요청에 대한 처리는 서비스에게 전달해서 서비스로부터 결과가 돌아오면 그 결과를 클라이언트에게 전송
-
Service : 비지니스 로직 처리 (서버에서 사용자의 요구사항 처리) 실제 사용자의 요구사항이 여기서 처리
-
Repository : DB관리 역할, 연결, 해제, 자원 관리까지, DB의 CRUD작업 처리
전체적 흐름
Client가 요청이 들어오면 Controller에게 가고, Controller는 그 요청을 Service에게 보내주고, Service는 비지니스 로직을 처리하고 처리하다가 DB의 정보가 필요하면 repository에 전담하고, Repository는 DB에 필요한 정보를 조회,저장,업데이트,삭제 하는 역할하고 그 결과를 service에게 전달. Service는 필요한 비지니스 로직을 다 마무리 지으면 결과를 Controller에게 보내주고, Controller가 그 결과를 Client에게 보내줌.
1-12 관심사 별 코드 분리해보기
updateProduct를 하나의 controller에서만 호출하는 건 아니기 때문에 productservice에 최저가 설정을 해준다.
1-13 코드 좀 더 개선하기
1-14 DI(의존성 주입)의 이해
- 중복 : 프로젝트가 진행되면서 productService는 계속 늘어남. Service가 생성될 때마다 Repository를 함께 생성해야함
- 강한 결합 : ProductRepository클래스 생성자가 변경되면 ProductRepository를 생성하는 ProductService클래스 코드도 변경되어야 함.
- 모든 Controller는 Repository를 생성하기 위해 모두 다 id,pw를 알아야 함
1-15 DI(의존성 주입) 사용하기
- 각 객체는 1개만 필요하니까 객체 생성은 1번만 하고, 생성된 객체가 필요할 때 가져다 사용
- DB의 id,pw를 가지고 생성하는 것이 아니라, 미리 생성되어 있는 클래스(productService)를 가져와서 생성자에서 멤버 변수에 설정
--> ProductRepository 생성자에 변화가 생겨도, ProductService, ProductController 클래스를 모두 고칠 필요가 없음( 강한 결합 해결 ) - 의존성 주입 : 하나의 객체에서 다른 객체가 필요할 때 객체를 직접 생성하지 않고, 이미 생성되어 있는 객체를 가져오는 작업
1-16 스프링 IoC 컨테이너 사용하기
- 빈(Bean) : 스프링이 생성해주는 객체
- 스프링 IoC 컨테이너 : 빈을 모아둔 통
@service도 Bean의 한 종류
this.productService = new ProductService로 만들어서 쓰던 것을 스프링 IoC를 이용하면 이미 만들어져 있는 객체를 가져다가 바로 사용하면 됨.
(@Autowired 이용해서)
1-17 스프링 프레임워크 재이해
