튼튼발자 개발 성장기🏋️

JPA를 사용하기 위한 설정과 동작 원리에서 언급했던가? 엔티티 매니저 팩토리는 여러 스레드가 동시에 접근해도 안전하기 때문에 서로 다른 스레드 간에 공유해서 사용이 가능 하지만 엔티티 매니저는 여러 스레드가 동시에 사용하게 되면 동시성 문제가 발생하여 스레드 간의 공유가 불가능하다. 영속성 컨텍스트 영속성 컨텍스트는 JPA를 이해하기에 가장 중요하다고 할 수 있다. 영속성 컨텍스트는 '엔티티를 영구적으로 저장하는 환경'이라고 정의되어 있으나 도통 이 말이 이해가되지 않는다. 말로 풀어서 이야기 한다면 엔티티 매니저로 엔티티를 저장하거나 조회하면 엔티티 매니저는 데이터베이스가 아닌 어떠한 공간에 보관하고 관리하는데 이 공간이 영속성 컨텍스트다. 지금까지 살펴본 persist(member)의 메소드가 바로..

JPA를 사용하는 궁극적인 목적은 데이터베이스 관점의 테이블과 객체지향적 객체 사이에서 개발자가 해야할 일을 최소화하고 객체지향적으로 자유롭게 개발하기 위해서다. 따라서, JPA를 사용하려면 가장 먼저 객체를 매핑해야한다. - 객체 매핑 CREATE TABLE MEMBER ( ID VARCHAR(255) NOT NULL, NAME VARCHAR(255), AGE INTEGER, PRIMARY KEY (ID) ) 위 테이블은 아래와 같이 객체 매핑을 할 수 있다. @getter @setter @Entity @Table(name="MEMBER") public class Member { @id private String id; @Column(nullable = true, length = 255, unique ..

JPA(Java Persistence API)를 알기 위해서는 ORM(Object-Relational Mapping)을 알아야 한다. ORM은 객체와 관계형 데이터베이스를 맵핑해주는 녀석이다. 이전에 언급했듯이 자바의 객체와 관계형 데이터베이스간의 차이가 문제를 일으킬수 있다. 이 문제를 최소화 시키기 위해서 ORM이라고 하는 기술이 등장했다. JPA가 바로 자바 플랫폼의 ORM 표준 기술이다. JPA는 [그림 1]과 같이 동작하게 되는데, JPA가 자바 애플리케이션과 JDBC 사이에서 하는 일은 다음과 같다. 패러다임 불일치 해결 (DB 연동 시 유의할점 #2 참고) SQL query 생성 Entity 분석 (추 후에 이야기 하겠지만 여기서의 엔티티란 테이블을 객체화 시킨 것을 이야기 한다.) 우리는 ..

애플리케이션을 개발할 때 상용계 운영과 유지보수도 함게 생각하면서 개발해야 한다. 결국, 내부 로직이 복잡하면 복잡할 수록 유지보수가 어렵고 운영에도 영향을 미치기 쉬울 수 있다. 데이터베이스를 연동 할 때도 복잡해서는 안된다는 이야기이다. 이전 글에서 언급한 것 처럼 개발을 하게 된다면, 유지보수가 말도 못하게 힘들 수 있다. 그렇다고 데이터베이스 연동을 안할 수 없지 않는가. 데이터베이스는 객체지향 이야기 되는 추상화, 상속, 다형성의 개념이 없고, 구조 조차도 다르다. 즉, 객체와 RDB는 각각 지향하는 목적이 다르기 때문에 사용 방법과 표현방식에 차이가 있을 수 밖에 없다. 이 것을 패러다임 불일치 문제라고 이야기 한다. 이러한 문제때문에 객체 구조를 DB 테이블 구조에 저장하는데에 한계가 있을 ..

현대시대에는 자바로 개발되는 애플리케이션을 보면 대부분 관계형 데이터베이스를 사용하고 있다. 이 데이터베이스에서 데이터를 관리하려면 SQL을 사용해야한다. 자바 애플리케이션은 JDBC를 사용해서 DB에 접근한다. 다음 코드를 보자. 우리는 JDBC에게 SQL문을 전달하여 실행하도록 하면서 데이터를 관리한다. String sql = "SELECT NAME FROM MEMBER WHEHERE ID = ?"; ResultSet resultSet = stmt.executeQuery(sql); String name = resultSet.getString("NAME"); Member member = new Member(); member.setName(name); logger.info(member.getName())..

달달달 외우는 것을 싫어하고 암기력도 좋지 않아서 이과를 선택했다. 뭘 외우고 있는가? 외울 시간에 이해를 하려고하고 적용을 해보려고 해보자. 이전 글을 참고하자. 꼭. #1 : RESTful API 개발자라면 RESTful에 대해 한 번이라도 들어 보았을 것이라 생각이 든다. 그러나 정작 "RESTful이 뭐야?"라고 물었을 때 진정으로 정답을 말하기 애매한 것 같다. 실제로 사내 프로젝트로 서버 개발을 했을 때 R.. dotori.ga 위 내용에 덧붙여 더 깊게 알아보자. REST의 구성 요소는 다음과 같다. 표현방식 : HTML 등 식별자 : URI 행위 : HTTP REST architecture style Server - Client 자원 제공을 server, 요청을 client가 한다. ser..

REST를 구성하는 아키텍처 스타일을 모아보았다. Client - Server Stateless Cache Uniform Interface Layered System Code On Demand (이 녀석은 Optional) 잘 보면 HTTP API만 잘 지켜져도 다 만족할 수 있는 녀석들이다. 그러나 4번 Uniform Interface라는 녀석만이 지켜지기 어렵다. Uniform Interface의 4가지 제약조건이 있다. Identification of resources Manipulation of resources through representions self descriptive messages hypermedia as the engine of application state 이 중에서도 3번 ..

개발자라면 RESTful에 대해 한 번이라도 들어 보았을 것이라 생각이 든다. 그러나 정작 "RESTful이 뭐야?"라고 물었을 때 진정으로 정답을 말하기 애매한 것 같다. 실제로 사내 프로젝트로 서버 개발을 했을 때 RESTful을 사용해서 서버를 구축한 경험어 있다. 그러나 코드리뷰로부터 "REST 스럽지 않다."라는 피드백을 받은 적이 있었다. 그럼 REST 스러운게 무엇일까? REST의 풀 네임은 [REpresentational State Transfer]라고 한다. 그래도 모르겠다. 그래서 REST가 만들어진 계기를 찾아보았다. 1991년으로 넘어가 보자. 인터넷을 사용하던 시절 www(World Wide Web)이 탄생할 때 어떻게 데이터를 서로 주고받을 것인지에 대해 논의를 하던 도중 다음과..