WIL
이번 주는 API만을 만드는 주간이였습니다.
API 및 Input, Output 값을 보고 API 를 만들고, 테스트를 통과하면 되는 과제였습니다.
이전 프론트까지 하던 과제보다는 알고리즘 문제 풀이에 가깝다는 느낌을 받았습니다.
상대적으로 초반엔 빠르게 진행이 되었다가.. 일반적인 출력값과 다르게 List 형식의 입출력을 진행할 때, 한번 막히고..
리스트 내부에 리스트가 중첩되어있는 구조에서 다시 막히는 상황이 일어났습니다.
또한 지속적으로 Test 및 Entity 코드에 에러가 발생하여 3번문항의 모든 파일을 제거하고 다시 작성하는 과정을 반복하게 되었습니다.
https://github.com/Zpoxic/restaurant
어노테이션 기능이 좋은 것은 확실하지만 관계형 DB에 대해 좀 더 알아봐야할 필요성을 느꼈고,
List 형식의 Input, Output에 대해 확인해봐야할 것 같습니다.
POJO (Plain Old Java Object) 오래된 방식의 자바 오브젝트입니다.
Java EE등의 중량 프레임워크들을 사용하면서 프레임워크에 종속된 무거운 객체를 만드는 것에 대해 반발하며 사용하게 된 용어입니다.
ORM 기술을 사용하기위해 ORM을 지원하는 프레임워크를 사용하게된다면 특정 기술에 종속되어 POJO라고 할 수 없습니다.
스프링 개발자들은 ORM이라는 기술을 사용하기 위해서 'JPA'라는 표준 인터페이스를 정해두었습니다. 그리고 이제 여러 ORM 프레임워크들은 이 JPA라는 표준 인터페이스 아래, 구현되어 실행됩니다.
이것이 스프링이 새로운 엔터프라이즈 기술을 도입 하면서도 POJO를 유지하는 방법입니다.
싱글톤 패턴이란.. 전역 변수를 사용하지 않고 객체를 하나만 생성 하도록 하며, 생성된 객체를 어디에서든지 참조할 수 있도록 하는 패턴입니다.
싱글톤은 객체에 접근할 때 메모리 낭비를 막고, 이미 생성되어있는 인스턴스를 활용하기 때문에 속도면에서도 이점이 있습니다.
또한 데이터 공유가 쉬운 것도 장점입니다. 전역으로 사용되는 인스턴스이기 때문에 다른 클래스의 인스턴스들이 접근할 수 있습니다.
하지만 멀티스레딩 환경에서 발생하는 동시성 문제를 잘 해결해주어야합니다.
JPA는 애플리케이션과 JDBC 사이에서 DB와 통신을 위한 도움을 줍니다.
insert 과정은 엔티티를 분석 하여 INSERT SQL을 생성하고, JDBC API를 사용하여 SQL을 DB에 날려줍니다.
find 과정은 개발자가 JPA에게 지급한 id(PK)값을 DB에 보내 DB에서 결과를 받아오고, 관련 결과를 객체에 매핑해줍니다.
JPA는 데이터를 객체지향적으로 관리할 수 있어서 비즈니스 로직에 집중할 수 있고 객체지향 개발이 가능합니다.
자바 객체와 DB테이블 사이의 매핑을 통해 SQL을 생성해주고, 객체를 통해 쿼리를 작성할 수 있는 JPQL이 지원됩니다.
또, 성능 향상을 위한 옵션을 잘 활용하면 SQL을 직접 사용하는 것과 유사한 성능을 기대할 수 있습니다.
참고
https://gmlwjd9405.github.io/2018/07/06/singleton-pattern.html