Struktura folderów dla projektu Node.js

Zauważam, że projekty Node.js często zawierają takie foldery:

/ libs, / vendor, / support, / spec, / testy

Co dokładnie to oznacza? Czym się różnią i gdzie powinienem dołączyć kod referencyjny?

W odniesieniu do wspomnianych folderów:

• /libs jest zwykle używany do niestandardowego classes/functions/modules
• /vendorlub /supportzawiera biblioteki stron trzecich (dodane jako podmoduł git, gdy używa się git jako kontroli źródła)
• /spec zawiera specyfikację testów BDD.
• /testszawiera testy jednostkowe aplikacji (przy użyciu środowiska testowego, patrz tutaj )

UWAGA: zarówno /vendori /supportsą przestarzałe od NPM wprowadził czystą zarządzania pakietami. Zaleca się obsługę wszystkich zależności innych firm za pomocą NPM i pliku package.json

Podczas budowania dość dużej aplikacji polecam następujące dodatkowe foldery (szczególnie jeśli używasz jakiegoś rodzaju MVC- / ORM-Framework, takiego jak express lub mongoose ):

• /modelszawiera wszystkie modele ORM (nazywane Schemasmangustą)
• /views zawiera szablony widoków (przy użyciu dowolnego języka szablonów obsługiwanego w trybie ekspresowym)
• /public zawiera całą zawartość statyczną (obrazy, arkusze stylów, JavaScript po stronie klienta)
  • /assets/images zawiera pliki graficzne
  • /assets/pdf zawiera statyczne pliki pdf
  • /css zawiera arkusze stylów (lub skompilowane dane wyjściowe przez silnik css)
  • /js zawiera JavaScript po stronie klienta
• /controllerszawierają wszystkie Twoje trasy ekspresowe, oddzielone modułem / obszarem aplikacji (uwaga: podczas korzystania z funkcji ładowania początkowego ekspresu, ten folder jest nazywany /routes)

Przyzwyczaiłem się do organizowania swoich projektów w ten sposób i myślę, że to działa całkiem dobrze.

Aktualizacja dla aplikacji Express opartych na CoffeeScript (przy użyciu zasobów Connect ):

• /app zawiera skompilowany JavaScript
• /assets/ zawiera wszystkie zasoby po stronie klienta, które wymagają kompilacji
  • /assets/js zawiera pliki CoffeeScript po stronie klienta
  • /assets/css zawiera wszystkie arkusze stylów LESS / Stylus
• /public/(js|css|img) zawiera pliki statyczne, które nie są obsługiwane przez żaden kompilator
• /src zawiera wszystkie pliki CoffeeScript specyficzne dla serwera
• /test zawiera wszystkie skrypty testowania jednostkowego (zaimplementowane przy użyciu wybranej przez ciebie struktury testowej)
• /views zawiera wszystkie twoje ekspresowe widoki (czy to jadeit, ejs lub inny silnik szablonów)

Trwa dyskusja na GitHub z powodu pytania podobnego do tego: https://gist.github.com/1398757

Możesz skorzystać z innych projektów w celu uzyskania wskazówek, wyszukaj w GitHub:

• ThreeNodes.js - moim zdaniem wydaje się mieć specyficzną strukturę nieodpowiednią dla każdego projektu;
• lżejsze - prostsza struktura, ale brakuje jej organizacji;

I wreszcie w książce ( http://shop.oreilly.com/product/0636920025344.do ) sugeruje tę strukturę:

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

Więcej przykładów z mojej architektury projektu można zobaczyć tutaj:

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

Zasadniczo aplikacja logiczna oddzielona do folderów DB i APP w katalogu SRC.

Jest to odpowiedź pośrednia, bardzo związana ze strukturą folderów.

Kilka lat temu miałem to samo pytanie, wziąłem strukturę folderów, ale później musiałem dużo przenieść katalog, ponieważ folder ten miał inny cel niż ten, który przeczytałem w Internecie, czyli to, co ma dany folder różne znaczenia dla różnych osób w niektórych folderach.

Teraz, po wykonaniu wielu projektów, oprócz objaśnienia we wszystkich innych odpowiedziach, na samej strukturze folderów, zdecydowanie sugerowałbym, aby podążać za strukturą samego Node.js, którą można zobaczyć na stronie : https://github.com/ nodejs / node . Zawiera wszystkie szczegóły, powiedzmy linters i inne, jaką strukturę plików i folderów mają i gdzie. Niektóre foldery mają plik README, który wyjaśnia, co znajduje się w tym folderze.

Zaczynanie w powyższej strukturze jest dobre, ponieważ pewnego dnia pojawia się nowe wymaganie, ale będziesz mieć możliwość poprawy, ponieważ już za nim podąża sam Node.js, który jest utrzymywany przez wiele lat.

Mam nadzieję że to pomoże.

Należy zauważyć, że nie ma zgody co do najlepszego podejścia, a powiązane ramy ogólnie nie egzekwują ani nie nagradzają niektórych struktur.

Uważam, że jest to frustrujące i ogromne obciążenie ogólne, ale równie ważne. Jest to rodzaj lekceważonej wersji (ale ważniejsze IMO) problemu przewodnika po stylach . Chciałbym to podkreślić, ponieważ odpowiedź jest taka sama: nie ma znaczenia, jakiej struktury używasz, o ile jest ona dobrze zdefiniowana i spójna .

Proponuję więc poszukać wyczerpującego przewodnika, który ci się podoba i wyjaśnić, że projekt jest na tym oparty.

To nie jest łatwe, szczególnie jeśli jesteś w tym nowy! Spodziewaj się spędzić godziny na badaniach. Znajdziesz większość przewodników zalecających strukturę podobną do MVC. Choć kilka lat temu był to dobry wybór, obecnie niekoniecznie tak jest. Na przykład oto inne podejście .

Zakładając, że mówimy o aplikacjach internetowych i tworzeniu interfejsów API:

Jednym z podejść jest kategoryzowanie plików według funkcji , podobnie jak wyglądałaby architektura mikrousług. Moim zdaniem największą wygraną jest to, że bardzo łatwo jest sprawdzić, które pliki odnoszą się do funkcji aplikacji.

Najlepszym sposobem zilustrowania tego jest przykład:

Tworzymy aplikację biblioteczną. W pierwszej wersji aplikacji użytkownik może:

• Wyszukaj książki i zobacz metadane książek
• Wyszukaj autorów i zobacz ich książki

W drugiej wersji użytkownicy mogą również:

• Utwórz konto i zaloguj się
• Pożycz / pożycz książki

W trzeciej wersji użytkownicy mogą również:

• Zapisz listę książek, które chcą przeczytać / oznaczyć jako ulubione

Najpierw mamy następującą strukturę:

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

Następnie dodajemy funkcje użytkownika i pożyczki:

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

A potem funkcjonalność ulubionych:

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

Dla każdego nowego programisty, któremu powierzy się zadanie dodania, że ​​wyszukiwanie książek powinno również zwracać informacje, jeśli jakakolwiek książka została oznaczona jako ulubiona, naprawdę łatwo jest zobaczyć, gdzie w kodzie powinien szukać.

Następnie, gdy właściciel produktu wkracza i oświadcza, że ​​funkcja ulubionych powinna zostać całkowicie usunięta, łatwo ją usunąć.