백엔드, 프론트엔드 보통 구현 방식 어떤식으로 진행함?
백엔드에서 API 넘겨줄 때 말 그대로 DB의 엔티티 , 컬럼 뭐 결과의 Result의 대한 Array 정도만 주고
프론트엔드에서 받은 엔티티를 프론트엔드 내부 어떤 뭐 객체나 클래스같은거로
자동적으로 뷰모델로 만들어서
그 인스턴스들을 엘리먼트 데이터들 업데이팅해서 보여주는거임?
아니면 백엔드 API 넘겨줄 때 부터 DB의 엔티티를 뽑는데
이제 뷰모델까지 완성시켜서
그 뷰모델을 넘기고 프론트엔트에서는
뷰모델 받은거 그 자체를 그냥 엘리먼트 추가해서 업데이팅 보여줌?
플레이가 머임
변태심?
당연히 뷰모델에 맞는 스펙대로 뿌려줌. 엔티티 질의 결과 그대로 뿌려주면 여러 문제가 발생할 수 있음.
1. 새로운 BL을 추가하면서 테이블에 컬럼을 추가했는데, 기존 API의 스펙이 바뀜
2. 닉네임,이메일만 필요한데 만약 그 테이블에 암호, 주소, 휴대전화번호까지 다 있다면 ? 불필요한 데이터까지 보내는거라 존나 비효율적.
2번은 상식이지만 1번때문에 API는 한번 만들어놓고 최대한 안건들이게끔 개발함
그럼 (콘트롤러, 서비스, 엔티티, 레파지토리, 뷰모델)로 묶음
??
예를들어 1:1 테이블 매핑된 Dog레파지토리가 있으면 원래 이 디비의 모든 컬럼값 Dog엔티티가 있음. 근데 서비스에서 레파지토리 셀렉팅해서 받은 테이터는 이제 어떤 뷰모델에 대한 클래스임 이런느낌?
음 그건 뭐 선택이긴한데 뷰모델이 프론트로 뿌려주는 스펙을 의미하는거임?
controller repository service entity 기본으로 들어가고 API 서버면 service -> front단으로 넘겨주는 Dto랑 front단에서 요청 들어올때 입력 받는 Dto(보통 Form Data라고 부름)
front단에서 넘어오는 Dto는 굳이 필요없긴한데 전부다 체계적으로 개발해두면 관리하기 용이해짐.
ㄴ ㅇㅇ
디비에서 셀렉트 할때부터 그 결과 엔티티를 디비의 컬럼 엔티티로 받는게 아니네 그럼
셀렉트할때 컬럼 명시적으로 지정해주는건 그냥 선택사항임. Dto만 잘 만들어두면 뭐 어떻게 해도 성능이나 보안에는 차이 없다
노드 기준이라 너가 뭐 말하는지 확실치않네 데이터 모델 엔티티 클래스 말한 ㄴ거 같은데. 아 타잎스크십트로 하나부터 끝까지 다 신경써줘야하네 주입부터 그냥 아주 다 ㅈ같다 이래서 편해서 스프링쓰놰