여기서 중요하게 볼거는 repository는 dao임.
이름 ㅄ같긴 해서 dao로 바꾸긴할건데
어찌되었던 테이블이랑 1:1매핑된 객체임.
service도 마찬가지로 그 repository에서 결과 Rows를 지지고 갈기고 해서 가공하면서 비지니스 로직 수행
schema는 그냥 그 테이블의 컬럼 Entity Interface 있고
그리고 클라이언트 입장에서의 뷰모델 (DTO) 들도 여기에 다 선언해둠
사실 이게 구조 맞는지는ㅁ ㅗ르겠음 ㅇㅇ
그러면 컨트롤러인데 컨트롤러도 그러면 사실
GET: /memo 이런식으로 와야하잖아?
근데 이런식으로 오는게 맞긴함
다만 업무적인 가장 더 큰 요소가 PATH 앞에 붙어
admin/memo, admin/user
order/user
이런식으로 ㅇㅇ
그래서 컨트롤러 레이어와 테이블 1:1 매핑된 서비스, 레파지토리의 레이어를 강제로 분리시킴.
Service가 Controller랑 묶여야 할거같긴한데
일단 repository랑 묶었음
그리고 1, 2의 차이는 디렉토리 구성밖에 없음
ㄱㅊ음?
더 좋은 방안 모색중인데 의견 바람
뭐야 자바가 아닌데?
내가 노드써서 ㅇㅇ 그래서 스프링에서 쓰던 구조나 몇가지 레이어 개념 가져다가 조금만 쓰려는데 구조 의견 부탁함
난 노드 모름 ㅅㄱ
입금해라
제발 꽁짜로 알려주세요 ㅠㅠ
2번이 맞음
1,2 구조는 장단점 있고 오키 검색해도 ㄹㅇ 지들 맘대로인데 뭔가 방식이 있냐??
그리고 컨트롤러만 레이어 나누고 서비스 레파 하나로 둔건 어때보임? 난 뭔가 애매해보이는데