현재 애플리케이션에서 보관된 사용자(“isArchived”），并且同时处于非活动状态超过一个月（"lastVisitedDate" 字段应早于 new Date() - 1 个月)를 반환해야 하는 API GET 경로 "/inactive-users"를 생성해야 합니다.
계층화된 아키텍처(컨트롤러/서비스/저장소)와 열악한 도메인 모델을 사용하는 경우 이 경우 어떻게 해야 합니까?
두 가지 가능한 접근 방식이 있습니다.
1 - 사용자를 가져오고 필요한 사용자 필드를 전달하는 일반 저장소 방법을 만듭니다.
으아아아
2 - 비활성 사용자를 정확하게 검색하는 저장소 메소드를 생성합니다. 이 메소드는 요청해야 하는 필드를 알 수 있습니다.
으아아아
어떤 방법이 좋을까요? 이 경우 저장소는 "비활성" 사용자의 도메인 이해에 대해 아무것도 모르기 때문에 첫 번째 것이 나에게는 좋아 보입니다. 그러나 동시에 이러한 반응형 접근 방식을 구축하는 것은 상당히 어려울 수 있습니다.
두 번째 방법은 구축하기가 더 쉽지만 동시에 일부 "비즈니스" 논리를 이해하고 비활성 사용자가 바로 "isArchived" 等于 false라는 것을 알고 있습니다. 또한 이 저장소 방법은 사용해야 하는 일수를 알고 있습니다.
이 상황에서는 어떤 옵션을 선택해야 할까요? 아니면 이걸 만드는 다른 방법이 있을까요?
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
이 문제를 해결하는 올바른 방법은 저장소가 저장소의 데이터 요소에 대해서만 알고 있다는 것입니다. 이는 저장소에 여러 진입점을 가질 수 없다는 의미는 아니며 모두 동일한 "테이블"에 액세스하는 다양한 쿼리가 있을 수 있습니다.
첫 번째 접근 방식처럼 완전한 QBE가 필요하다는 의미는 아니며 단순하게 유지하세요. 데이터베이스 수준을 캡슐화하지만 여전히 필요한 것이 필요한 쿼리가 있습니다.
이 경우 isArchived 및 lastVisitedDate 매개변수를 전달하는 서명이 있어야 합니다. QueryUsersByStatusAndLastVisited와 같은 것입니다. 이런 방식으로 저장소는 데이터 검색과 관련된 모든 비트를 처리하지만 검색되는 이유에 대한 논리는 없습니다. 모든 스마트 비트가 서비스 계층에 캡슐화되어 "멍청한" 상태가 됩니다.