[node.js] Node.js 프로젝트의 폴더 구조

Node.js 프로젝트에는 종종 다음과 같은 폴더가 포함되어 있습니다.

/ libs, / vendor, / support, / spec, / tests

이것이 정확히 무엇을 의미합니까? 그들 사이의 차이점은 무엇이며 참조 코드를 어디에 포함시켜야합니까?



답변

언급 한 폴더와 관련하여 :

  • /libs 일반적으로 사용자 정의에 사용됩니다 classes/functions/modules
  • /vendor또는 /support타사 라이브러리를 포함합니다 (git를 소스 제어로 사용할 때 git 하위 모듈로 추가됨)
  • /spec BDD 테스트 사양이 들어 있습니다.
  • /tests응용 프로그램에 대한 단위 테스트를 포함합니다 (테스트 프레임 워크 사용, 여기 참조
    ).

참고 : 모두 /vendor/supportNPM 깨끗한 패키지 관리를 도입하기 때문에 사용되지 않습니다. NPM 및 package.json 파일을 사용하여 모든 타사 종속성을 처리하는 것이 좋습니다.

다소 큰 응용 프로그램을 빌드 할 때는 다음과 같은 추가 폴더를 사용하는 것이 좋습니다 (특히 express 또는 mongoose 와 같은 MVC- / ORM- 프레임 워크를 사용 하는 경우 ).

  • /models모든 ORM 모델을 포함합니다 ( Schemas몽구스 라고 함 ).
  • /views 뷰 템플릿을 포함합니다 (Express에서 지원되는 템플릿 언어 사용).
  • /public 모든 정적 컨텐츠 (이미지, 스타일 시트, 클라이언트 측 JavaScript)를 포함합니다.
    • /assets/images 이미지 파일을 포함
    • /assets/pdf 정적 pdf 파일을 포함합니다
    • /css 스타일 시트를 포함합니다 (또는 CSS 엔진에 의해 컴파일 된 출력)
    • /js 클라이언트 측 JavaScript를 포함
  • /controllers애플리케이션의 모듈 / 영역으로 구분 된 모든 특급 경로를 포함합니다 (참고 : express의 부트 스트랩 기능을 사용하는 경우이 폴더를이라고 함 /routes)

나는 이런 식으로 내 프로젝트를 조직하는 데 익숙해졌고 그것이 잘 작동한다고 생각합니다.

CoffeeScript 기반 Express 응용 프로그램 업데이트 ( connect-assets 사용 ) :

  • /app 컴파일 된 JavaScript를 포함합니다
  • /assets/ 컴파일이 필요한 모든 클라이언트 측 자산을 포함합니다
    • /assets/js 클라이언트 측 CoffeeScript 파일을 포함합니다
    • /assets/css 모든 LESS / Stylus 스타일 시트를 포함합니다
  • /public/(js|css|img) 컴파일러가 처리하지 않는 정적 파일을 포함합니다.
  • /src 모든 서버 측 특정 CoffeeScript 파일을 포함합니다
  • /test 모든 단위 테스트 스크립트를 포함합니다 (선택한 테스트 프레임 워크를 사용하여 구현 됨)
  • /views 모든 표현력이 포함되어 있습니다 (jade, ejs 또는 기타 템플릿 엔진)

답변

다음과 비슷한 질문으로 인해 GitHub에 대한 토론이 있습니다 :
https://gist.github.com/1398757

다른 프로젝트를 사용하여 GitHub에서 다음을 검색하여 안내를받을 수 있습니다.

  • ThreeNodes.js-제 생각에는 모든 프로젝트에 적합한 특정 구조가없는 것 같습니다.
  • 더 가벼운-더 간단한 구조이지만 약간의 조직이 부족합니다.

