programing

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

mailnote 2023. 5. 21. 11:51
반응형

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

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

/libs, /libs, /support, /spec, /supply

이것들은 정확히 무엇을 의미합니까?그들 사이에는 무엇이 다르며, 참조 코드는 어디에 포함해야 합니까?

말씀하신 폴더와 관련하여:

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

:둘 다: 둘 다/vendor그리고./support는 NPM에서 클린 를 도입한 로 더 사용되지 않습니다.NPM에서는 패키지 관리를 사용하지 않습니다.모든 타사 종속성은 NPM 및 패키지를 사용하여 처리하는 것이 좋습니다.json 파일

비교적 큰 애플리케이션을 구축할 때는 다음과 같은 추가 폴더를 사용하는 것이 좋습니다(특히 express나 mongoose와 같은 MVC-/ORM-Framework를 사용하는 경우).

  • /models 모든 ORM 모델을 포함합니다(호칭).Schemas몽구스에 걸린
  • /views 뷰 템플릿 포함(익스프레스에서 지원되는 템플릿 언어 사용)
  • /public 모든 정적 콘텐츠(이미지, 스타일시트, 클라이언트 측 JavaScript) 포함
    • /assets/images 이미지 파일 포함
    • /assets/pdf 정적 PDF 파일 포함
    • /css 스타일 시트 포함(또는 CSS 엔진에 의해 컴파일된 출력)
    • /js 클라이언트 사이드 JavaScript 포함
  • /controllers 응용 프로그램의 모듈/영역별로 구분된 모든 익스프레스 경로를 포함합니다(참고: express의 부트스트랩 기능을 사용하는 경우 이 폴더를 ).

저는 이런 식으로 프로젝트를 구성하는 것에 익숙해졌고 그것이 꽤 잘 된다고 생각합니다.

CoffeeScript 기반 Express 응용 프로그램에 대한 업데이트(연결 자산 사용):

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

이와 유사한 질문 때문에 깃허브에 대한 논의가 있습니다: 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 dir 내의 DB 및 APP 폴더로 분리됩니다.

웹 애플리케이션과 API 구축에 대해 이야기하고 있다고 가정합니다.

한 가지 접근 방식은 기능별로 파일을 분류하는 것입니다.설명하기:


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

  • 책 검색 및 책 메타데이터 보기
  • 저자 검색 및 저자의 책 보기

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

  • 계정 생성 및 로그인
  • 대출/차입 장부

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

  • 읽고 싶은 책 목록을 저장하거나 즐겨찾기에 표시

먼저 다음과 같은 구조가 있습니다.

books
  └─ entities
  │   └─ book.js
  │   └─ author.js
  │
  └─ services
  │   └─ booksService.js
  │   └─ authorsService.js
  │
  └─ repositories
  │   └─ booksRepository.js
  │   └─ authorsRepository.js
  │
  └─ controllers
  │   └─ booksController.js
  │   └─ authorsController.js
  │
  └─ tests
      └─ ...

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

user
  └─ controllers
  └─ entities
  └─ services
  └─ ...

loan
  └─ controllers
  └─ ...

그리고 즐겨찾기 기능:

favorites
  └─ controllers
  └─ entities
  └─ ...

즐겨찾기로 표시된 책이 있으면 책 검색에서도 정보를 반환해야 한다는 작업을 추가해야 하는 새로운 개발자의 경우 코드에서 찾아야 하는 위치를 쉽게 확인할 수 있습니다.

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

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

저는 이것이 답답하고 엄청난 간접비이지만 똑같이 중요하다고 생각합니다.스타일 가이드 문제의 축소판입니다(그러나 IMO가 더 중요합니다).제가 이것을 지적하고 싶은 이유는 답이 같기 때문입니다. 잘 정의되고 일관성이 있는 어떤 구조를 사용하든 상관없습니다.

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

이것은 쉽지 않습니다, 특히 여러분이 이것에 익숙하지 않다면!연구에 몇 시간을 할애할 것으로 예상합니다.MVC와 유사한 구조를 추천하는 대부분의 가이드를 찾을 수 있습니다.몇 년 전만 해도 그것은 확실한 선택이었을 수 있지만, 요즘은 꼭 그렇지는 않습니다.를 들어, 여기 다른 접근법이 있습니다.

이것은 폴더 구조 자체에 대한 간접적인 답변입니다. 매우 관련이 있습니다.

몇 년 전에도 같은 질문이 있었습니다. 폴더 구조를 선택했지만 나중에 디렉터리 이동을 많이 해야 했습니다. 왜냐하면 폴더는 인터넷에서 읽은 것과는 다른 목적을 가지고 있었기 때문입니다. 즉, 특정 폴더가 어떤 폴더의 다른 사용자에게 다른 의미를 가지고 있기 때문입니다.

이제 폴더 구조 자체에 대한 다른 모든 답변에 대한 설명 외에도 여러 프로젝트를 수행했으므로 https://github.com/nodejs/node 에서 확인할 수 있는 Node.js의 구조 자체를 따를 것을 강력히 제안합니다.예를 들어, 린터와 다른 사람들이 어떤 파일과 폴더 구조를 가지고 있으며 어디에 있는지 등 모든 것에 대해 매우 상세하게 설명합니다.일부 폴더에는 해당 폴더에 무엇이 있는지 설명하는 README가 있습니다.

위의 구조에서 시작하는 것은 언젠가 새로운 요구 사항이 들어오기 때문에 좋지만, 이미 수년간 유지되고 있는 Node.js 자체에 따라 개선할 여지가 있을 것입니다.

GitHub에서 레포를 복제하기만 하면 됩니다.

https://github.com/abhinavkallungal/Express-Folder-Structure

이것은 이미 MongoDB를 데이터베이스로 설정하고 hbs를 뷰 엔진으로 설정한 node.js express.js 프로젝트의 기본 구조입니다. 따라서 node js express 프로젝트를 쉽게 설정할 수 있습니다.

1단계: 레포 다운로드 또는 복제
2단계: 코드 편집기에서 열기
3단계: 폴더 경로에서 터미널 열기
4단계: 터미널에서 설명을 실행npm start
5단계: 코딩 시작

언급URL : https://stackoverflow.com/questions/5178334/folder-structure-for-a-node-js-project

반응형