Hayden's Archive
[자바/Java] CRUD 본문
- 데이터베이스는 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()