Express를 노드 응용 프로그램의 나머지 부분과 분리해야 하는 이유

최초 발표coreycleary.me.이것은 나의 콘텐츠 블로그의 교차 게시물이다.나는 1, 2주에 한 번씩 새로운 내용을 발표하는데, 만약 당신이 나의 글을 우편함으로 직접 보내고 싶다면, 당신은 sign up to my newsletter!나는 또한 자주 메모지, 다른 개발자가 제공하는 우수한 튜토리얼 링크, 그리고 기타 무료 경품을 보낸다!
너는 아마도 들었을 것이다. 너는 시종일관 너의 응용 프로그램을 나누어야 하며, 논리가 다른 층으로 유출되지 않도록 해야 한다.
이것은 모두 당신이 가장 좋아하는 블로그, 반드시 읽어야 할 프로그래밍 서적, 기술 회의와 회의에서 발표한 성명입니다.
그런데 왜 이게 문제인지 알고 싶을지도 몰라!이른바'최선의 실천'은 일반적으로 이렇게 소개되지만, 만약 당신이 그것을 따르지 않는다면 무슨 일이 일어날지, 그리고 그들이 처음에 어떻게 최선의 실천이 되었는지는 설명하지 않는다.
따라서 층별로 프로그램을 구성하지 않으면 Express REST API를 사용할 때 이 문제가 발생할 수 있는 문제를 살펴보겠습니다.그리고 우리는 미래에 이런 문제가 발생하지 않도록 간단한 해결 방안을 연구할 것이다. (문제가 있으면 복구해 주십시오.)

눈에 보이는 물체

당신은 이런 코드를 가지고 있습니까?

expressreq 대상은 당신의 컨트롤러에 있을 뿐만 아니라 당신의 서비스 층에도 있습니다!더 심각한 것은 req 대상이 서비스 층에서 데이터베이스 층으로 전달될 수 있다는 것이다!
이것은 논리가 다른 계층으로 유출되지 않도록 항상 애플리케이션을 계층화하는 것을 위반합니다.
지금 이 문제의 원인:

표현할 결혼

우선 현재 응용 프로그램의 나머지 부분은 req 대상뿐만 아니라 Express 프레임워크에도 의존하고 있다.나중에 Hapi나 Koa로 바꾸고 싶으면 어떻게 되나요?그런 다음 req 에 대한 모든 참조를 찾아 삭제/교체해야 합니다.그리고 테스트가 여전히 유효하다는 것을 확보해야 합니다!
소형 응용 프로그램에 대해 말하자면, 이것은 복구하는 데 너무 많은 작업이 필요하지 않을 수도 있지만, 만약 그것이 많은 루트/컨트롤러가 있는 대형 응용 프로그램이고, 많은 사람들이 그것을 사용하고 있다면, 그것을 바꾸는 것은 매우 큰 고통이 될 것이다.
만약 당신이 req 참고 문헌을 놓쳤다면, 당신의 테스트는 그것을 잡지 못했을까요?당신의 사용자는 틀림없이...

테스트를 더욱 번거롭게 하다

이것 또한 테스트를 더욱 어렵게 한다.현재 req 우리에게 전달된 서비스 함수는 우리의 테스트에서 우리는 반드시 이 대상을 모의/재현해야 한다.
관심 있는 대상이 하나 또는 두 개의 속성만 있다면, 이것은 상당히 쉽다.근데 뭐가 많으면?req 제목을 확인하려면 어떻게 합니까?그리고 수동으로 복사하기가 어려워요.
그러나 req HTTP 레이어에만 한정된다면 supertest나 유사한 도구를 사용하여 통합 테스트를 통해 컨트롤러를 테스트할 수 있습니다. 시뮬레이션이 필요하지 않습니다req!서비스 층의 기능에 대해 더 많은 순수 단원 테스트를 진행할 것입니다.

혼합 개념

마지막으로, 우리가 응용 프로그램을 층별로 나누는 가장 큰 원인은 우리가 처리해야 할 정신적 부담을 줄였기 때문이다.
소프트웨어를 구축하는 것은 매우 어려울 뿐만 아니라, 반드시 우리의 뇌에서 여러 가지 일을 처리해야 하는 것은 매우 도전적이다.물론 HTTP 층을 통해 서비스/업무 논리 층에 들어갔다면 이것은 단지 하나의 대상일 뿐, 표면적으로는 이해하기 어렵지 않을 것 같습니다.하지만 당신은 이미 자신의 업무 논리를 가지고 있는데, 왜 또 다른 것을 추가해야 합니까?HTTP 컨텐츠가 현재 비즈니스 논리와 혼합되어 있으므로 당혹스럽지 않습니까?

피/수정

지금 우리는 왜 이것이 문제인지, 어떻게 그것을 피하거나 복구하는지 토론했다.
당신의 req:

const { blogService } = require('../services')
const { createBlogpost } = blogService

const postBlogpost = async (req, res, next) => {
  const {user, content} = req.body
  try {
    await createBlogpost(user, content)
    res.sendStatus(201)
    next()
  } catch(e) {
    console.log(e.message)
    res.sendStatus(500) && next(error)
  }
}

여기서 관건은 controller우리가 하고 있는 것은 const {user, content} = req.body 대상(이 예에서 req 속성)을 분해하여 body 서비스에 관심을 가진 데이터만 추출하는 것이다.그래서 현재 Express는 우리의 HTTP 층에만 한정되어 있고/HTTP 논리를 서비스 층으로 누설할 것을 요청하지 않았습니다.
만약 우리가 미래에 웹 프레임워크를 교환하고 싶다면, 이렇게 하면 더욱 빠르고 간단할 것이다.createBlogpost 대상은 우리의 컨트롤러에만 한정됩니다!현재 우리는 요청 대상을 모의하지 않는 상황에서 다른 층을 테스트할 수 있다.

끝내다

따라서 Express는 전체 응용 프로그램이 아닌 입구점임을 기억하십시오.해당 컨텍스트는 HTTP 계층으로 제한되어야 하며 비즈니스 논리/서비스 계층으로 유출되어서는 안 됩니다.
REST API 계층화에 대한 자세한 내용을 보려면check out the best way I've found to structure/layer my apps.
만약 당신이 이 글이 매우 도움이 된다고 생각한다면, here's that link again 나의 시사통신을 등록하고, 그 글이 발표된 후에 즉시 새로운 내용을 접수하십시오.Node(그리고 일반적인 JavaScript)에 대해 말하자면, 테스트를 어떻게 작성하는지, 응용 프로그램을 어떻게 구성하는지, 비동기적인 것을 어떻게 처리하는지, 새로운 내용을 작성하여 간소화하는 데 도움을 주고 있습니다.그것은 때때처럼 그렇게 어려울 필요가 없다.