JDBC JDBC란 DB에 접근(Connectivity)할 수 있도록 Java에서 제공하는 API이다. JDBC API가 있고 JDBC DriverManager가 DB제품에 따른 드라이버를 생성하여 JDBC API에 맞게 동작할 수 있게 처리해준다. 따라서 우리는 JDBC API 변경없이 JDBC 드라이버만 바꿔주면 어떤 제품의 DB든 연결할 수 있다. 쿼리를 실행하기 전과 후에 연결 생성, 명령문, ResultSet 닫기등과 같은 많은 코드를 작성해야한다. 또 connection 관리, 예외처리등에 불편함이 있어 나온게 Spring JDBC이다. Spring JDBC -핵심 : JdbcTemplate- Spring JDBC는 JDBC에서 DriveManager가 하는 일들을 JdbcTemplate에게 ..

DAO DAO(Data Access Object) 는 데이터베이스의 data에 접근하기 위한 객체이다. DataBase에 접근 하기 위한 로직 & 비지니스 로직을 분리하기 위해 사용한다. DTO DTO(Data Transfer Object) 는 계층 간 데이터 교환을 하기 위해 사용하는 객체로, DTO는 로직을 가지지 않는 순수한 데이터 객체(getter & setter 만 가진 클래스)이다. 데이터 전송 객체 즉, DTO는 기능은 없고 데이터를 전달만 하는 용도로 사용되는 객체를 뜻한다. 참고로 DTO에 기능이 있으면 안되는가? 그것은 아니다. 객체의 주 목적이 데이터를 전송하는 것이라면 DTO라 할 수 있다. 객체 이름에 DTO를 꼭 붙여야 하는 것은 아니다. 대신 붙여두면 용도를 알 수 있다는 장점..

1.트랜잭션 문제 2.예외 누수 문제 3.JDBC 반복 문제 트랜잭션 문제 JDBC 구현 기술이 서비스 계층에 누수되는 문제 트랜잭션을 적용하기 위해 JDBC 구현 기술이 서비스 계층에 누수되었다. 서비스 계층은 순수해야 한다. 구현 기술을 변경해도 서비스 계층 코드는 최대한 유지할 수 있어야 한다. (변화에 대응) 그래서 데이터 접근 계층에 JDBC 코드를 다 몰아두는 것이다. 물론 데이터 접근 계층의 구현 기술이 변경될 수도 있으니 데이터 접근 계층은 인터페이스를 제공 하는 것이 좋다. 서비스 계층은 특정 기술에 종속되지 않아야 한다. 지금까지 그렇게 노력해서 데이터 접근 계층으로 JDBC 관련 코드를 모았는데, 트랜잭션을 적용하면서 결국 서비스 계층에 JDBC 구현 기술의 누수가 발생했다. 트랜잭션..

트랜잭션 - 개념 이해 데이터를 저장할 때 단순히 파일에 저장해도 되는데, 데이터베이스에 저장하는 이유는 무엇일까? 여러가지 이유가 있지만, 가장 대표적인 이유는 바로 데이터베이스는 트랜잭션이라는 개념을 지원하기 때문이다. 트랜잭션을 이름 그대로 번역하면 거래라는 뜻이다. 이것을 쉽게 풀어서 이야기하면, 데이터베이스에서 트 랜잭션은 하나의 거래를 안전하게 처리하도록 보장해주는 것을 뜻한다. 그런데 하나의 거래를 안전하게 처 리하려면 생각보다 고려해야 할 점이 많다. 예를 들어서 A의 5000원을 B에게 계좌이체한다고 생각해보자. A의 잔고를 5000원 감소하고, B의 잔고를 5000원 증가해야한다. 5000원 계좌이체 A의 잔고를 5000원 감소 B의 잔고를 5000원 증가 계좌이체라는 거래는 이렇게 2..

데이터베이스 커넥션 데이터베이스 커넥션 풀에 대해 알아보기 이전에 데이터베이스 커넥션이 무엇인지부터 알아봐야한다. 우리가 개발하는 웹 애플리케이션과 데이터베이스는 서로 다른 시스템이다. 따라서 데이터베이스 드라이버를 사용하여 데이터베이스에 연결해야한다. 데이터베이스 연결의 생애주기는 아래와 같다. 1. 데이터베이스 드라이버를 사용하여 데이터베이스 연결 열기 2. 데이터를 읽고 쓰기 위해 TCP 소켓 열기 3. TCP 소켓을 사용하여 데이터 통신 4. 데이터베이스 연결 닫기 5. TCP 소켓 닫기 위와 같이 데이터베이스 연결을 수립하고, 해제하는 과정은 비용이 많이 들어가는 작업이다. 사용자로부터 웹 애플리케이션에 요청이 들어올때마다 데이터베이스 연결을 수립하고, 해제하는 것은 굉장히 비효율적으로 보인다...

