출처: 자바 ORM 표준 JPA 프로그래밍 PersistenceContext: 영속성 컨텍스트 영속화의 의미는 데이터를(엔티티) 영구 저장하는 것. 그것에 사용되는 논리적인 환경이 영속성 컨텍스트이다. EntityManager를 통해 접근할수 있다. 세부적으로는 EntityManagerFactory에서 EntityManager를 만들고, 그걸 트랜잭션 단위로 클라이언트가 사용한다. 생명주기 • 비영속 (new/transient) 영속성 컨텍스트와 전혀 관계가 없는 새로운 상태 • 영속 (managed) 영속성 컨텍스트에 관리되는 상태 • 준영속 (detached) 영속성 컨텍스트에 저장되었다가 분리된 상태 • 삭제 (removed) 삭제된 상태 영속성 컨텍스트의 이점 1차캐시 - 영속성 컨텍스트에 포함되..
출처: 자바 ORM 표준 JPA 프로그래밍 주된 이유: 패러다임의 불일치 . . . ===객체지향 언어와 관계형 데이터베이스의 차이에서 오는 어려움=== -객체를 테이블에 맞추어 모델링 해야함: 객체는 상속관계, 테이블은 슈퍼타입 서브타입 관계, 객체는 참조 사용, 테이블은 외래키 사용 -진정한 의미의 계층분할이 어려움: DAO 작성자와 service 작성자가 다를때, 서비스에서 DAO를 맘놓고 못쓴다. 쿼리가 실제로 어떻게 나가는지 일단 확인해야하기 때문이다. -객체를 자바 컬렉션처럼 디비에 저장하고 사용하고싶음: 그래야 다형성, 객체 그래프 탐색 등이 쉬움 종합하면, 프로그래머는 객체지향 프로그래밍의 장점을 살려서 프로그래밍 하고싶다. 그러나 패러다임의 불일치로 인해서 급한 불을 끄는 식으로 sql ..
김영한님의 JPA 인강을 드디어 다 들었다. 17시간 짜리 강의이고, 강의 내용도 쉽지않아서 힘들었다. 사실 난이도 자체가 너무 어렵고 이해가 죽어도 안된다는 느낌은 아니였고, 강의에서 안다고 전제하고 설명하는 것들, 초반부에 알려주고 제대로 복습이 안된것들에 대해서 슉슉 지나가는 느낌이여서 힘들었다. DB설계와 SQL에 관한 내용들이 특히 알쏭달쏭했다. 하지만 이 강의를 듣기 잘했다고 생각하는게, 이렇게 내가 뭘 모르는지 아는 상태가 되는것이 너무너무 필요했기 때문이다. 이제부터 강의를 쭉 복습해서 블로그에 정리하고, 남은 강의들을 빨리 듣고나서 토이 프로젝트를 얼른 해보고싶다.
강의 복습 스프링에서 DB 연결 같이 초기화랑 종료 작업이 필요한 일을 어떻게 해야할까? 초기화 콜백, 소멸전 콜백 이 두개를 사용하면 된다. 그전에 알아야 할 사실...! 스프링 빈의 이벤트 라이프사이클 스프링 컨테이너 생성 스프링 빈 생성 의존관계 주입 초기화 콜백 사용 소멸전 콜백 스프링 종료 이 순서로 이루어진다. 다시 돌아와서, 다양한 방식으로 이런 생명주기 콜백을 지원한다. 1. 인터페이스(InitializingBean, DisposableBean) 2. 설정 정보에 초기화 메서드, 종료 메서드 지정 3. @PostConstruct, @PreDestory 애노테이션 지원 이 중에서 @PostConstruct, @PreDestory 애노테이션을 사용하자 이유? -> 최신 스프링에서 가장 권장하는..
강의 복습 자동등록 이전까지는 config, xml, 혹은 사용자 지정 설정 파일로 직접 스프링 빈을 등록했었다. @ComponetScan, @Component, @Autowired 등의 사용은 이들을 편하게 자동으로 해준다. @Component 말고도 @Configuration @Service @Controller @Repository 이런것들이 붙어있어도 빈으로 등록된다 -> 사실 위 annotation 들은 @Component를 포함하고 있기 때문이다. +어노테이션이 상속을 지원하고 이런건아닌데, 스프링 쓰면 비슷하게 동작한다. 옵션 컴포넌트 스캔은 다양한 옵션이있다. FilterType이라고 한다. FilterType은 5가지 옵션이 있다. ANNOTATION: 기본값, 애노테이션을 인식해서 동작..
강의 복습 싱글톤 패턴: 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다. -> 그래서 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 한다. 그래서 직접 싱글톤 패턴을 만들어 봤었다. 그런데 여러 문제가 있었다. 싱글톤 패턴 문제점: 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다. 의존관계상 클라이언트가 구체 클래스에 의존한다. DIP를 위반한다. 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다. 테스트하기 어렵다. 내부 속성을 변경하거나 초기화 하기 어렵다. private 생성자로 자식 클래스를 만들기 어렵다. 결론적으로 유연성이 떨어진다. 안티패턴으로 불리기도 한다. ...단점이 이렇게 많다고? 하지만 스프링 컨테이너를 쓰면 단점을 모두 없에고 장..
강의 복습 //스프링 컨테이너 생성 ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class); ApplicationContext 인터페이스에 여러가지 구현체를 대입하여 스프링 컨테이너를 생성가능하다. 등록된 스프링 빈은 설정정보를 이용, DI 가 이루어진다. 스프링 컨테이너에서 스프링 빈을 찾는 가장 기본적인 조회 방법: ac.getBean(빈이름, 타입) ac.getBean(타입) 해당 타입 전부 조회: ac.getBeansOfType() 조회시 고려사항: 타입 조회시 같은 타입 빈이 둘 이상이면? -> 오류 부모타입으로 조회하면? -> 자식 타입 전부 조회됨. ApplicationCont..
강의 복습 섹션 2, 3에서는 스프링 핵심 원리 이해에 관한 내용을 배웠다. 우선 스프링 없이 프로젝트를 생성 후, 불편함을 해결하다보면 왜 스프링이라는 프레임워크가 나올 수 밖에 없는지 따라갈수 있었다. JUnit을 통한 테스트 작성 방법도 배웠다. 사실 이전에 들은 스프링 입문 강의에서 듣긴했지만. 스프링의 핵심은 좋은 객체지향 프로그래밍을 쉽게 만들 수 있게 해주는것이다. 좋은 객체지향 프로그래밍은, SOLID 원칙을 준수하면 된다. config파일을 생성해서 리팩토링하면 기존 코드로만은 지키기 불가능한 SRP,OCP, DIP 원칙을 지킬 수 있다. 이 config 파일을 생성한 것이 프레임워크를 쓰면 얻는 장점과 유사하다. IoC, DI 이것들이 config 덕에 생겨났다. IoC = 제어의 역전..
