숙제 3

SimpleFormController
– Spring reference
[#M_ more.. | less.. | a form controller that provides even more support when creating a form with a corresponding command object. The SimpleFormController  let’s you specify a command object, a viewname for the form, a viewname for page you want to show the user when form submission has succeeded, and more._M#]- Spring API :: SimpleFormController
– Spring MVC :: p65(84)
– Pro Spring :: p547

CoC
– Convention over Configuration 의 약어로 “설정을 능가하는 규약” 정도의 의미.
http://softwareengineering.vazexqi.com/files/pattern.html
Convention vs Configuration
CoC in Spring MVC

The paradigm mismatch

Hibernate를 공부하는 중인데요. 객체와 Relation간의 어떤 차이들이 있는 것인지 궁금해서 살짝 공부해 봤습니다.

The problem of graularity
=> 알갱의 크기가 달라서 생기는 문제

The problem of subtypes
=> 객체의 상속을 Relation에서 표현하기 위한 문제

The problem of identity
=> 객체와 그에 해당하는 row를 식별하는 문제

Problems relating to associations
=> 객체에서의 reference 연관과 Relation의 외례키를 사용한 연관의 차이

The problem of data navigation
=> DB의 성능을 높이기 위한 join과 persistence 객체의 fetching으로 인한 n+1 slelect 문제

The problem of data navigation

참조 : Java Persistence With Hibernate

객체에서는 . 을 사용해서 다른 객체로 이동하곤 합니다. 하지만 SQL db에서 데이타를 이런식으로 가져오는 것은 효율적이지 않습니다.

db의 성능을 높이는 방법으로 SQL 쿼리 숫자를 줄이는 겁니다. 그래서 연관된 table 간의 join을 이용해서 data를 가져 옵니다.

만약에 Member에 있는 데이타만 관심이 있다면 Select * From member; 이렇게 하면 되겠지만 Member와 Messenger의 데이터에 모두 관심이 있다면 outter join을 이용해서 member를 가져와 두면 나중에 messenger의 데이터를 위해 쿼리를 날릴 필요가 없습니다.

하지만 Object persistence의 경우 객체에 처음 접근 할 때 fetching이라는 기능으로 연관된 객체를 붙여오는 기능을 제공하는데 이것은 각 노드 또는 콜렉션 마다 하나의 쿼리문을 실행하도록 요구하기 때문에 비효율적일 수 있습니다. 이것을 바로 무서운 n+1 selects problem 이라고 한다는 군요.

이 문제에 관해서는 13, 14, 15장에서 Hibernate가 제공해 주는 효율적이면서도 투명한 fetching 기능을 공부할 수 있을 것 같습니다.

Problems relating to associations

참조 : Java Persistence With Hibernate

객체에서는 객체들의 관계를 reference를 사용해서 나타내지만 관계형 DB에서는 외례키로 나타내기 때문에[footnote]이밖에 데이타 무결성을 위해서도 사용된다.[/foonote] 발생하는 문제입니다.

방향성에 대한 차이

  • Object Reference는 고유의 방향성이 있다. 참조 하는 쪽과 참조 되는 쪽이 있다는 말인듯 합니다. 따라서 양방향성을 설정 하려면 두 번 설정해 줘야 합니다.
public class Member{
    private Set<Messenger> messengers;
}

public class Messenger{
    private Member member;
}

  • Foreign key를 사용한 관계는 정해진 방향성이 없다. 임의로 join이나 projection을 사용해서 연관을 맺을 수 있기 때문에 Navigation이 관계형 데이타 모델에 의미가 없다.

관계에 있어서 차이

  • Java에서는 다 : 다 관계를 표현할 수 있다. Java class를 보고 어떤 관계인지 알 수가 없다.
  • DB에서는 항상 1 : 다 또는 1 : 1 관계다. 외례키 정의한 부분을 보면 어떤 관계인지 알 수 있다.

The problem of identity

참조 : Java Persistence With Hibernate

Java에는 두 가지의 동일성에 대한 표현[footnote]Equality를 나타내는 equals()와 Object identity를 나타내는 == 이 있습니다.[/footnote]이 있고 DB에서의 row에 대한 identity는 주키로 나타내기 때문에 발생하는 문제 입니다.[footnote]단순히 동일성 표현 방법의 갯수가 차이 나서 그런 것은 아닙니다.[/footnote]

9.2.2에 보시면 equals()와 hashCode()를 구현할 때 주의할 것들이 나옵니다.

  • equals()와 hashCode()를 테이블의 주키 값의 동일성으로 구현을 하면 transient 객체의 동일성 비교를 할 때 아직 id가 없는 상태이기 때문에 문제가 발생하며..
  • equlas()와 hashCode()를 테이블의 주키를 제외한 다른 모든 속성들의 값으로 구현을 하면 같은 row인데 속성하나가 바꼈다고 다른 row로 인식하거나.. 다른 row인데 값이 같다고 해서 같은 객체로 인식하는 문제가 발생합니다.
  • 그래서 business key를 사용하라는 내용이 있었습니다. 주키는 surrogate key를 사용하는데 둘다 유일한 값을 가지며 차이가 있다면 business key는 어떤 의미가 있는 값(ex. 학번, 주민번호)이 지만 surrogate key는 아무런 의미가 없이 DB에서 식별자 역할 만 한다는 겁니다.

주키를 정할 때 surrogate key로 정하는데 DB를에 row 식별을 위해 만든 속성을 domain model에 표현을 해야하는 건지..? 라는 질문을 던지고 있습니다. 여기에 대해서는 p162쪽 4.2.2에 보시면 Hibernate는 db identity를 application에서 두 가지 방법으로 표현할 수 있다고 합니다.

  • persistence 객체의 식별자 속성의 값으로
  • Session.getIdentifier(Object entity)의 리턴값으로