어느정도 진행을 하고 서버 코드를 뒤돌아보니, 너무 route 부분에 코드들이 집중이 되어 있어 역할별로 코드를 정리하고 분리해 가독성을 높으고, 또 역할에 맞게 코드를 정리해야겠다고 결정이 나 더 늦기전 리팩토링을 하겠다 결심했다.
N-Queens 를 할때 살짝 설명하고, 중간중간 과제에 적용된 것으로 보이는 MVC 패턴은 어떻게 소프트웨어를 개발할 것인지의 디자인 패턴 중 하나로, 특히 사용자와 상호작용을 하는 애플리케이션을 개발할 때 흔히 사용된다.
M(Model): 비지니스 영역의 로직을 처리한다.
뷰(View): 비지니스 영역에 대한 시야, 화면을 담당한다.
컨드롤러(Controller): 사용자의 입력과 흐름을 담당한다.
여기서 비지니스 로직이란 데이터를 생성, 표시, 저장, 변경하는 부분, 즉 데이터를 처리하는 일련의 과정들을 비지니스 로직이라고 한다.
같이 프로젝트를 봐주시는 개발자 분과 상의를 통해 API가 그렇게 많지 않고 시간도 진짜 없는 경우이기에 그냥 route 부분과 controller부분을 합치기로 했고 (추후에 시간이 남으면 가독성과 역할 정리를 위해 나눌 생각도 하고 있다 (해결함!) ) 라우트 안의 비지니스 로직 부분을 DAO와 서비스로 나눠주기로 했다.
확실히 이러한 리팩토링을 통해서 코드의 역할을 나누고 가독성 면에서 훨씬 향상된 점을 볼 수 있었다. 시간이 많이 걸리긴 했지만 MVC 패턴을 적용해서 코드를 정리했다는 점이 보람찼다.
Active Record 패턴으로 접근한다면 모든 쿼리 메소드들과 필요한 CRUD를 엔티티 안에 정의할 수 있다. 엑티브 레코즈 패턴을 사용하면 모델안에서 데이터 베이스 접근이 가능하다는 장점이 있다. 사용방법은 공식 홈페이지를 참조하면 된다. CRUD를 하는 쿼리빌더를 엔티티 안에 컬럼과 같이 생성한다고 생각하면 된다.
Data Mapper 패턴으로 접근한다면 레포지터리 라는 별도의 클래스를 만들어 모든 쿼리 메소드를 정의해준다. 이 레포지토리를 사용해 CRUD사용하기 때문에 엔티티는 칼럼과 관계만을 정의하는 제한적인 역할만을 수행한다. 그래서 데이터베이스에 연결해 접근하는 부분은 다 레포지토리에서 처리한다. 커스텀 레포지터리를 만들어서 사용하면 된다.
일단 큰 차이점은 애플리캐이션을 유지하는데 차이가 있다. 데이터 매퍼 접근법을 사용하면 유지보수에 더 효과적이여서 큰 애플리케이션이고 더 많은 데이터를 다룬다면 더 유리하다. 따로 기능과 데이터베이스를 분리해관리하기에 설계적인 측면에서도 더욱 효과적이고 더 유연하다. 액티브 레코즈 접근법은 아무래도 한 엔티티 안에 다 정의하기 때문에 더욱 간단하고 작은 애플리케이션에 있어 더 효과적이다. 유지보수도 더 쉬울 수 밖에 없다.
결국 도메인 로직이 복잡하다면 Data Mapper를, 아니라면 Active Record를 사용하면 된다.
우리 프로젝트 같은 경우는 일단 로직이 매우 길고 다양하기 때문에, 그리고 장기적으로 봤을 때 많은 데이터가 저장되어 처리해야 하기 때문에 Data Mapper를 도입해서 사용하는게 더욱 좋을 것이라 생각했다.
이런식으로 캣태그라는 EntityRepository를 만들어 준 후 CatTag 레포지토리를 연결해주어서 이 안에 필요한 CRUD들을 만들어 준다. 이렇게 클래스를 만들어 준 후 export를 해준다면 서비스에서 필요한 DAO를 선정해 사용한다.
const catTagRepository = () => getCustomRepository(CatTagRepository);
그리고 서비스 파일에서는 만들어놓은 repository를 가져와야 하기 때문에 (DB와 연결) 위 코드를 실행해줘야 레포지토리에 있는 메소드들을 사용할 수 있다.
데이터 매퍼를 사용하면 체감상 못 느끼겠지만 설계면에서 더욱 유리하고 유지보수에 도움이 된다는 장점이 있기에 패턴을 도입했고 성공적으로 코드가 잘 실행된다는 점이 매우 만족스럽다.
참고 - 생활코딩