โครงสร้างโฟลเดอร์สำหรับโครงการ Node.js

346

ฉันสังเกตว่าโปรเจ็กต์ Node.js มักจะมีโฟลเดอร์ดังนี้:

/ libs, / ผู้ขาย, / support, / spec, / tests

สิ่งเหล่านี้หมายความว่าอย่างไร อะไรคือความแตกต่างระหว่างพวกเขาและที่ฉันควรรวมรหัสอ้างอิง?

node.js

— กุ้ยหลิน桂林
แหล่งที่มา

439

เกี่ยวกับโฟลเดอร์ที่คุณพูดถึง:

/libs มักจะใช้สำหรับกำหนดเอง classes/functions/modules
/vendorหรือ/supportมีห้องสมุดบุคคลที่ 3 (เพิ่มเป็นโมดูลย่อย git เมื่อใช้ git เป็นการควบคุมแหล่งที่มา)
/spec มีข้อกำหนดสำหรับการทดสอบ BDD
/testsมีหน่วยการทดสอบสำหรับแอปพลิเคชัน (โดยใช้กรอบการทดสอบดู ที่นี่ )

หมายเหตุ: ทั้งสอง/vendorและ/supportถูกคัดค้านเนื่องจาก NPM แนะนำการจัดการแพ็คเกจที่สะอาด ขอแนะนำให้จัดการการอ้างอิงบุคคลที่สามทั้งหมดโดยใช้ NPM และไฟล์ package.json

เมื่อสร้างแอปพลิเคชั่นที่ค่อนข้างใหญ่ฉันขอแนะนำโฟลเดอร์เพิ่มเติมต่อไปนี้ (โดยเฉพาะถ้าคุณใช้ MVC- / ORM-Framework บางประเภทเช่นแบบด่วนหรือพังพอน ):

/modelsมีโมเดล ORM ทั้งหมดของคุณ (เรียกว่าSchemasmongoose)
/views มีมุมมองเทมเพลตของคุณ (ใช้ภาษาเทมเพลตใดก็ได้ที่สนับสนุนในแบบด่วน)
/public มีเนื้อหาสแตติกทั้งหมด (รูปภาพ, สไตล์ชีท, JavaScript ฝั่งไคลเอ็นต์)
- /assets/images มีไฟล์รูปภาพ
- /assets/pdf มีไฟล์ pdf แบบคงที่
- /css มีสไตล์ชีท (หรือผลลัพธ์ที่คอมไพล์โดยโปรแกรม css)
- /js มี JavaScript ฝั่งไคลเอ็นต์
/controllersมีเส้นทางด่วนทั้งหมดของคุณคั่นด้วยโมดูล / พื้นที่ของแอปพลิเคชันของคุณ (หมายเหตุ: เมื่อใช้ฟังก์ชั่น bootstrapping ของ express โฟลเดอร์นี้จะถูกเรียกว่า/routes)

ฉันคุ้นเคยกับการจัดระเบียบโครงการของฉันด้วยวิธีนี้และฉันคิดว่ามันทำงานได้ค่อนข้างดี

อัปเดตสำหรับแอปพลิเคชัน Express-based Express (ใช้การเชื่อมต่อสินทรัพย์ ):

/app มี JavaScript ที่คอมไพล์แล้วของคุณ
/assets/ มีสินทรัพย์ฝั่งไคลเอ็นต์ทั้งหมดที่ต้องมีการรวบรวม
- /assets/js มีไฟล์ CoffeeScript ฝั่งไคลเอ็นต์ของคุณ
- /assets/css มีสไตล์ชีท LESS / Stylus ทั้งหมดของคุณ
/public/(js|css|img) มีไฟล์สแตติกของคุณที่ไม่ได้รับการจัดการโดยคอมไพเลอร์ใด ๆ
/src มีไฟล์ CoffeeScript เฉพาะฝั่งเซิร์ฟเวอร์ทั้งหมดของคุณ
/test มีสคริปต์ทดสอบหน่วยทั้งหมด (ใช้งานโดยใช้กรอบการทดสอบที่คุณเลือก)
/views มีมุมมองด่วนทั้งหมดของคุณ (ไม่ว่าจะเป็นหยก ejs หรือเครื่องมือสร้างเทมเพลตอื่น ๆ )

