নোড.জেএস প্রকল্পের জন্য ফোল্ডার কাঠামো

346

আমি লক্ষ্য করেছি যে নোড.জেএস প্রকল্পগুলিতে প্রায়শই এই জাতীয় ফোল্ডার অন্তর্ভুক্ত থাকে:

/ libs, / বিক্রেতা, / সমর্থন, / বিশেষ, / পরীক্ষা

এগুলি ঠিক কী বোঝায়? তাদের মধ্যে আলাদা কী এবং আমার রেফারেন্স কোডটি কোথায় অন্তর্ভুক্ত করা উচিত?

node.js

— গিলিন 桂林
সূত্র

439

আপনি উল্লিখিত ফোল্ডারগুলি সম্পর্কে:

/libs সাধারণত কাস্টম জন্য ব্যবহৃত হয় classes/functions/modules
/vendorবা /support3 য় পক্ষের গ্রন্থাগার রয়েছে (গিটারটি সোর্স নিয়ন্ত্রণ হিসাবে ব্যবহার করার সময় গিট সাব-মডিউল হিসাবে যুক্ত করা হয়েছে)
/spec বিডিডি পরীক্ষার জন্য নির্দিষ্টকরণ রয়েছে।
/testsএকটি অ্যাপ্লিকেশনটির জন্য ইউনিট-পরীক্ষা রয়েছে (একটি পরীক্ষার কাঠামো ব্যবহার করে, এখানে দেখুন )

উল্লেখ্য: উভয় /vendorএবং /supportঅবচিত যেহেতু NPM একটি পরিষ্কার প্যাকেজ পরিচালনার পরিচয় করিয়ে দেন। এটি এনপিএম এবং একটি প্যাকেজ.জসন ফাইল ব্যবহার করে সমস্ত তৃতীয় পক্ষের নির্ভরতা হ্যান্ডেল করার পরামর্শ দেওয়া হয়

যখন একটি বরং বড় আবেদন বিল্ডিং, আমি নিম্নলিখিত অতিরিক্ত ফোল্ডার (বিশেষ করে যদি আপনি চান MVC- / ORM-ফ্রেমওয়ার্ক কিছু ব্যবহার করছেন সুপারিশ দ্রুতগামী বা নকুল ):

/modelsআপনার সমস্ত ওআরএম মডেল রয়েছে ( Schemasমঙ্গুজে বলা হয়)
/views আপনার ভিউ-টেম্পলেটগুলি (এক্সপ্রেসে সমর্থিত কোনও টেম্প্লেটিং ভাষা ব্যবহার করে) রয়েছে
/public সমস্ত স্থিতিশীল সামগ্রী (চিত্রগুলি, স্টাইল শিটস, ক্লায়েন্ট-সাইড জাভাস্ক্রিপ্ট) রয়েছে
- /assets/images ইমেজ ফাইল রয়েছে
- /assets/pdf স্ট্যাটিক পিডিএফ ফাইল রয়েছে
- /css স্টাইল শীট (বা একটি সিএসএস ইঞ্জিন দ্বারা সংকলিত আউটপুট) রয়েছে
- /js ক্লায়েন্ট পাশ জাভাস্ক্রিপ্ট রয়েছে
/controllersআপনার অ্যাপ্লিকেশনটির মডিউল / ক্ষেত্র দ্বারা পৃথক করা আপনার সমস্ত এক্সপ্রেস রুট ধারণ করুন (দ্রষ্টব্য: এক্সপ্রেসের বুটস্ট্র্যাপিং কার্যকারিতাটি ব্যবহার করার সময়, এই ফোল্ডারটি বলা হয় /routes)

আমি এইভাবে আমার প্রকল্পগুলি সংগঠিত করতে অভ্যস্ত হয়েছি এবং আমার মনে হয় এটি বেশ কার্যকর হয়েছে works

