학습회고
서비스로 비즈니스를 처리하는 방식을 트랜잭션 스크립트라 한다.
만약 서비스 영역에서 비즈니스 처리 메소드를 만든다면
도메인 객체는 그저 데이터 덩어리에 불과함.
서비스는 그냥 트랜잭션과 도메인 간의 순서만 보장해야한다 함.
왜그런가? 생각해봤는데
확실히 각각의 도메인 객체가 자신의 비즈니스 메소드를
서비스 영역에서 다룬다면 굉장히 난잡해질 수 있다고 생각된다.
서비스 영역의 클래스가 지는 책임이 많아질테고,
만약 어떤 메소드를 만드는데 그것과 비슷한 동작을
여러 도메인이 중복되게 사용해야한다면
서비스 영역의 클래스가 중복된 동작의 메소드를 여러개 만들 수도 있을수도 있겠다싶다.
의외로 스프링에서 Bean을 주입 할 때
@Autowired를 권장하지 않는다는 얘기를 책에서 봤다.
스프링에서 의존관계 주입 DI 3가지
Field Injection, Setter Based Injection, Constructor Based Injection 가 있는데
보통 생성자 주입을 추천하다
- NullPointerException 을 방지할 수 있다.
- 주입받을 필드를 final 로 선언 가능하다.
는 장점 외에 - 객체 생성시점에서 순환참조가 발생하는 것을 확인할 수 있다.
컨테이너가 빈을 생성하는 시점에서 객체생성에 사이클관계가 생기기 때문이라는 듯.
더 자세한 내용은 구글링해서 공부.
기존에 쓰던 요청 DTO에 @setter를 사용했었는데
혹시 dto에도 setter 말고 builder패턴을 쓰는게 안전할까?싶어서
찾아봤는데
생성자를 쓰는 DTO의 경우 도중에 setter로 인해 데이터 변질이 우려되기 때문에
불변성을 위해 빌더를 쓰는게 낫다는 의견을 보았다.
갑자기 DB관련 오류가 많아졌다.
application.properties 설정과 관련 있는 것 같다.
내일은 application.properties 설정들을 공부하고,
재정립해야겠다.
되새김
세션 무효화
[1], [2]
MVC패턴에 대한 소개 및 예시 코드
[1]
트랜잭션 스크립트 문제점
[1], [2]
@Transactional
[1]
@Transactional 사용시 주의점
[1], [2]
DI 의존관계
[1]
dto에도 setter 말고 builder
[1]
ddl-auto 옵션)운영 장비에서는 절대 crate, create-drop, update 사용하면 안된다.
[1]
