1) 특징
Record Entity와 관련된 작업을 수행한다.
Record Entity 내부에 들어갈 만한 비지니스 로직을 Record Service에서 작성하면 된다.
이렇게 하기 위해서 Record Entity의 모든 Field에 Setter를 열어 두었고 Record Service에서만 Record Entity를 핸들링 한다.
다른 Service에서 Record Entity를 핸들링 하고싶으면 Record Entity의 Setter를 직접 사용하는 것이 아닌, Record Service를 통해 Record Entity를 핸들링 한다.
2) 구현 방법에 대한 생각
Record Entity 내부에 비지니스 로직이 존재한다고 하더라도, Record Service가 아닌 다른 Service에서 Record를 핸들링 하도록 하므로 비지니스 로직을 Entity 내부로 캡슐화 하지 않았다.
즉, 비지니스 로직을 Entity 내부로 캡슐화 한다고 하더라도 어차피 여러 곳에서 사용되는 것이 아닌 Record Service에서만 사용되므로 Enitity 내부로 캡슐화 할 필요가 없다고 판단했다. 오히려 캡슐화하는 경우 비지니스 로직이 어떻게 구현되어있는지 한눈에 안 들어온다.
다만, 비슷하게 Record Entity 내부로 캡슐화 했을 비지니스 로직이 Record Service로 위치한다. 따라서 외부에서 Entity를 다룰 때는 Record Service를 통해 Record Entity를 핸들링 하게 된다.
이렇게 구현하는 경우 Record Service를 사용하는 다른 Service가 필요해 진다.
TimeLog Service
1) 특징
TimeLog Service 또한 Record Service와 마찬가지로 TimeLog Entity를 핸들링 하는 역할을 한다.
RecordTime Service
1) 특징
RecordTime Service를 만들어 Record Service와 TimeLog Service를 사용해 Record와 TimeLog를 핸들링 하고 두 Entity의 연관관계를 설정 및 비지니스 로직을 수행한다.
2) 구현 방법에 대한 생각
Record 와 TimeLog는 서로 1:N 관계이다. 이러한 관계를 설정하는 것을 Record Service에서 하려고 하면, Record Service에서 TimeLog Entity까지 핸들링 해야 하므로 이렇게 구현하는 경우라면 Entity 내부에 비지니스 로직을 위치시키는 것이 더 나은 선택일 수 있다.
하지만 이렇게 개발을 진행하는 경우 어떤 로직은 TimeService에서 진행해야 하는 경우가 존재하고 그러면 Time Service에서 TimeLog Entity 뿐만 아니라 Record Entity 까지 핸들링 해야 하는 경우가 발생한다.
따라서, Record Service에서도 Record와 TimeLog Entity를 핸들링하고 TimeLog Service에서도 두 Entity를 핸들링 하게 되는 스파게티 코드가 만들어진다.
고민하고 배웠던 부분
Q) JPA의 기능을 충분히 활용하면 객체 그래프를 한번에 조회할 수 있는데 따로따로 객체를 조회해 와서 RecordTimeService에서 객체를 연결 시킨 후(Join) 사용하는가?
위 고민은 결국 DB에서 Join을 해올 것인가 아니면 서버에서 Join을 할 것인가의 고민이라고 볼 수 있다.
나는 다음과 같은 이유로 서버에서 Join하기로 결정했다.
의사 결정에서 중요하게 고려되어야 하는 부분은 어떤 방법이 DB를 덜 바쁘게 만들 것인가 이다.
테이블이 5개가 존재한다고 생각해보자.
한번에 5개의 테이블을 Join하는 쿼리 작성
쿼리 5번을 통해 객체 조회 후 서버에서 Join해서 사용
첫 번째 이유
하나의 테이블에서 where 조건을 통해 데이터를 가져오는 것은 Index만 잘 설정되어있으면 빠르다.
물론 쿼리를 5번 날려야 하지만, 어차피 Join을 하기 위해서도 5개의 테이블을 DB가 살펴봐야 한다.
따라서, 2번의 방법을 선택했다.
두 번째 이유
디버깅을 해야하는 경우를 고려해보자.
1번의 경우 내가 작성한 복잡한 쿼리가 어떻게 동작하는지 디버깅 하는 것이 불가능하다.
2번의 경우 JPA가 만들어주는 간단한 쿼리를 사용하므로 나의 비지니스 로직만 디버깅 하면 된다.
즉 1번과 다르게 디버깅이 가능하다.
RecordService
1) 특징 Record Entity와 관련된 작업을 수행한다. Record Entity 내부에 들어갈 만한 비지니스 로직을 Record Service에서 작성하면 된다. 이렇게 하기 위해서 Record Entity의 모든 Field에 Setter를 열어 두었고 Record Service에서만 Record Entity를 핸들링 한다.
다른 Service에서 Record Entity를 핸들링 하고싶으면 Record Entity의 Setter를 직접 사용하는 것이 아닌, Record Service를 통해 Record Entity를 핸들링 한다.
2) 구현 방법에 대한 생각 Record Entity 내부에 비지니스 로직이 존재한다고 하더라도, Record Service가 아닌 다른 Service에서 Record를 핸들링 하도록 하므로 비지니스 로직을 Entity 내부로 캡슐화 하지 않았다.
즉, 비지니스 로직을 Entity 내부로 캡슐화 한다고 하더라도 어차피 여러 곳에서 사용되는 것이 아닌 Record Service에서만 사용되므로 Enitity 내부로 캡슐화 할 필요가 없다고 판단했다. 오히려 캡슐화하는 경우 비지니스 로직이 어떻게 구현되어있는지 한눈에 안 들어온다.
다만, 비슷하게 Record Entity 내부로 캡슐화 했을 비지니스 로직이 Record Service로 위치한다. 따라서 외부에서 Entity를 다룰 때는 Record Service를 통해 Record Entity를 핸들링 하게 된다.
이렇게 구현하는 경우 Record Service를 사용하는 다른 Service가 필요해 진다.
TimeLog Service
1) 특징 TimeLog Service 또한 Record Service와 마찬가지로 TimeLog Entity를 핸들링 하는 역할을 한다.
RecordTime Service
1) 특징 RecordTime Service를 만들어 Record Service와 TimeLog Service를 사용해 Record와 TimeLog를 핸들링 하고 두 Entity의 연관관계를 설정 및 비지니스 로직을 수행한다.
2) 구현 방법에 대한 생각 Record 와 TimeLog는 서로 1:N 관계이다. 이러한 관계를 설정하는 것을 Record Service에서 하려고 하면, Record Service에서 TimeLog Entity까지 핸들링 해야 하므로 이렇게 구현하는 경우라면 Entity 내부에 비지니스 로직을 위치시키는 것이 더 나은 선택일 수 있다.
하지만 이렇게 개발을 진행하는 경우 어떤 로직은 TimeService에서 진행해야 하는 경우가 존재하고 그러면 Time Service에서 TimeLog Entity 뿐만 아니라 Record Entity 까지 핸들링 해야 하는 경우가 발생한다. 따라서, Record Service에서도 Record와 TimeLog Entity를 핸들링하고 TimeLog Service에서도 두 Entity를 핸들링 하게 되는 스파게티 코드가 만들어진다.
고민하고 배웠던 부분
위 고민은 결국 DB에서 Join을 해올 것인가 아니면 서버에서 Join을 할 것인가의 고민이라고 볼 수 있다. 나는 다음과 같은 이유로 서버에서 Join하기로 결정했다.
의사 결정에서 중요하게 고려되어야 하는 부분은 어떤 방법이 DB를 덜 바쁘게 만들 것인가 이다.
테이블이 5개가 존재한다고 생각해보자.
첫 번째 이유 하나의 테이블에서
where조건을 통해 데이터를 가져오는 것은 Index만 잘 설정되어있으면 빠르다. 물론 쿼리를 5번 날려야 하지만, 어차피 Join을 하기 위해서도 5개의 테이블을 DB가 살펴봐야 한다.따라서, 2번의 방법을 선택했다.
두 번째 이유 디버깅을 해야하는 경우를 고려해보자. 1번의 경우 내가 작성한 복잡한 쿼리가 어떻게 동작하는지 디버깅 하는 것이 불가능하다. 2번의 경우 JPA가 만들어주는 간단한 쿼리를 사용하므로 나의 비지니스 로직만 디버깅 하면 된다. 즉 1번과 다르게 디버깅이 가능하다.
따라서, 2번의 방법을 선택했다.