4) 영속성 전이 :CASCADE (생각보다 많이 씀) CASCADE 란? 즉시 로딩 레이지 로딩과 아무 관계도 아니다! (헷갈릴 수는 있음) 특정 엔티티를 영속화 시킬 때 연관 엔티티도 함께 영속화 시키는 것을 말한다. 예시를 다음과 같이 보자. @Entity @Data public class Parent { @Id @GeneratedValue private Long id; private String name; @OneToMany(mappedBy = "parent") private List children = new ArrayList(); public void addChild(Child child) { children.add(child); child.setParent(this); } } @Entity ..

** 매우 중요한 부분 class Member{ String username; Team team; } class Team{ String name; } Member를 조회할 때 Team 도 함께 조회되어야 할까? ---- 만약 Member에 대한 정보와 Team 에 대한 정보를 한꺼번에 사용을 해야 할 때 : 한번에 쿼리로 가져오면 좋음 ---- 반대로 Member에 대한 정보만 활용하면 될 때 : Team 쿼리 까지 굳이 나가는 것은 손해임. (즉, 비즈니스 상황에 따라 다르긴 함) 1) 프록시 > em.find() // em.getReference() 란 녀석도 있음. getRefrence() 란, DB 조회를 미루는 가짜 (Proxy) Entity 객체가 조회됩니다. 다음 예시 @Test @Displ..