কফিস্ক্রিপ্ট-ভিত্তিক এক্সপ্রেস অ্যাপ্লিকেশনগুলির জন্য আপডেট করুন ( সংযোগ-সম্পদ ব্যবহার করে ):

/app আপনার সংকলিত জাভাস্ক্রিপ্ট রয়েছে
/assets/ সমস্ত ক্লায়েন্ট-পাশের সম্পদ রয়েছে যা সংকলন প্রয়োজন
- /assets/js আপনার ক্লায়েন্ট-সাইড কফিস্ক্রিপ্ট ফাইল রয়েছে
- /assets/css আপনার সমস্ত কম / স্টাইলাস স্টাইল শিট রয়েছে
/public/(js|css|img) আপনার স্থির ফাইল রয়েছে যা কোনও সংকলক দ্বারা পরিচালিত হয় না
/src আপনার সমস্ত সার্ভার-সাইড নির্দিষ্ট কফিস্ক্রিপ্ট ফাইল রয়েছে
/test সমস্ত ইউনিট টেস্টিং স্ক্রিপ্ট রয়েছে (আপনার পছন্দের পরীক্ষার কাঠামো ব্যবহার করে প্রয়োগ করা হয়েছে)
/views আপনার সমস্ত এক্সপ্রেস ভিউ রয়েছে (এটি জেড, ইজেস বা অন্য কোনও টেম্প্লেটিং ইঞ্জিন)

— schaermu
সূত্র

5

আপনি আপনার ক্লায়েন্ট-সাইড জেএস, সিএসএস, চিত্রগুলি কোথায় রাখবেন? আপনি কি পাবলিক ফোল্ডারে অনুরূপ ফোল্ডার কাঠামোর পরামর্শ দিবেন, যেমন: সর্বজনীন / সম্পদ পাবলিক / সম্পদ / সিএসএস পাবলিক / সম্পদ / চিত্র পাবলিক / সম্পদ / ডক্স পাবলিক / পাবলিক সাপোর্ট / পাবলিক সাপোর্ট / টেস্ট পাবলিক / মডেল পাবলিক / পাবলিক / কন্ট্রোলারদের দেখে ?

— ezmilhouse

2

এক্সপ্রেজগুলি একটি ./routes ডিরেক্টরি তৈরি করে, এটি কি আপনার উদাহরণে ./controllers এর মতো?

— chovy

2

আপনি কেন এই প্রস্তাব দিয়ে ইওমেন জেনারেটর তৈরি করেন না? এটি একটি স্ট্যান্ডার্ড হয়ে উঠতে পারে।

— জয়র মোটা

+1 এএসপি.নেট এমভিসি থেকে আগত, "রুটস" ফোল্ডারটিকে "নিয়ন্ত্রণকারী" কল করা আমার কাছে আরও বেশি অর্থবোধ করে।

— adam0101

প্রশ্ন, ডিরেক্টরি কাঠামো সাধারণত কাঠামো দ্বারা উত্পন্ন হয় না (অর্থাত্ পিএইচপি জন্য সিমফনি)? উদাহরণস্বরূপ এক্সপ্রেসের সাথে, কোনও ডিরেক্টরি কাঠামো সঠিকভাবে তৈরি হয় না? বিকাশকারীরা নিজেই এমভিসি ডিজাইন এবং রুটগুলি তৈরি এবং রক্ষণাবেক্ষণ করতে চান? আমি যে কোনও প্রতিক্রিয়ার প্রশংসা করি, আমি এক্সপ্রেসে নতুন

— আনচোভিলেজেন্ড

49

এটির অনুরূপ একটি প্রশ্নের কারণে গিটহাবের উপর আলোচনা রয়েছে: https://gist.github.com/1398757

আপনি গাইডেন্সের জন্য অন্যান্য প্রকল্পগুলি ব্যবহার করতে পারেন, গিটহাবের জন্য অনুসন্ধান করতে পারেন:

