안녕하세요, EF Core를 공부하고 있습니다.
현재 진행중인 프로젝트가 백엔드, 프론트앤드로 나뉘어져 있고, 백엔드에서는 Web API를 제공하고, 프론트엔드에서는 API를 통해서만 데이터를 보여줄 수 있게 하려고 합니다.
이때 백앤드 개발과 프론트앤드 개발을 완전히 독립적으로 분리하여 개발한다고 했을 때 데이터를 주고받는 클래스들은 어디에서 관리하게 되나요?
제가 생각했을 때의 방법은 두가지가 있습니다.
첫번째 방법은 Entity에 변경이 발생할 시 다른 프로젝트에서 똑같이 수정해줘야되는 문제가 있습니다.
두번째 방법은 서로 독립적인 관계가 아니게 됩니다.
실무에서는 어떤 구조를 사용하나요?
말씀하신 것 처럼, Entity를 다른 레이어에서도 공용으로 쓰는 것은 그리 좋은 아이디어가 아니었습니다.
사실, 처음 배울 때 예제 코드들이 전무 Entity 와 Domain 을 구분하지 않고 사용하는 바람에, 공용으로 쓰는 게 맞는 것처럼 생각했죠.
실제로 공용으로 사용하면, 처음에는 코드가 쭉쭉 나가기 때문에 좋아 보이는데, 도메인 로직이 변경될 때마다 저장 레이어에 영향을 줘서 코드 관리 범위가 기하급수적으로 늘어나는 폐단이 있었습니다.
예를 들어, 한 로직의 리펙토링이 데이터 베이스 변경을 유발할 경우, 이는 또 다른 로직과 충돌을 일으키기는 경우 잦았습니다.
그래서, 현재는 아래와 같은 프로젝트 구조가 일상화된 것 같습니다.
프론트 엔드 → 백엔드 { Dto → Domain } → 저장 레이어 { DbContext → Entity }
( → : 의존성 )
EF 코어를 사용할 때, Entity 클래스는 테이블 디자인 용도 외에는 쓰지 않는다가 원칙입니다.
FE단 에서 Entity클래스모델을 알아야할 이유가 없을거같습니다…
그렇기 때문에 DTO클래스라는 모델을 만들어 통신합니다.
이때 DTOModel 변수와 EntityModel은 Mapping라이브러리를 통해 처리합니다.
EF의 엔터티 그대로 웹 API로 노출하는 것은 불필요한 관계나 정보가 그대로 전달되기 때문에 지양하는 것이 좋지만 프로젝트 초기 단계에서 그렇게 진행하고 차후 별도 DTO로 구성하는 것이 전략이 될 수 있습니다.
그리고 서버와 클라이언트의 DTO를 맞추는 방법은 Swagger 메타 JSON을 이용해서 자동으로 클라이언트용을 생성하는 것을 추천합니다.
이후 엔터티와 DTO의 형태 관리는 별도의 정책으로 유지하는 것이 좋습니다.