rest 설계를 이렇게했어
scheduler / 뭔가 일정 매니지먼트 하는 그런거
admin / 관리자의 업무 자체
statistics / 통계 기능 몰빵
그래서 controller 파일은 3개야.
scheduleController,
adminController,
statisticsController
디비 테이블은 대충 몇개있음.
user, option, product, history, reservation
얘낸 다 각각 service, dao, vo가 한쌍으로 존재함.
근데 이게 짜다보니까 스케쥴러에서도 어드민에서도 user 디비 데이터가 필요할때가 있음
그래서 schedulerController, adminController 둘다 userService에 접근이 가능함
걍 콘트롤러가 자기 꼴리는 서비스 알아서 쓰도록 하는 개념
그럼 업무 도메인이 달라도 내부 디비쫄 로직은 동일하거나 혹은 비슷한거 쓰니까 중복 제거되는 느낌임
구조 어때보임 ㄱㅊ음?
말은 그럴싸하지 코드 내놔 -리누스 토발즈-
이 댓글은 게시물 작성자가 삭제하였습니다.
해당 댓글은 삭제되었습니다.
도메인 거치고나면 뒤에 테이블 네임오잖아 컨트롤러를 내부로 다시 나눠서 서비스랑도 1:1 관계로 만들까? 고민중임
admin/users/10 , admin/options?~~~ 뭐 이런식으로 다 있다보니까 근데 이중으로 하면 더 ㅂㅅ이긴 하겠네
저렇게 안짜는 새끼들도 있노?
스프링 책만 봐도 저게 기본 베이스인데
물론 api 설계 자체가 테이블로 오는 경우가 많고 controller도 1:1 매핑되는 경우가 있긴함 작은 서비스면