일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- springboot
- 백준 17626
- sql 기술면접
- spring security
- 프로그래머스
- 백준 19238
- re.split
- 파이썬
- MSA
- 프로래머스
- with recursive
- java
- spring cloud
- 백준 16719
- Spring Boot
- 백준 16236
- Coroutine
- JVM
- 웹어플리케이션 서버
- 백준 15685
- java 기술면접
- 백준 파이썬
- Spring
- Kotlin
- spring oauth
- 백준 16235
- 백준
- 백준 17779
- MySQL
- JPA
- Today
- Total
목록Programming (98)
시작이 반
준영속성 상태만드는 법 em.detach(entity) 특정 엔티티만 준영속 상태로 전환 em.clear() 영속성 컨텍스트를 완전히 초기화 em.close() 영속성 컨텍스트를 종료 준영속 엔티티? 영속성 컨텍스트가 더는 관리하지 않는 엔티티 ex) 임의로 만들어낸 엔티티가 식별자를 가지고 있는경우, db에서 데이터를 찾아 해당 데이터로 new Entity()를 만든 엔티티 준영속성 엔티티를 수정하는 2가지 방법 변경 감지 기능 사용 병합 사용 변경 감지 기능 사용 @Transactional void update(Item itemParam) { //itemParam: 파리미터로 넘어온 준영속 상태의 엔티티 Item findItem = em.find(Item.class, itemParam.getId())..
@Valid : 객체의 값을 검증해준다. @PostMapping("/members/new") public String create(@Valid MemberForm form) { Address address = new Address(form.getCity(), form.getStreet(), form.getZipcode()); Member member = new Member(); member.setName(form.getName()); member.setAddress(address); memberService.join(member); return "redirect:/"; } @Getter @Setter public class MemberForm { @NotEmpty(message = "회원 이름은 필수 입..
ex) H2 test 폴더안에 resources폴더를 생성한다. 기존에 main폴더에 있던 application.yml을 그대로 복사하여 test의 resources폴더 안에 넣는다. (테스트에서 할 설정과 운영의 설정은 다르기 떄문에 분리하는게 맞음) Cheat Sheet에 가보면 in-Memory 에 jdbc:h2:mem:test 가 있다. url을 jdbc:h2:mem:test 로 바꿔주면 메모리 모드로 동작한다. 그런데 Spring Boot는 별도의 설정이 없을 경우 메모리 모드로 동작한다. 이렇게 주석처리해도 메모리 모드로 동작함
싱글톤 패턴일때 스프링 빈의 이벤트 사이클 "스프링 컨테이너 생성" -> "스프링 빈 생성" -> "의존관계 주입" -> "초기화 콜백" -> "사용" -> "소멸전 콜백" -> "스프링 종료" 프로토 타입 스프링의 3가지 생명주기 콜백 인터페이스(InitalizingBean, DisposableBean) : 옛날 방식 해당 클래스에 InitalizingBean, DisposableBean인터페이스 implements afterPropertiesSet() : 의존관계 주입이 끝나면 호출되는것 destroy() : 빈이 소멸전 호출 설정 정보에 초기화 메소드, 종료 메소드 지정 : 외부 라이브러리에 적용할때 사용 @Configuration이 붙은 설정 정보에 빈등록시 메소드 지정하여 초기화 콜백, 소멸전 ..
업무 로직 빈 : 컨트롤러, 비지니스 로직이 있는 서비스, 레포지토리 등 비지니스 요구사항을 개발할 때 기술 로직 빈 : 기술적인 문제나 공통 관심사(AOP)를 처리할 때 점점 자동 빈 등록으로 가는 추세이다. 빈이 많아지고 설정 정보를 관리하는 것 자체가 부담이 된다. 자동빈을 사용해도 OCP, DIP를 모두 지킬 수 있기 떄문에 업무 로직에 관해서는 자동을 사용하는 것이 좋다. 기술 로직같은 경우 업무 로직에 비해 수가 적고 광범위하게 영향을 미치고 기술 로직같은 경우 잘 되고 있는지 아닌지 파악하기 어려운 경우가 많기 때문에 수동빈을 사용해서 명확하게 나타내는 것이 좋다. 또한 비지니스 로직에서 다형성을 적극 활용할 때 수동 등록을 사용해서 한번에 보기 쉽게 하는 것이 좋지만 그래도 자동 빈을 쓰고..
@Autowired를 통한 의존관계 주입 생성자 주입 수정자 주입(setter 주입) 필드 주입 일반 메서드 주입 생성자 주입 - 생성자 호출시점에 1번만 호출되는 것이 보장 - 불변, 필수 의존관계에 사용 - 해당 class가 빈으로 등록되어 있고 생성자가 한개 있을때 @Autowired 생략 가능 @Component public class MemberServiceImpl implements MemberService{ private final MemberRepository memberRepository; @Autowired public MemberServiceImpl(MemberRepository memberRepository) { this.memberRepository = memberRepositor..
ComponentScan을 통해서 Component 어노테이션이 붙은 객체들을 스프링 컨테이너에 스프링 빈으로 등록하게 된다. ( ComponentScan은 스프링 부트를 시작시키는 메인 메소드의 @SpringBootApplication 어노테이션을 까보면 상단에 걸려있다. 즉, 메인 메소드의 패키지부터 스캔한다. ) ( 어노테이션은 상속이 안됨 근데 어떻게 이식하냐? 자바 언어가 지원하는 것이아니라 스프링이 지원하는 것임 ) ComponentScan시 같은 이름이 여러개가 있을때 무엇을 스프링 컨테이너에 저장하는가? - 자동 빈 등록 vs 자동 빈 등록 : 오류 -> 예외 - 수동 빈 등록 vs 자동 빈 등록 : 수동 빈 등록이 우선권을 가진다. 근데 최근 스프링 부트는 기본적으로 오류가 나도록 바뀜 ..
1. 스프링 컨테이너 생성 ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class); ApplicationContext를 스프링 컨테이너라고 한다. new AnnotationConfigApplicationContext를 사용하여 어노테이션 기반으로 설정된 class를 기반으로 스프링 컨테이너를 만든다. AppConfig는 객체를 생성하는 class이다. 어노테이션으로 configuration과 빈을 설정해준다. @Configuration public class AppConfig { @Bean public MemberService memberService(){ return new MemberS..