Today's Dev Notes(2018-12-31)

안녕하세요, Brad입니다. 오늘 공부한 내용 정리해볼게요.

 

객체지향 프로그래밍과 데이터베이스

• 자바 객체 1개와 DB테이블 1개와 매칭이 된다면 객체지향적인지 의심해봐야 합니다.

  • 테이블 1개당 여러 개의 자바 객체가 매칭이 될 수 있어야 합니다.

  • 해결방안

    • 일급 콜렉션 적용

      • 클래스에 인스턴스 변수로 하나의 콜렉션만 있는 것이 '일급 콜 렉션'입니다.
      • @Embeddable : 어디에 들어갈 수 있는 객체라는 표시입니다.
      • @Embedded : 들어갈 곳을 말합니다.
      • 이 안의 로직을 써넣을 수 있습니다.
      • 일급 콜렉션 적용을 통해 하나의 Entity 안에 복잡도가 훨씬 줄어들 수 있습니다.

    도메인 객체가 많아지면 어떻게 패키지 분리해야할까요?

    qna, user 또는 history 패키지를 만들어 이 안에서 관리할 수 있습니다. 하나의 객체당 하나의 패키지를 만드는 것이 아니라 기능별 또는 성격이 같은 객체들만 묶어서 패키지 안에 넣어야 합니다.

• equalsTitleAndContents() 리팩토링

  • 이처럼 하나처럼 뭉쳐다니는 속성들에 대해 클래스를 분리하여 QuestionBody 클래스로 만들어 임베디드 속성을 이용할 수 있습니다.
  • 이렇게 하면 또 장점은 생성자에 쓰였던 많은 인자의 수를 줄일 수 있습니다!
  • QuestionBody 가 생긴 덕분에 equalsTitleAndContents() 을 QuestionBody 안에 equals() 를 통해 사용할 수 있습니다.
  • 이 속성을 사용하는 로직도 이 안에서 구현할 수 있습니다.

• 객체내 메서드가 해당 인스턴스 변수를 100% 사용하는 것이 가장 객체지향적이라고 할 수 있습니다(100% 아니라면 클래스 분리하는 것을 고려할 수 있습니다)

• 이런 식으로 도메인 객체 내 계속 분리를 통해 로직을 도메인 안에 넣고 서비스 레이어을 경량화하는 것이 좋습니다!

 

 

Q & A

• 세션에 어떤 정보들을 담아야 할까요?

  • 세션도 메모리를 잡아먹기 때문에 다 담아두면 좋지 않습니다.
  • 1000명이 5byte의 세션을 가지고 있다면 5000byte
  • 세션에는 진짜 필요한 최소한의 데이터만 가지고 있어야 합니다!
  • 그런데 너무 최소한의 데이터를 남기면 매번 DB로 요청을 보내야 하기 때문에 그것도 성능상에 좋지 않습니다.
  • 매 요청에 대해 보여줘야 하는 정보(예를들어 name)가 있다면 그건 Session에 관리하는 것이 좋습니다.
  • 예를들어 User 의 경우 id, userId, name 정도가 될 수 있겠죠. 이 경우 SessionUser 클래스를 만들고 이 객체를 세션으로 관리하는 것이 좋은 방법입니다.
  • Entity객체 전체를 모두 Session에 담는 것은 좋은 방법이 아닙니다.

• 세션값 테스트할 수 있을까요?

  • 스프링의 MockHttpSession 객체를 이용하여 가짜 데이터를 만들어 테스트 할 수 있습니다.
  • 실제 세션값을 테스트하는 것은 힘듭니다.

• 세션값 변동이 어떻게 작동하는 걸까요?

  • reference 참조로 변동가능합니다.

• Entity의 상속할 경우는 어떻게 할 수 있을까요?

  • 부모의 클래스를 @Entity 가 아니라 @MappedSuperclass 를 통해 설정할 수 있습니다.
  • AbstractEntity 참고합니다.

• @EntityListeners(AuditingEntityListener.class) 는 뭘까요?

  • 이 애노테이션을 통해 @CreatedDate 또는 @LastModifiedDate 를 사용할 수 있습니다.
  • 시간 관리 데이터에 많이 사용됩니다.
  • audit(감사, 조사) 이라는 말로 알 수 있듯이 어떤 history을 남기는 것이라는 것을 짐작할 수 있습니다.
  • DeleteHistory 처럼 기능상 상관은 없지만 나중에 문제가 생겼을 때 필요한 것입니다.

• API 수준은 어디까지 만들어야 할까요?

  • 사실 CRUD를 다 만들 필요도 없습니다!(Delete는 위험) 너무 많이 만들면 데이터를 다 노출되는 것이기 때문입니다.
  • 개발, 유지보수 비용도 들기 때문에 서비스에 딱 필요한 것만 만드는 것이 좋습니다.
  • 물론 facebook이나 Github처럼 여러 API를 만들어 개발자들이 사용할 수 있도록 할 수도 있습니다.

• Post 방식으로 보내고 body부분을 encoding할 때 다음 3가지 형태의 용도는 무엇일까요?

  • x-www-form-urlencoded

    • key-value 형태로 전달되게 됩니다.

  • multipart/form-data 는 언제 꼭 사용할까요?

    • 파일 보낼 때 사용됩니다.
    • 파일은 크기가 클 수 있기 때문에 이것을 사용하게 되면 body를 쪼개서 보내게 됩니다.
    • 서버 입장에서는 이 타입을 보고 조금씩 잘라 받게 되는 것을 알게됩니다.

  • plain/text

    • 잘 안 사용됩니다.

• @RestController 와 @Controller

  • @RestController = @Controller + @ResponseBody

• Builder Pattern

  • Builder Pattern은 보통 Entity 안에 static class로 주로 만듭니다.
  • 생성자를 줄이고 테스터 데이터를 만드는 방법으로 사용될 수도 있습니다.

• 생성자 줄이기

  • 무분별한 생성자를 만들기 보단 꼭 필요한 것들에 한해 만드는 것이 좋습니다.
  • 테스트 데이터를 위해 생성자가 여러개가 필요하다면 여러 속성값을 갖는 생성자를 만든 다음 default 값을 따로 정해 안 쓰는 속성을 그 default데이터를 통해 채워넣어 만들 수 있습니다.

 

 

적용해보고 싶은 부분

세션객체 만들고 이걸로 세션값에 관리하기

관련된 속성들 하나의 클래스로 분리하기, QuestionBody 와 같이 적용합니다.