madvirus0123

언어나 스프링 같은 문제라기 보다는, 경험과 관련이 있습니다. 개발 경험을 좀 더 하고 나서 다시 들어보시면 와 닿는 내용이 더 늘어날 겁니다.

강의 수준 질문드려요

네, 비슷합니다. 조금 더 말하면 외부나 하위 클래스에서 접근할 수 있는 메소드에 가깝습니다.

6분 26초에 말하는 객체의 안에 있는 프로시저란 객체의 메서드를 말하는건가요?

데이터를 구조화한 것에 관련 데이터를 조작하는 기능을 추가하는 것도 외부에 제공하는 기능으로 정의하는 게 맞습니다. 보통 DB에서부터 구현이 출발할 때 말씀하신 것처럼 데이터 구조를 먼저 생각하고 그 다음에 기능을 도출하게 되죠.중요한 점은 캡슐화를 최대한 지키면 됩니다.실제 개발을 하다보면 당연히 아래 두 관점을 왔다 갔다 하게 됩니다.* 외부 관점에서 사용할 기능 * 구현 관점에서 데이터/구조일방적으로 한 방향으로 설계가 진행되기 보다는 두 관점을 오가면서 설계가 완성되어 간다고 보면 됩니다.

객체의 기능보다 속성을 먼저 추출하는 것에 대해 의견을 여쭤보고 싶습니다.

안녕하세요. 아래 코드를 보죠.<pre class="hljs"><code>public class SomeService {
 private SmsSender sender = new SmsSender();

 public void doSome() {
 ... // DB 연동 등 작업
 sender.send(to, msg);
 }
}</code></pre>이 코드에서 SomeService는 SmsSender를 new로 생성해서 사용하고 있습니다. 즉 SomeService가 SmsSender를 의존하고 있죠.SMS가 아니라 알림톡으로 메시지를 보내라고 요구사항이 변경되고 알림톡 발송 기능은 AlimtalkSender에 구현되어 있다고 가정하면, SmsSender 대신에 AlimtalkSender를 사용하도록 기존 코드를 변경해야 할 겁니다.<pre class="hljs"><code>public class SomeService {
 private AlimtalkSender sender = new AlimtalkSender(); // <-- 코드 바뀜

 public void doSome() {
 ... // DB 연동 등 작업
 sender.send(to, msg);
 }
}</code></pre>즉 위 코드처럼 SmsSender를 new로 생성해서 사용(의존)하는 SomeService 코드가 AlimtalkSender를 생성하도록 바뀌는 거죠.

의존 대상 객체를 직접 생성했을 때 문제에 대해 질문드립니다.

개념적으로 하나인 대상을 매핑하고 싶을 때 사용합니다. 예를 들어 객관식 문제는 질문과 보기로 구성되어 있는데 이때 질문과 보기를 두 테이블에 나눠서 저장할 수 있을 겁니다. 여기서 '객관식 문제'를 DB에 매핑할 때 보기를 콜렉션을 사용해서 매핑할 수 있습니다.

1:N 매핑과 해당 방식 차이가 뭔가요?

@OneToOne+@JoinColum 설정을 하기 위해서 user_email 칼럼에 대응하는 칼럼을 설정할 필요는 없습니다.

JoinColumn 질문

1:N은 엔티티와 엔티티 간 매핑입니다.엔티티 간 매핑이므로 서로 독립적인 라이프사이클을 갖습니다.예를 들어, A와 B가 1:N 관계일 때 A를 삭제한다고 해서 A와 연관된 모든 B가 삭제되지는 않죠.물론 엔티티 간 연관에 영속성 전파 설정을 하면 같이 삭제되지만요.&nbsp;반면에 값 콜렉션은 엔티티와 값의 관계입니다.즉 엔티티를 삭제하면 엔티티에 속한 값도 함께 삭제됩니다.또한 값만 따로 조회할 수 없습니다. 엔티티를 조회해야 엔티티에 속한 값도 같이 조회가 되지요.

@Embedded로 매핑할 대상이 엔티티와 같은 테이블이 아닌 다른 테이블인 경우에, 조인할 테이블을 알려주기 위해서 @SecondaryTable을 이용하는데요,이해가 안 된다고 하는 부분이 @SecondaryTable 자체를 말씀하시는 걸까요? 아니면 @Embeddable을 다른 테이블로 매핑할 일이 있느냐를 말씀하시는 걸까요?&nbsp;

7강에서 SecondaryTable을 왜 사용하지 모르겠습니다.

@Embeddable은 값(Value)를 표현하는 모델을 매핑할 때 주로 사용합니다. 실무에서 @Embeddable을 잘 활용할수록 모델이 풍부해지죠. 이 값 모델을 잘 활용한다는 것은 그 만큼 조직/개인의 모델 방식/역량하고도 연결이 됩니다.그래서 조직/개인이 모델을 설계 결과물에 따라 사용하는 비율이 달라집니다.&nbsp;동일한 테이블을 밸류로도, 엔티티로도 매핑한다는 것은 누군가에게는 엔티티인데, 누군가에는 밸류라는 얘기로 들립니다.명령 모델과 조회 모델을 나눠서 구현하면 그럴 가능성이 있다고 생각합니다(CQRS).명령 모델에서는 엔티티엔데, 조회 모델에서는 밸류라던가 하는 식으로요.&nbsp;

JPA 실무 @Entity을 @Embeddable 대체하는 경우가 많은가요?

우선 개인적으로는 너무 완벽하게 JPA에 대한 의존을 제거하려고 노력하지 않아도 된다고 생각합니다. 큰 틀에서 구조를 깨뜨리지 않는 선에서 JPA에 의존하는 정도는 허용해도 괜찮다고 봅니다.Order와 OrderJpaEntity를 꼭 분리해야 한다면 Order를 인터페이스나 추상 클래스로 만들고 OrderJpaEntity는 Order를 상속받는 구조를 가져가는 방법이 있습니다. 이때<ul><li>리포지토리는 save나 find에서 Order 타입을 사용하고</li><li>리포지토리 인터페이스를 구현한 클래스는 내부적으로 OrderJpaEntity를 사용합니다. </li></ul>유사한 방식으로 Order 인터페이스/추상 클래스가 있고, 이 Order를 상속받은 클래스가 내부에 필드로 JPA용 엔티티를 필드로 가져서 변경이 발생하면 전파하는 방법을 사용할 수도 있을 듯 합니다.하지만 이렇게 해서 얻게 되는 실질적인 이점이 무엇이 있는지는 한 번 고민해 볼 필요가 있습니다.

madvirus0123

Bài viết