연관관계 매핑시 고려해야할 사항 1. 다중성 (다대일, 일대다, 일대일, 다대다) - 이건 참고로 RDBMS 를 위함임 2. 단방향 양방향 3. 연관주. 1) 다대일 다대다대 (외래키가 가는 곳이 다, 연관관계의 주인이 다, DB를 다스리는 쪽이 다, 조회만 하는쪽이 일) (지난 시간에 한 Member : Team 연관관계로 생각) (내가 DB에 넣을 칼럼과 동기화 시켜주면 됨. @JoinColumn(name = "team_id")) 2) 일대다 일대일대 (이건 연관주를 (일) 쪽에 두겠다는 것) (위에 모델을 뒤집은 것) (Team List 에서 DB를 다스림) (하지만 DB에서는 Member 쪽에 (다) 쪽에 외래키가 들어갈 수밖에 없음. 왜냐면 Team 쪽엔 그러면 ㅅㅂ member_id 계속 넣어..

실제 JPA 가 DB 와 어떻게 엔티티를 매핑할까요? 1) 객체와 테이블 매핑 (@Entity, @Table) @Entity - JPA 가 관리할, 엔티티라 부른다. (No Args Contructor 필수), 이상한 클래스로는 불가 @Table - Entity Class 이름과 다르게 들어가야 한다면 name 지정 가능 2) DB Schema 자동생성 JPA에서는 앱 로딩 시점에 DB table 을 생성하도록 함 -> 당연히 운영은 쓰면 안되고, 완성된 DB 구조를 넣어야 함. (운영에서 쓸 때는 테스트 서버, 릴리즈 서버에 있는 것을 다듬은 다음에 보내야 함) ddl-auto 속성 1) CREATE - 매번 모든 테이블을 (있으면) 모두 삭제후 다시 초기화 시킴 (@Entity 모두 확인 후) (이건..

누군가 저에게 서버가 무엇인가요? 라고 물어본 적이 있습니다. 정말 추상적인 질문이지만, 저는 이 질문에 항상 "서버는 그냥 Data 저장하는 곳입니다" 라고 답변을 합니다. 수많은 Data 가 어딘가에는 저장되어 있어야 하는데, 그 곳이 서버라는 뜻으로 하는 말이며, 수많은 서버의 역할들이 있지만, 결국 모든 서버는 Data 를 위해 동작한다는 생각이 많이 듭니다. IT 서비스를 제공하는 가장 중심에는 Database 가 있습니다. 결국 우리는 우리의 정보를 제공하는 대가로, 서비스를 제공받는 형태로 이루어지는 서비스가 많습니다. 그리고 DB를 어떻게 보여주고 가공하냐에 따라서 서비스는 그들의 기능을 제공해줍니다. Database 는 여러분들이 아시는 관리 시스템을 통해서 관리됩니다 (MySQL, Ma..

1. Ajax 는 FormLogin 과는 다르게 비동기 방식의 JS 통신을 말함 2. 타방법의 인증을 선택하려면 기본적으로 Form Login은 사용하지 않는 것이다. 3. Spring 은 기본적으로 Form Login 을 사용하고 있고, Form Login을 위한 설정들이 박혀 있기 때문에, 그 것을 사용하지 않으려면 Filter, Token, Provider 등을 구현해야 한다. 4. fromLogin 은 disable 후 사용하는게 좋으나, Session 저장 관련해서도 같이 끄기 때문에 SCHoler 등에 저장하는 것은 직접 따로 구현해봐야 할 듯. =================== 인증을 위한 객체들, Ajax 와는 크게 무관. 하지만 기본적으로 필요 ============= 1. Accoun..

프로그램을 배포할 때, 특히 DB가 있는 웹 서비스나 프로그램을 배포할 때 개발자로서 가장 걱정되는 것 중 하나는 역시 보안입니다. 내가 어떻게 막아두든 훨씬 잘하는 공격자들이 마음만 먹으면 얼마든지 공격할 수 있을 것 같기 때문입니다. 사실 보안 전문가와 같이 일하지 않는다면 "완벽한 보안"이란 웹 서비스 개발자들 입장에서는 달성하기 어려운 과제가 아닐까 합니다. 그래도 개발자라면 책임감을 가지고 서버이든, 앱이든 할 수 있는 보안에는 최선을 다해야 합니다. 그러기에 Spring에서도 Admin단에서 효율적인 보안 처리를 도와주는 제공 API가 있는데, 바로 Spring Security 입니다. Spring Security를 배우기에 앞서서는 Spring의 기본적인 사항들, 그리고 Spring의 라이프..

우리는 지금까지 스프링 빈이 스프링 컨테이너의 시작과 함께 생성되어서 스프링 컨테이너가 종료될 때까지 유지된다고 배웠습니다. 이는 스프링 빈들이 기본적으로 싱글톤 객체로 형성되어 관리되기 때문입니다. 여기서 Bean Scope 의 개념에 대해서 살펴볼 필요가 있습니다. Bean Scope 란 말 그대로 빈이 존재할 수 있는 범위를 말합니다. 우선 지정해줄 수 있는 Bean 들의 Scope 종류에 대해서 살펴보겠습니다. (물론 기본은 Singleton 이며, 특수한 경우를 제외하고는 모두 싱글톤으로 제어해주는게 맞습니다) Singleton : 가장 긴 생명주기를 가진 기본 스코프. IOC 컨테이너에서 관리하며, 컨테이너의 시작과 함께 종료까지 유지된다 Prototype : IOC 컨테이너에서는 Bean 의..

프레임워크를 통한 앱 개발을 하다보면 정말 많이 듣는 단어인 Life Cycle (생명주기) 이 Bean 에도 역시 있습니다. 사실 이 Bean 의 생명주기보다 Spring App 자체의 생명주기 뼈대를 우선적으로 이해하는 것이 중요하지만, 이번 포스트에서는 Bean 의 생명주기에 대해서 살펴보겠습니다. 생명주기를 제어하기 위해서는 앱이 실행되면서 필요한 연결들을 미리 해두고 (이 경우 Bean 등록), 앱이 종료 시점에 모든 연결을 해제하고 메모리를 비워낼 수 있는 작업 을 진행해야 하며, 이를 중점으로 살펴볼 예정입니다. 우선 이번 포스트에서 Bean 생명주기 이해를 도와줄 Network Client 객체부터 살펴봅시다. NetworkClient 는 특 정 서버와 연결을 하고 데이터 통신을 해주는 객..

이전 포스트에서 잠시 언급된 적이 있지만, Spring에서는 App 을 탐색하며 Bean을 등록하는 과정은 크게 두 가지 절차를 거치게 됩니다. (당장 지난 포스트에서 그림들. 1번, 2번, 3번 그림) 1. Bean 생성 2. 의존 관계 주입 (DI) 지금까지는 간단히 생성자를 통해서 DI를 진행하였지만 (제일 일반적인 방법입니다), 생성자를 통한 주입 말고도 DI 에는 크게 4가지 전략이 있습니다 (Autowire Strategy). (1) 생성자 주입 @Component public class MemberServiceImpl implements MemberService{ private final MemberRepository memberRepository; @Autowired public Membe..