থ্রিএনডস.জেএস - আমার মতে, মনে হচ্ছে একটি নির্দিষ্ট কাঠামো প্রতিটি প্রকল্পের জন্য উপযুক্ত নয়;
লাইটার - আরও সাধারণ কাঠামো, তবে কিছুটা সংগঠনের অভাব রয়েছে;

এবং পরিশেষে, একটি বইতে ( http://shop.oreilly.com/product/0636920025344.do ) এই কাঠামোর পরামর্শ দেয়:

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

— পাওলো অলিভিরা
সূত্র

গতিশীল ফাইলগুলির প্রয়োজনের জন্য আমি একটি মডিউল তৈরি করেছি, যা আপনাকে আদর্শ মডেল, ভিউ, কন্ট্রোলারের চেয়ে বৈশিষ্ট্য অনুসারে আপনার প্রকল্পের কাঠামো তৈরি করতে দিয়েছি। আশা করি এটি কাউকে সহায়তা করেছে: 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

মূলত, যৌক্তিক অ্যাপ্লিকেশনটি এসআরসি ডিরের ভিতরে ডিবি এবং অ্যাপ্লিকেশন ফোল্ডারে আলাদা হয়।

— ড্যানিয়েল চেরেনকভ
সূত্র

যদি আপনার অ্যাপ্লিকেশনটিতেও একটি ফ্রন্ট এন্ড অ্যাপ থাকে তবে আপনি কি এটিকে রাখেন srcবা সম্মুখ সমাপ্তি অ্যাপটি নিজস্ব ফোল্ডারটি (তার নিজস্ব package.jsonএবং অনুরূপ ফোল্ডার কাঠামো সহ) পাবে?

— ওয়াল

2

@ ওয়ালা আমি আরও সজ্জিত হওয়ায় অগ্রণী প্রকল্পগুলি অন্য ভাণ্ডারগুলিতে পৃথক করতে পছন্দ করি

— ড্যানিয়েল চেরেনকোভ

2

এটি ফোল্ডারের কাঠামোর মধ্যেই পরোক্ষ উত্তর very

কয়েক বছর আগে আমার একই প্রশ্ন ছিল, একটি ফোল্ডার কাঠামো নিয়েছিল তবে অনেকগুলি ডিরেক্টরি পরে চালিয়ে যেতে হয়েছিল, কারণ ফোল্ডারটি আমি ইন্টারনেটে পড়েছি তার চেয়ে আলাদা উদ্দেশ্যে তৈরি করা হয়েছিল, এটি একটি নির্দিষ্ট ফোল্ডার যা করে কিছু ফোল্ডারে বিভিন্ন লোকের জন্য আলাদা অর্থ।

এখন, ফোল্ডার কাঠামো নিজেই, অন্যান্য সমস্ত উত্তরের ব্যাখ্যা ছাড়াও, একাধিক প্রকল্পগুলি সম্পাদন করার পরে, আমি দৃ strongly়ভাবে নোড.জেএস এর কাঠামো অনুসরণ করার পরামর্শ দেব, যা এখানে দেখা যাবে: https://github.com/ nodejs / নোড । এটি সবার উপরে দুর্দান্ত তথ্য রয়েছে, বলুন এবং অন্যান্যগুলি বলুন, তাদের কোন ফাইল এবং ফোল্ডার কাঠামো রয়েছে এবং কোথায় রয়েছে। কিছু ফোল্ডারে একটি README থাকে যা সেই ফোল্ডারে কী রয়েছে তা ব্যাখ্যা করে।

উপরের কাঠামোতে শুরু করা ভাল কারণ কোনও দিন একটি নতুন প্রয়োজনীয়তা আসে এবং আপনার ইতিমধ্যে নোড.জেএস অনুসরণ করে যা উন্নতি করার সুযোগ পাবে যা এখন বেশ কয়েক বছর ধরে রক্ষণাবেক্ষণ করা হচ্ছে।

আশাকরি এটা সাহায্য করবে.

— মনোহর রেড্ডি পোরেডি
সূত্র

1

এটি লক্ষ করা গুরুত্বপূর্ণ যে সাধারণভাবে সর্বোত্তম পদ্ধতির এবং সম্পর্কিত কাঠামোগুলি নির্দিষ্ট কাঠামো প্রয়োগ করে না বা পুরষ্কার দেয় না সে সম্পর্কে কোনও conক্যমত্য নেই।

আমি এটিকে হতাশাব্যঞ্জক এবং বিশাল ওভারহেড বলে মনে করি তবে সমানভাবে গুরুত্বপূর্ণ। এটি একটি একে গুরুত্বহীন সংস্করণ (কিন্তু আইএমও বেশি গুরুত্বপূর্ণ) সাজানোর শৈলী গাইড ইস্যু । আমি এটি উল্লেখ করতে চাই কারণ উত্তরটি একই: আপনি যতক্ষণ কাঠামো এটির সংজ্ঞাযুক্ত এবং সুসংগত হিসাবে ব্যবহার করেন তা বিবেচ্য নয় ।

সুতরাং আমি আপনাকে পছন্দ করি এমন একটি বিস্তৃত গাইড সন্ধান করার প্রস্তাব দেব এবং এটি পরিষ্কার করে দেব যে প্রকল্পটি এর ভিত্তিতে রয়েছে।

এটি সহজ নয়, বিশেষত আপনি যদি এটিতে নতুন হন! ঘন্টা গবেষণা ব্যয় আশা। আপনি বেশিরভাগ গাইডকে এমভিসির মতো কাঠামোর প্রস্তাব দিচ্ছেন। বেশ কয়েক বছর আগে যদিও এটি একটি কঠিন পছন্দ হতে পারে, আজকাল এটি অবশ্যই প্রয়োজন হয় না। উদাহরণস্বরূপ এখানে অন্য পদ্ধতি ।

— এটা আমার নকশা
সূত্র

1

ধরে নিই আমরা ওয়েব অ্যাপ্লিকেশন এবং বিল্ডিং এপিআই সম্পর্কে কথা বলছি:

একটি পন্থাটি হ'ল মাইক্রো সার্ভিস আর্কিটেকচারের মতো দেখতে, বৈশিষ্ট্য অনুসারে ফাইলগুলি শ্রেণীবদ্ধ করা । আমার মতে সর্বাধিক বিজয় হ'ল অ্যাপ্লিকেশনটির কোনও বৈশিষ্ট্য সম্পর্কিত কোন ফাইলগুলি এটি দেখতে খুব সহজ।

চিত্রিত করার সর্বোত্তম উপায় হ'ল একটি উদাহরণের মাধ্যমে:

আমরা একটি লাইব্রেরি অ্যাপ্লিকেশন বিকাশ করছি। অ্যাপ্লিকেশনটির প্রথম সংস্করণে, একজন ব্যবহারকারী এটি করতে পারেন:

বই অনুসন্ধান করুন এবং বইগুলির মেটাডেটা দেখুন
লেখকদের সন্ধান করুন এবং তাদের বই দেখুন

দ্বিতীয় সংস্করণে, ব্যবহারকারীরাও এটি করতে পারেন:

একটি অ্যাকাউন্ট তৈরি করুন এবং লগ ইন করুন
Loণ / ধার বই

তৃতীয় সংস্করণে, ব্যবহারকারীরাও এটি করতে পারেন:

তারা পছন্দের বইগুলি পড়তে / চিহ্নিত করতে চান তাদের তালিকা সংরক্ষণ করুন

প্রথমে আমাদের নীচের কাঠামো রয়েছে:

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

তারপরে আমরা ব্যবহারকারীর এবং loanণের বৈশিষ্ট্যগুলি যুক্ত করব:

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
সূত্র