마지막으로 책 ( http://shop.oreilly.com/product/0636920025344.do )에서 다음 구조를 제안합니다.

├── index.html
├── js/
   ├── main.js
   ├── models/
   ├── views/
   ├── collections/
   ├── templates/
   └── libs/
       ├── backbone/
       ├── underscore/
       └── ...
├── css/
└── ...


답변

내 프로젝트 아키텍처의 더 많은 예는 다음과 같습니다.

├── Dockerfile
├── README.md
├── config
   └── production.json
├── package.json
├── schema
   ├── create-db.sh
   ├── db.sql
├── scripts
   └── deploy-production.sh
├── src
   ├── app -> Containes API routes
   ├── db -> DB Models (ORM)
   └── server.js -> the Server initlializer.
└── test

기본적으로 논리 앱은 SRC 디렉토리 내의 DB 및 APP 폴더로 분리됩니다.


답변

이것은 폴더 구조 자체에 대한 간접적 인 답변입니다.

몇 년 전에 나는 같은 질문을했고 폴더 구조를 취했지만 나중에 폴더를 이동해야했습니다. 폴더는 인터넷에서 읽은 것과 다른 목적, 즉 특정 폴더의 기능을 의미하기 때문입니다. 일부 폴더의 다른 사람들에게 다른 의미.

이제 폴더 구조 자체에 대한 다른 모든 답변의 설명 외에도 여러 프로젝트를 수행 한 후 https://github.com/ 에서 볼 수있는 Node.js 자체의 구조를 따르는 것이 좋습니다. nodejs / node . 그것은 린터와 다른 사람들, 그들이 가지고있는 파일과 폴더 구조 및 위치에 대해 모든 세부 사항을 가지고 있습니다. 일부 폴더에는 해당 폴더의 내용을 설명하는 README가 있습니다.

언젠가는 새로운 요구 사항이 들어 오기 때문에 위의 구조에서 시작하는 것이 좋지만 이미 수년 동안 유지되는 Node.js 자체가 이미 있기 때문에 개선의 여지가 있습니다.

도움이 되었기를 바랍니다.


답변

최선의 접근 방식과 관련 프레임 워크에 대한 합의가 없으며 일반적으로 특정 구조를 시행하거나 보상하지 않습니다.

나는 이것이 좌절스럽고 엄청난 오버 헤드이지만 똑같이 중요하다는 것을 알았습니다. 스타일 가이드 이슈 의 다운 버전 (그러나 IMO가 더 중요)의 일종입니다 . 나는 대답이 동일하기 때문에 이것을 지적하고 싶습니다 . 잘 정의되고 일관성이있는 한 어떤 구조를 사용하든 중요하지 않습니다 .

그래서 나는 당신이 좋아하는 포괄적 인 가이드를 찾고 프로젝트가 이것을 기반으로하고 있음을 분명히 제안합니다.

쉬운 일이 아닙니다. 특히이 기능이 처음이라면 더욱 그렇습니다! 조사하는 데 몇 시간을 소비 할 것으로 예상됩니다. MVC와 같은 구조를 권장하는 대부분의 안내서를 찾을 수 있습니다. 몇 년 전, 이것이 확실한 선택 이었을지 모르지만, 오늘날 반드시 그런 것은 아닙니다. 예를 들어 여기 다른 접근 방식이 있습니다.


답변

웹 애플리케이션에 대해 이야기하고 API를 빌드한다고 가정합니다.

한 가지 방법은 마이크로 서비스 아키텍처와 유사한 방식으로 파일을 기능별분류 하는 것입니다. 내 의견으로는 가장 큰 승리는 응용 프로그램의 기능과 관련된 파일을 쉽게 볼 수 있다는 것입니다.

가장 잘 설명 할 수있는 방법은 다음과 같습니다.


우리는 도서관 응용 프로그램을 개발하고 있습니다. 응용 프로그램의 첫 번째 버전에서 사용자는 다음을 수행 할 수 있습니다.

  • 도서 검색 및 도서 메타 데이터보기
  • 저자를 검색하고 그들의 책을보십시오

두 번째 버전에서 사용자는 다음을 수행 할 수도 있습니다.

  • 계정을 만들고 로그인
  • 대출 / 대출 도서

세 번째 버전에서 사용자는 다음을 수행 할 수도 있습니다.

  • 그들이 읽고 / 즐겨 찾기에 표시 할 책 목록 저장

먼저 다음과 같은 구조를 갖습니다.

books
  ├─ controllers
     ├─ booksController.js
     └─ authorsController.js
  
  └─ entities
      ├─ book.js
      └─ author.js

그런 다음 사용자 및 대출 기능을 추가합니다.

user
  ├─ controllers
     └─ userController.js
  ├─ entities
     └─ user.js
  └─ middleware
       └─ authentication.js
loan
  ├─ controllers
     └─ loanController.js
  └─ entities
      └─ loan.js

그런 다음 즐겨 찾기 기능 :

favorites
  ├─ controllers
     └─ favoritesController.js
  └─ entities
      └─ favorite.js

도서 검색에 추가해야 할 새로운 개발자의 경우, 도서가 즐겨 찾기로 표시되어 있으면 도서 검색에서 정보를 반환해야하므로 코드에서 어디에 표시되는지 쉽게 알 수 있습니다.

그런 다음 제품 소유자가 스윕하여 즐겨 찾기 기능을 완전히 제거해야한다고 주장하면 쉽게 제거 할 수 있습니다.


답변