UMC - 2nd Server/UMC - 2nd Server 스터디

UMC - 2nd Server/UMC - 2nd Server 스터디

UMC 2nd Server - 추가 스터디 : Lombok - @Getter, @Setter, @~ArgsConstructor

Model 클래스 같은 경우에 수많은 멤버 변수가 있고, getter와 setter, 멤버 변수에 따른 생성자를 필요로 한다. 이때, getter와 setter, 생성자 코드를 작성하면, 코드가 길어진다. 이때 사용하는 것이 Lombok 라이브러리다! Lombok 라이브러리를 사용하면 여러 코드를 애노테이션 몇 개로 줄일 수 있다. 기존 코드 public class ExampleModel { private String name; // Getter 코드 public String getName() { return name; } // Setter 코드 public void setName(String name) } this.name = name; } } Lombok의 @Getter / @Setter 애노테이션 ..

UMC - 2nd Server/UMC - 2nd Server 스터디

UMC 2nd Server - 추가 스터디 : 다양한 의존관계 주입 방법

스프링의 의존관계 주입 방법 - 3가지 필드 주입 setter 주입 생성자 주입 1. 필드 주입 @Controller public class ExampleController { @Autowired private ExampleService exampleService; } 👉 이렇게 필드 주입을 하게되면 스프링 실행 시 스프링 빈이 주입 되는데, 그 빈을 개발자가 바꿀 수 없다. 👉 테스트 코드 작성 시에 문제가 된다. 테스트 시에는 스프링 컨테이너의 도움 없이 ExampleService가 가지고 있는 여러 Repository를 자유롭게 변경하며 테스트가 가능해야 하는데, 필드 주입을 하면 스프링 실행 시 주입된 스프링 빈밖에 사용하지 못하므로 테스트 단에서 Repository 등을 스프링 컨테이너 없이 변..

UMC - 2nd Server/UMC - 2nd Server 스터디

UMC 2nd Server - 추가 스터디 : 스프링 빈 & 의존관계 주입

스프링 빈 스프링에서 스프링 컨테이너는 @Controller / @Service / @Repository 애노테이션이 붙은 클래스 객체를 스프링 실행 시 스프링에 넣어둔다! 이때 생성되는 객체를 스프링 빈이라고 하고, 스프링 빈은 스프링 컨테이너가 관리한다! @Controller public class ExampleController { ... } 👉 이렇게 되어 있으면 스프링 실행 시 ExampleController가 스프링 컨테이너에 의해 스프링 빈으로 등록된다. @Service public class ExampleService { ... } 이렇게 ExampleService도 @Service 를 사용하여 스프링 컨테이너에 의해 스프링 빈으로 등록되어 있다고 하자. 의존관계 주입을 하지 않는다면? @..

UMC - 2nd Server/UMC - 2nd Server 스터디

UMC 2nd Server - 추가 스터디 : JdbcTemplate 메소드

update() 메소드 JdbcTemplate에서 삽입, 수정, 삭제는 update() 메소드를 사용한다. 이때, update() 메소드는 쿼리 실행 결과 변경된 행의 개수를 리턴한다! update(쿼리문, 치환자에 대한 파라미터) ※ 치환자 - ‘?’ : ex) "update users set name=? where password=?" 1. 삽입 (INSERT) public int createUser(PostUserReq postUserReq){ String createUserQuery = "insert into User (name, nickName, phone, email, password) VALUES (?,?,?,?,?)"; Object[] createUserParams = new Object[..

UMC - 2nd Server/UMC - 2nd Server 스터디

UMC 2nd Server - 추가 스터디 : @RequestBody / @ResponseBody

클라이언트와 서버의 비동기 통신 클라이언트 → 서버로 통신하는 메세지 : 요청(Request) 메세지 서버 → 클라이언트로 통신하는 메세지 : 응답(Response) 메세지 웹에서 새로고침없이 이루어지는 동작들은 대부분 비동기 통신으로 이루어진다. 비동기 통신을 하기 위해서는 클라이언트 → 서버로 요청 메세지를 보낼 때, Body에 데이터를 담아서 보내야하고, 서버 → 클라이언트로 응답을 보낼때도 Body에 데이터를 담아서 보내야한다. 이때, 데이터들을 다 JSON으로 주고 받는다. 웹페이지에서 JSON으로 Request한 파라미터들을 JAVA에서 받으려면 JAVA 객체로의 변환이 필요하고, 마찬가자로 Response 시에도 JAVA 객체에서 JSON으로 변환이 필요하다. 이러한 JSON ↔ JAVA 객..

UMC - 2nd Server/UMC - 2nd Server 스터디

UMC 2nd Server - 추가 스터디 : 동기(Sync) VS 비동기(Async) 통신

비동기(Async) 통신 / 동기(Sync) 통신 동기(Sync) Synchronous로, 동시에 일어난다는 뜻이다. Request를 보내게 되면 시간이 얼마나 걸리든 Response를 받기 전까지 대기한다. Request를 보낸 Thread는 Response가 도착하기 전까지 아무것도 하지 못하는 Block 상태가 된다. 👉 두 서버 사이의 Transction을 맞춘다. 장점 Request(요청)와 Respond(응답)의 순서가 보장된다. Request에 대한 Respond를 보장받을 수 있다. 단점 Request에 대한 Response가 지연된다면 Request를 보낸 Thread는 해당 Response를 기다려야하는 Block 상태가 된다. 비동기(Async) ASynchronous로, 동시에 수행..

UMC - 2nd Server/UMC - 2nd Server 스터디

UMC 2nd Server - 추가 스터디 : @RequestMapping

@RequestMapping : 컨트롤러의 모든 API의 URI 앞에 기본적으로 들어가는 애노테이션 특정 URI로 요청을 보내면 Controller에서 어떤 방식으로 처리할지 정의하는데, 이때 들어온 요청을 특정 메소드와 맵핑하기 위해 사용하는 것이 @RequestMapping UMC springboot template 예제에서는 @RequestMapping 아래에 @GetMapping을 써서 부모-자식 간의 조합으로 사용했다. @RestController @RequestMapping("/users") public class UserController { @ResponseBody @GetMapping("/{userIdx}") // (GET) 127.0.0.1:9000/users/:userIdx publi..

UMC - 2nd Server/UMC - 2nd Server 스터디

UMC 2nd Server - 추가 스터디 : Proxy Server / Forward Proxy / Reverse Proxy

Proxy 서버 / Forward, Reverser Proxy 1. Proxy 서버 서비스를 제공하는 서버 대신 무언가를 대신 수행하는 서버 프록시 서버의 주요 역할 웹 서버의 로드 감소 웹 서비스의 전체 과정 웹 서비스는 Client - Web - Web Server 영역을 사용한다. Client : 서비스를 이용하는 사용자 Web : 사용자가 요청한 page, file 등을 Web Server에 전달 Web Server : 클라이언트의 요청에 맞는 데이터를 응답 웹 서비스 요청-응답 과정 모든 클라이언트의 요청마다 위의 과정을 거치게 된다. 이때, 서버가 응답하는 데이터에는 변하지 않는 정적 데이터와 사용자별, 시간별에 따라 달라지는 동적 데이터가 존재한다. 동적 데이터는 어쩔 수 없지만, 정적 데이..

BE_성하
'UMC - 2nd Server/UMC - 2nd Server 스터디' 카테고리의 글 목록