— schaermu
แหล่งที่มา

5

คุณจะใส่ js, css, images ที่ฝั่งไคลเอ็นต์ของคุณไว้ที่ไหน? คุณต้องการแนะนำโครงสร้างโฟลเดอร์ที่คล้ายกันในโฟลเดอร์สาธารณะเช่น: สาธารณะ / สินทรัพย์สาธารณะ / สินทรัพย์ / css สาธารณะ / สินทรัพย์ / ภาพสาธารณะ / สินทรัพย์ / เอกสารสาธารณะ / libs สาธารณะ / สนับสนุนสาธารณะ / การทดสอบสาธารณะ / รุ่นสาธารณะ / มุมมองสาธารณะ / ตัวควบคุม ?

— ezmilhouse

2

expressjs สร้างไดเรกทอรี ./routes เป็นเช่นเดียวกับ. /controllers ในตัวอย่างของคุณหรือไม่

— chovy

2

ทำไมคุณไม่สร้างตัวสร้าง Yeoman ด้วยข้อเสนอนั้น? มันอาจกลายเป็นมาตรฐาน

— Jayr Motta

+1 มาจาก ASP.NET MVC การเรียกตัวควบคุม "เส้นทาง" โฟลเดอร์ "" ทำให้ฉันมีความหมายมากขึ้น

— adam0101

คำถามปกติโครงสร้างของไดเร็กตอรี่จะถูกสร้างโดยเฟรมเวิร์ก (เช่น Symfony สำหรับ PHP) ไม่ใช่หรือ ด้วย Express ตัวอย่างเช่นไม่มีการสร้างโครงสร้างไดเรกทอรีที่ถูกต้อง? นักพัฒนาจะต้องสร้างและบำรุงรักษาการออกแบบและเส้นทาง MVC ด้วยตนเองหรือไม่ ฉันขอขอบคุณข้อเสนอแนะใด ๆ ฉันยังใหม่กับ Express

— AnchovyLegend

49

มีการอภิปรายเกี่ยวกับ 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/
└── ...

— Paulo Oliveira
แหล่งที่มา

ฉันสร้างโมดูลเพื่อต้องการไฟล์แบบไดนามิกช่วยให้คุณสามารถจัดโครงสร้างโครงการของคุณโดยใช้คุณสมบัติแทนรุ่นทั่วไป, มุมมอง, คอนโทรลเลอร์ หวังว่าจะช่วยให้ใครบางคน: github.com/ssmereka/crave

— สกอตต์

13

ตัวอย่างเพิ่มเติมจากสถาปัตยกรรมโครงการของฉันคุณสามารถดูที่นี่:

├── 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

โดยพื้นฐานแล้วแอปแบบลอจิคัลจะถูกแยกไปยังโฟลเดอร์ DB และ APP ภายใน SRC dir

— Daniel Chernenkov
แหล่งที่มา

หากแอพของคุณมีแอพพลิเคชั่นส่วนหน้าคุณวางไว้ข้างใต้srcหรือไม่หรือแอพพลิเคชั่นส่วนหน้าจะได้รับโฟลเดอร์ของตัวเอง (ที่มีpackage.jsonโครงสร้างโฟลเดอร์ของตัวเองและคล้ายกัน)

— wal

2

@Wal ฉันต้องการแยกโครงการส่วนหน้าไปยังที่เก็บอื่นเนื่องจากมีการจัดระเบียบมากขึ้น

— Daniel Chernenkov

2

นี่คือคำตอบทางอ้อมในโครงสร้างโฟลเดอร์นั้นเกี่ยวข้องกันมาก

ไม่กี่ปีที่ผ่านมาฉันมีคำถามเดียวกันเอาโครงสร้างโฟลเดอร์ แต่ต้องทำไดเรกทอรีจำนวนมากย้ายในภายหลังเนื่องจากโฟลเดอร์มีวัตถุประสงค์เพื่อวัตถุประสงค์ที่แตกต่างกว่าที่ฉันได้อ่านบนอินเทอร์เน็ตนั่นคือสิ่งที่โฟลเดอร์เฉพาะมี ความหมายที่แตกต่างกันสำหรับคนที่แตกต่างกันในบางโฟลเดอร์

