Hayden's Archive

[자바/Java] CRUD 본문

Study/Java & Kotlin

[자바/Java] CRUD

_hayden 2020. 4. 16. 10:31

- 데이터베이스는 2차원 구조로 생겼음. 과 열.

  maker price count
product1      
product2      
product3      
...      

DB 테이블의 하나의 행(Low)와 1:1 매핑 되는 게 Instance ===> product1, product2, product3, ...
DB 테이블의 각각의 열(Column)Instance의 Field와 매핑됨 ===> maker, price, count


 

VO Class (VO = Value Object = Domain Object)

- 최종적인 데이터는 DB에 저장되는데 DB가 클라우드에 있을 수도 있고 로컬에 있을 수도 있음. 

- VO 클래스는 직접적인 리소스. 자료. 데이터베이스와 연결지어 생각. 

- VO 객체는 DB와 매핑된다. 나중에 화면단과 연결됨.

- 필드에 값 넣고 값 가져오고 이런 것만 있음. 필드, 생성자, Setter, Getter로 구성.

- 알고리즘(=기능)이 있으면 안 됨! VO에는 자료만 담아야 한다.

 

Service Class (= Manager(Mgr) class)

- VO를 Handling(CRUD + α)하는 게 Service Object인데, 핸들링하기 위해 중요한 게 Service Object에 배열이 만들어져 있어야 한다.

- Service에서 처리한 결과를 Test로 넘김.

- Working Method.

 

Test Class

- 값 집어넣고 메소드 호출하는 역할. Calling Method.

- Service에서 처리한 결과를 받아서 실행하고 출력함.

- Test에 for문 같은 거 다 돌리면 구조를 파악하기 어려움. Calling method와 Working method가 구분되지 않음. -> 확장성이 떨어짐 -> 유지보수성이 떨어짐.

 

(Vaule Object/Domain Object) <- (Serivice) <- (Test)
Product(필드, 생성자/setter) <- ProductStoreService(기능) <- ProductStoreServiceTest(값 넣고 호출) 

Service가 Product를 가지는데, Service Product를 필요로 하므로 Service Product에 의존한다.(아쉬운 건 Service 쪽.) 

마찬가지로 Test가 Service에 의존함. 

결론 : Hasing하는 쪽이 의존함. 이게 바로 Dependencies

 

==> VO Class, Service Class, Test Class는 고정된 이름은 아니다. 사람에 따라 조금씩 다르게 부르기도 한다.


참고1 : https://ko.wikipedia.org/wiki/CRUD
참고2 : https://blog.naver.com/15elly/221856087883


Create - VO 생성 (DB로 치면 한줄 추가.) ===> addEngineer()

Read - VO 가져옴(프로그램에서의 Getter와 같음. 한줄 또는 여러줄 가지고 옴. 혹은 없으면 안 가져옴) ===> findEngineer()

Update - VO 정보 수정 (DB로 치면 한줄 중에 특정 컬럼 정보 수정. 프로그램에서의 Setter와 같음) ===> updateEngineer()

Delete - VO 삭제 (DB로 치면 한줄 삭제) ===> deleteEngineer()