Dto를 다 끌고 오지 말라고 했는데
대안은????
Dto → . toEntity()
만약에 서비스로직에서 new Product(request, sellerId)
이면 new Product(request,sellerId) 를 담게 되면
Entity 안 까지 불필요하게 request(Dto)를 끌고 가는것은 결합도는 떨어지고 의존성이 높아져 좋지 않다.
🔑 대안으로
💡Dto → Entity 로 만들어서 주면 좋다
Entity class 에서 toEntity 및 builder 이용
builder로 하면 좋은이유는 파라미터 값들이 많아지게되면 타입도 겹치게 될텐데
생성자의 경우
타입으로 분류하기 때문에 값들이 섞일수 있다.
그렇기 때문에 builer로 셋하여 가독성 및 안정성을 보장할 수 있다.
💡 Entity에 메소드 만드는게 setter없이 객체지향적 관리에 좋고, 서비스 가독성도 좋음
엔티티가 가지고 있는 속성값으로 변경해준다면 셋도 필요없고 유지보수도 좋아진다고 함
💡 save 더블채킹?? 트랜잭션
- 트랜잭션이 달려있으면 save 할 필요가 없지만 보장성? 을 위해 사용할 수 있는데 이건 스타일 ~
- @Transactional( read only )
더치체킹 안해서 효용성 높임
💡 한서비스에서 다른레포들까지 여러레포를 호출한다? 지양해야함 !
@Transactional
public void orderCancelingProcessing(Long orderId, Long sellerId) {
Orders order = orderRepository.findById(orderId).orElseThrow(() -> new CustomException(ExceptionStatus.Order_IS_NOT_EXIST));
User customer = userRepository.findById(order.getCustomerId()).orElseThrow(() -> new CustomException(ExceptionStatus.USER_IS_NOT_EXIST));
Product product = productRepository.findById(order.getProductId()).orElseThrow(() -> new CustomException(ExceptionStatus.Product_IS_NOT_EXIST));
유저서비스 - 프로덕트레포 ( 유저가 상위레벨로 보이는데, 유저서비스에서 프로덕트레포를 많이 쓴다면 유저서비스 말고
프로덕트서비스에 하는게 좋다. )
- order 의 경우 orderrepository,productrepository,userrepository를 다부르게 되는데 직접호출이 지양이면
대안 ?
repository를 직접 호출하는 것보다는 해당 서비스에 메서드를 만들어 서비스를 호출 하는것이
로직 유추 등등 좋다.
개발자꿈나무