JDBC는 1997년에 출시될 정도로 오래된 기술이고, 사용하는 방법도 복잡하다. 그래서 최근에는 JDBC를 직접 사용하기 보다는 JDBC를 편리하게 사용하는 다양한 기술이 존재한다. 대표적으로 SQL Mapper와 ORM 기술로 나눌 수 있다. SQL Mapper 장점 1. JDBC를 편리하게 사용하도록 도와준다. 2. SQL 응답 결과를 객체로 편리하게 변환해준다. 3. JDBC의 반복 코드를 제거해준다. 단점 1. 개발자가 SQL을 직접 작성해야한다. 대표 기술: 스프링 JdbcTemplate, MyBatis ORM 기술 ORM은 객체를 관계형 데이터베이스 테이블과 매핑해주는 기술이다. 이 기술 덕분에 개발자는 반복적인 SQL을 직접 작성하지 않고, ORM 기술이 개발자 대신에 SQL을 동적으로 만..

JDBC의 등장 이유 애플리케이션을 개발할 때 중요한 데이터는 대부분 데이터베이스에 보관한다. 클라이언트가 애플리케이션 서버를 통해 데이터를 저장하거나 조회하면, 애플리케이션 서버는 다음 과정을 통해서 데이터베이스를 사용한다. 1. 커넥션 연결: 주로 TCP/IP를 사용해서 커넥션을 연결한다. 2. SQL 전달: 애플리케이션 서버는 DB가 이해할 수 있는 SQL을 연결된 커넥션을 통해 DB에 전달한다. 3. 결과 응답: DB는 전달된 SQL을 수행하고 그 결과를 응답한다. 애플리케이션 서버는 응답 결과를 활용한다. 문제는 각각의 데이터베이스마다 커넥션을 연결하는 방법, SQL을 전달하는 방법, 그리고 결과를 응답 받는 방법이 모두 다르다는 점이다. 참고로 관계형 데이터베이스는 수십개가 있다. 여기에는 2..

쿠키에 중요한 정보를 보관하는 방법은 여러가지 보안 이슈가 있다. 이 문제를 해결하려면 중요한 정보를 모두 서버에 저장해야 한다. 그리고 클라이언트와 서버는 추정 불가능한 임의의 식별자 값으로 연결해야 한다. 이렇게 서버에 중요한 정보를 보관하고 연결을 유지하는 방법을 세션이라 한다. 로그인 정보가 서버에 넘어오면 세션 저장소에 값이 들어간다. 이때 세션ID(UUID)를 생성하는데 이 UUID는 추정이 불가능하다. (Cookie: mySessionId=zz0101xx-bab9-4b92-9b32-dadb280f4b61) 생성된 세션 ID와 세션에 보관할 값( memberA )을 서버의 세션 저장소에 보관한다. 클라이언트와 서버는 결국 쿠키로 연결이 되어야 한다. 서버는 클라이언트에 mySessionId 라..

쿠키를 사용해서 로그인Id를 전달해서 로그인을 유지할 수 있었다. 그런데 여기에는 심각한 보안 문제가 있다. 보안 문제 1. 쿠키 값은 임의로 변경할 수 있다. 클라이언트가 쿠키를 강제로 변경하면 다른 사용자가 된다. 실제 웹브라우저 개발자모드 Application Cookie 변경으로 확인 Cookie: memberId=1 Cookie: memberId=2 (다른 사용자의 이름이 보임) 2. 쿠키에 보관된 정보는 훔쳐갈 수 있다. 만약 쿠키에 개인정보나, 신용카드 정보가 있다면? 이 정보가 웹 브라우저에도 보관되고, 네트워크 요청마다 계속 클라이언트에서 서버로 전달된다. 쿠키의 정보가 나의 로컬 PC에서 털릴 수도 있고, 네트워크 전송 구간에서 털릴 수도 있다. 3. 해커가 쿠키를 한번 훔쳐가면 평생 ..

선수지식 web은 domain을 알고있지만 domain은 web을 모르도록 설계해야 한다. 이것을 web은 domain을 의존하지만, domain은 web을 의존하지 않는다고 표현한다. 예를 들어 web 패키지를 모두 삭제해도 domain에는 전혀 영향이 없도록 의존관계를 설계하는 것이 중요하다. 반대로 이야기하면 domain은 web을 참조하면 안된다. 우선 html파일로 홈 화면을 구현해보자. public class HomeController { @GetMapping("/") public String home() { return "home"; } } 1.Member package hello.login.domain.member; import lombok.Data; import javax.validati..

@RequestBody와 @ModelAttribute는 클라이언트 측에서 보낸 데이터를 Java 코드에서 사용할 수 있는 오브젝트로 만들어주는 공통점이 있다. 하지만 이 두 애너테이션은 세부 수행 동작에서 큰 차이를 보인다. @RequestBody 클라이언트가 보내는 HTTP 요청 본문(JSON 및 XML 등)을 Java 오브젝트로 변환하는 것. HTTP 요청 본문 데이터는 Spring에서 제공하는 HttpMessageConverter를 통해 타입에 맞는 객체로 변환된다. 1. @RequestBody를 사용하면 요청 본문의 JSON, XML, Text 등의 데이터가 적합한 HttpMessageConverter를 통해 파싱되어 Java 객체로 변환 된다. 2. @RequestBody를 사용할 객체는 필드를..