ตอนนี้หลังจากทำหลายโครงการนอกเหนือจากคำอธิบายในคำตอบอื่น ๆ ทั้งหมดแล้วในโครงสร้างของโฟลเดอร์ฉันขอแนะนำให้ติดตามโครงสร้างของ Node.js เองซึ่งสามารถดูได้ที่: https://github.com/ nodejs มันมีรายละเอียดที่ยอดเยี่ยมเกี่ยวกับการพูด linters และอื่น ๆ สิ่งที่พวกเขามีไฟล์และโครงสร้างและสถานที่ บางโฟลเดอร์มี README ที่อธิบายสิ่งที่อยู่ในโฟลเดอร์นั้น

การเริ่มต้นในโครงสร้างด้านบนเป็นสิ่งที่ดีเพราะบางวันมีข้อกำหนดใหม่เข้ามาและคุณจะมีขอบเขตในการปรับปรุงเนื่องจากตามด้วย Node.js ซึ่งได้รับการดูแลรักษามาเป็นเวลาหลายปีแล้ว

หวังว่านี่จะช่วยได้

— Manohar Reddy Poreddy
แหล่งที่มา

1

สิ่งสำคัญคือให้สังเกตว่าไม่มีความเห็นพ้องกันว่าอะไรคือวิธีการที่ดีที่สุดและกรอบงานที่เกี่ยวข้องโดยทั่วไปไม่บังคับใช้หรือให้รางวัลโครงสร้างบางอย่าง

ฉันคิดว่านี่เป็นสิ่งที่น่าผิดหวังและมีค่าใช้จ่ายสูง แต่ก็สำคัญไม่แพ้กัน มันคือการจัดเรียงของรุ่นวัดผล ( แต่สิ่งที่สำคัญมากกว่า IMO) ของปัญหาคู่มือสไตล์ ฉันชอบที่จะชี้ประเด็นนี้เพราะคำตอบเหมือนกัน: มันไม่สำคัญว่าคุณจะใช้โครงสร้างแบบใดตราบใดที่มันถูกนิยามไว้อย่างดีและเชื่อมโยงกันมันไม่ได้ว่าสิ่งที่คุณใช้โครงสร้างตราบเท่าที่มันกำหนดไว้อย่างดีและเชื่อมโยงกัน

ดังนั้นฉันจึงเสนอให้มองหาคำแนะนำที่ครอบคลุมที่คุณชอบและทำให้ชัดเจนว่าโครงการเป็นไปตามนี้

ไม่ใช่เรื่องง่ายโดยเฉพาะถ้าคุณยังใหม่กับสิ่งนี้! คาดว่าจะใช้เวลาค้นคว้าหลายชั่วโมง คุณจะพบคำแนะนำส่วนใหญ่ที่แนะนำโครงสร้างแบบ MVC ในขณะที่หลายปีที่ผ่านมาซึ่งอาจเป็นตัวเลือกที่ดี แต่ทุกวันนี้ก็ไม่จำเป็นต้องเป็นเช่นนั้น ยกตัวอย่างเช่นนี่เป็นอีกวิธีหนึ่ง

— thisismydesign
แหล่งที่มา

1

สมมติว่าเรากำลังพูดถึงเว็บแอปพลิเคชันและสร้าง 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

สำหรับนักพัฒนาใหม่ที่ได้รับมอบหมายให้เพิ่มการค้นหาหนังสือควรส่งคืนข้อมูลหากหนังสือใด ๆ ที่ถูกทำเครื่องหมายว่าเป็นรายการโปรดมันเป็นเรื่องง่ายมากที่จะดูว่าเขาควรมองไปที่รหัสใด

จากนั้นเมื่อเจ้าของผลิตภัณฑ์กวาดเข้ามาและอุทานว่าคุณสมบัติรายการโปรดควรลบออกอย่างสมบูรณ์มันง่ายที่จะลบ

— maxpaj
แหล่งที่มา