분류 전체보기 (46) 썸네일형 리스트형 Gradle 태스크 1. 기본 예제 예제1> task hello Gradle 기본 그레이들 스크리트 파일과 기본 객체 초기화 스크립트 -> Gradle객체 처음 시작 되는 스크립트 (init.gradle) 사용자 정보, 초기 설정 값, 실행 환경 등 설정 스크립트 -> Settings객체 파일 구조(싱글, 멀티등) 빌드에 대한 설정 정보(settings.gradle) 빌드 스크립트 -> Project 객체 그레이들 기본 객체들을 이용해 초기화와 설정 스크립트의 내용 이용 가능 그레이들 구성요소들 그레이들 속성파일: (gradle.properties, Project폴더 하위에 있음)/ 빌드 환경 속성 등 내용 환경변수: 시스템에 등록한 Gradle설치 정보 명령어 옵션: 빌드 수행시 명령어와 옵션 정보를 인수로 전달. (gradle -Pname=gradle hello) buildSrc.. 컴포넌트 스캔 1. @ComponentScan @Bean붙일 필요 없이 @Component적힌 자동 스프링 빈 등록 (하나의 AppConfig로 관리 안해도 됨.) @ComponentScan시 @Configuration 붙은 설정들도 자동 등록 됨 basePackages를 이용해 시작 위치를 지정할 수 있다. 이때 이 패키지를 포함해서 하위 패키지를 모두 탐색 basePackage = { "hello.core", "hello.service"} 이렇게 여러 시작 위치 지정할 수도 있다. 지정하지 않으면 @ComponentScan이 붙은 설정 정보 클래스의 패키지가 시작 위치가 된다. 권장방법1: 설정 정보클래스의 위치를 프로젝트 최상단에 두기 권장방법2: 스프링 부트면 @SpringBootApplication를 프로젝트.. 싱글톤 (웹과 관련하여) 1. 스프링과 비교 웹 어플리케이션은 보통 여러 고객이 동시에 요청 스프링없는 순수한 DI 컨테이너는 AppConfig 요청을 할떄마다 객체 생성. 객체 인스턴스를 생성하는 비용이 1000 이라면 가져오는 비용은 1정도로 차이가 큼. 2. 싱글톤 패턴의 문제점 싱글톤 패턴 구현 코드 많이 들어감. 의존 관계상 클라이언트가 구체 클래스에 의존(DIP 위반) 클라이언트가 구체 클래스에 의존해서 OCP위반 가능성 높음. 테스트 하기 어려움. 내부 속성을 변경ㅎ거나 초기화 하기 어렵다. private생성자로 자식 클래스를 만들기 어렵다. 결론적으로 유연성 떨어진다. 안티패턴으로 불리기도 한다. 3. 싱글톤 컨테이너 스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤으로 관리한다. 스프링.. 의존성 자바코드 기반 1. 기본적인 방식의 의존 MemberService service = new MemberServiceImpl(); 문제점: OCP & DIP 문제 특히 DIP에서는 인터페이스와 구현 클래스 함께 의존 2. AppConfig를 통해 의존성 분리 public class AppConfig{ public MemberService memberService(){ return new MemberServiceImpl(memberRepository()); } public MemberRepository memberRepository(){ return new MemoryMemberRepository(); } } //Impl 생성자 public MemeryServiceImpl(MembmerRepository m.. JPA Basics - JPQL Advanced 1. 경로 표현식 ◍ 경로표현식: .(점)을 찍어 객체 그래프를 탐색하는 것 select m.username -> 상태 필드 from Member m join m.team t. -> 단일 값 연관 필드 join m.orders o -> 컬렉션 값 연관 필드 where t.name = '팀A' ◍ 용어 정리 ○ 상태필드(state field): 단순히 값을 저장하기 위한 필드(ex> m.username) ○ 연관필드(association field): 연관 관계를 위한 필드 ◼ 단일값 연관 필드: @ManyToOne, @OneToOne, 대상이 엔티티(ex> m.team) ◼ 컬렉션 값 연관 필드: @OneToMany, @ManyToMany, 대상이 컬렉션(ex> m.orders) ◍ 특징 ○ 상대 필드 .. JPA Basic - JPQL Basic 0. 기본 ◍ JPQL: 엔티티 객체를 대상으로 쿼리 ◍ JPA는 SQL을 추상화한 JPQL 이라는 객체 지향 쿼리 언어 제공. ◍ 검색 조건이 있는 쿼리가 필요할 때 사용. ◍ 동적쿼리: Criteria 보다 쿼리DSL ◍ QueryDSL ○ 문자가 아닌 자바코드로 JPQL 작성 가능 ○ JPQL빌더 역할 ○ 컴파일 시점에 문법 오류를 찾을 수 있음 ○ 동적 쿼리 작성 편리함 ○ 단순하고 쉬움 ○ 실무사용 권장! ◍ 네이티브 SQL ○ JPA가 제공하는 SQL을 직접 사용하는 기능 ○ JPQL로 해결할 수 없는 특정 데이터베이스에 의존적인 기능 EX> 오라클 CONNECT BY, 특정 DB만 사용하는 SQL 힌트 ◍ JDBC 직접 사용, SpringJdbcTemplate 등 ○ JPA를 사용하면서 JD.. JPA Basic - 값 타입 1. 기본 값 타입 ◍ JPA의 데이터 타입 분류 ○ 엔티티 타입 ◼ @Entity로 정의하는 객체 ◼ 데이터가 변해도 식별자로 지속해서 추적 가능 ○ 값 타입 ◼ int, Integer, String 처럼 단순히 값으로 사용하는 자바 기본 타입이나 객체 ◼ 식별자가 없고 값만 있으므로 변경시 추적 불가 ◍ 값타입 분류 ○ 기본 값 타입: 자바 기본 타입(int, double)/ 래퍼 클래스(Integer, Long)/ String ○ 임베디드 타입: 복합 값타입 ○ 컬렉션 값타입 ◍ 기본값 타입 ○ 생명 주기를 엔터티에 의존 ○ 값 타입은 공유하면 안됨. ○ 자바의 기본 차입은 절대 공유 불가. ◼ int,double같은 기본 타입은 절대 공유 못함 ◼ 기본 타입은 항상 값을 복사함. ◼ Integer.. JPA Basic - 프록시, CASCADE, 고아객체 1. 프록시 ◍ 기초 ○ em.find = 데이터 베이스 통해서 실제 엔티티 객체 조회 ○ em.getReference(): 데이터 베이스 조회를 미루는 가짜 엔티티 조회(프록시) ○ 특징 ◼ 실제 클래스를 상속 받아서 만들어짐. ◼ 실제 클래스와 겉 모양이 같다. ◼ 사용하는 입장에서는 진짜 객체인지 프록시 객체인지 구분하지 않고 사용하면 됨(이론상) ◼ 프록시 객체는 실제 객체의 참조(target)를 보관 ◼ 프록시 객체를 호출하면 프록시 객체는 실제 객체의 메소드 호출 ○ 프록시 객체의 초기화 Member member = em.getReference(Member.class, "id1"); member.getName() //1. getName() //2. 영속성 컨텍스트에 초기화 요청 //3. DB조.. JPA Basic - 상속관계 매핑 1. 상속관계 매핑 ◍ 관계형 데이터 베이스는 상속관계 없음 ◍ 슈퍼타입 서브타입 관계라는 모델링 기법이 객체 상속과 유사. -> 객체의 상속과 구조와 DB의 슈퍼타입 서브타입 관계를 매핑 ◍ 방법 ○ 각각 테이블로 변환 -> 조인전략 (정석 및 깔끔한 설계 - 그러나 성능 이슈 있을 수도) ◼ DTYPE 으로 구분하여 JOIN ◼ 장점: 테이블 정규화. 외래키 참조 무결성 제약조건 활용가능/저장공간 효율화 ◼ 단점: 조회시 조인 많이 사용/ 성능 저하/ 조회 쿼리가 복잡/ 데이터 저장시 INSERT 2번 호출 ○ 통합 테이블로 변환 -> 단일 테이블 전략 (기본) ◼ 장점: 조인이 필요 없으므로 일반적으로 조회 성능 빠름/ 조회 쿼리 단순함 ◼ 단점: 자식 엔티티가 매핑한 컬럼 모두 null 허용/ .. 이전 1 2 3 4 5 다음