Yanıtlar:
Bahsettiğiniz klasörler hakkında:
/libs genellikle özel için kullanılır classes/functions/modules/vendorveya /support3. taraf kitaplıkları içeriyor (git kaynak denetimi olarak git kullanılırken git alt modülü olarak eklenir)/spec BDD testleri için özellikler içerir./testsbir uygulama için birim testleri içerir (bir test çerçevesi kullanarak, buraya bakın
)NOT: NPM temiz bir paket yönetimi başlattığından her ikisi de /vendorve /supportkullanımdan kaldırılmıştır. NPM ve bir package.json dosyası kullanarak tüm 3. taraf bağımlılıkların ele alınması önerilir
Oldukça büyük bir uygulama oluştururken, aşağıdaki ek klasörleri öneririm (özellikle ekspres veya mongoose gibi bir çeşit MVC- / ORM-Framework kullanıyorsanız ):
/modelstüm ORM modellerinizi içerir ( Schemasmongoose olarak adlandırılır )/views görünüm şablonlarınızı içerir (hızlı bir şekilde desteklenen herhangi bir şablonlama dilini kullanarak)/public tüm statik içeriği içerir (resimler, stil sayfaları, istemci tarafı JavaScript)
/assets/images resim dosyaları içeriyor/assets/pdf statik pdf dosyaları içerir/css stil sayfaları (veya bir css motoru tarafından derlenmiş çıktı) içeriyor/js istemci tarafı JavaScript içeriyor/controllersuygulamanızın modülüne / alanına göre ayrılmış tüm ekspres rotalarınızı içerir (not: express'in önyükleme işlevini kullanırken bu klasöre çağrı yapılır /routes)Projelerimi bu şekilde organize etmeye alıştım ve bence gayet iyi çalışıyor.
CoffeeScript tabanlı Express uygulamaları için güncelleme ( connect varlıklarını kullanarak ):
/app derlenmiş JavaScript'inizi içerir/assets/ derleme gerektiren tüm müşteri tarafı varlıkları içerir
/assets/js istemci tarafı CoffeeScript dosyalarınızı içerir/assets/css tüm LESS / Stylus stil sayfalarınızı içerir/public/(js|css|img) herhangi bir derleyici tarafından işlenmeyen statik dosyalarınızı içerir/src sunucu tarafına özgü tüm CoffeeScript dosyalarınızı içerir/test tüm birim test komut dosyalarını içerir (seçtiğiniz bir test çerçevesi kullanılarak uygulanır)/views tüm açık görüşlerinizi içerir (yeşim taşı, ejs veya diğer cazip motorlar olsun)GitHub'da buna benzer bir soru nedeniyle bir tartışma var: https://gist.github.com/1398757
Diğer projeleri rehberlik için kullanabilir, GitHub'da aşağıdakileri arayabilirsiniz:
Ve son olarak, bir kitapta ( http://shop.oreilly.com/product/0636920025344.do ) bu yapıyı önerir:
├── index.html
├── js/
│ ├── main.js
│ ├── models/
│ ├── views/
│ ├── collections/
│ ├── templates/
│ └── libs/
│ ├── backbone/
│ ├── underscore/
│ └── ...
├── css/
└── ...Proje mimarimden daha fazla örnek burada görebilirsiniz:
├── 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.
└── testTemel olarak, mantıksal uygulama SRC dir içindeki DB ve APP klasörlerine ayrılmıştır.
srcveya ön uç uygulaması kendi klasörünü alır (kendi package.jsonve benzer klasör yapısına sahip)?
Bu dolaylı cevap, klasör yapısının kendisinde çok ilgili.
Birkaç yıl önce aynı sorum vardı, bir klasör yapısı aldım, ancak daha sonra ilerlemek için çok sayıda dizin yapmak zorunda kaldım, çünkü klasör internette okuduğumdan farklı bir amaç için, yani belirli bir klasörün ne yaptığını bazı klasörlerde farklı insanlar için farklı anlamlar.
Şimdi, klasör yapısının kendisinde, diğer tüm cevaplardaki açıklamalara ek olarak, birden fazla proje yaptıktan sonra, Node.js'nin kendisinin yapısını takip etmenizi şiddetle tavsiye ediyorum: https://github.com/ düğüm / düğüm . Linters ve diğerleri, hangi dosya ve klasör yapısına sahip olduklarını ve nerede olduğunu söylüyorlar. Bazı klasörlerde, o klasörde ne olduğunu açıklayan bir README vardır.
Yukarıdaki yapıdan başlamak iyidir, çünkü bir gün yeni bir gereksinim gelir ve daha sonra yıllar boyunca sürdürülen Node.js'nin kendisini izlediği için iyileştirme kapsamına sahip olacaksınız.
Bu yardımcı olur umarım.
En iyi yaklaşımın ne olduğu konusunda fikir birliği olmadığını ve genel olarak ilgili çerçevelerin belirli yapıları zorlamadığını veya ödüllendirmediğini belirtmek önemlidir.
Bunu sinir bozucu ve devasa bir yük olarak görüyorum ama aynı derecede önemli. Bu, stil rehberi sorununun önemsiz bir versiyonudur (ancak IMO daha önemlidir) . Bunu belirtmek istiyorum çünkü cevap aynı: iyi tanımlanmış ve tutarlı olduğu sürece hangi yapıyı kullandığınız önemli değil .
Bu yüzden beğendiğiniz kapsamlı bir rehber aramanızı ve projenin buna dayandığını açıkça belirtmeyi öneriyorum.
Kolay değil, özellikle de bu konuda yeniyseniz! Araştırma yaparak saatler geçirmeyi bekleyin. MVC benzeri bir yapı öneren kılavuzların çoğunu bulacaksınız. Birkaç yıl önce bu sağlam bir seçim olabilirken, bugünlerde durum böyle olmayabilir. Örneğin burada başka bir yaklaşım var .
Web uygulamaları ve bina API'ları hakkında konuştuğumuzu varsayarsak:
Bir yaklaşım, dosyaları bir mikro hizmet mimarisinin nasıl göründüğü gibi özelliklerine göre kategorilere ayırmaktır. Bence en büyük kazanç, hangi dosyaların uygulamanın bir özelliği ile ilgili olduğunu görmek çok kolay.
Bunu göstermenin en iyi yolu bir örnektir:
Bir kütüphane uygulaması geliştiriyoruz. Uygulamanın ilk sürümünde bir kullanıcı şunları yapabilir:
İkinci bir sürümde, kullanıcılar ayrıca:
Üçüncü bir sürümde kullanıcılar şunları da yapabilir:
İlk önce aşağıdaki yapıya sahibiz:
books
├─ controllers
│ ├─ booksController.js
│ └─ authorsController.js
│
└─ entities
├─ book.js
└─ author.jsDaha sonra kullanıcı ve kredi özelliklerini ekliyoruz:
user
├─ controllers
│ └─ userController.js
├─ entities
│ └─ user.js
└─ middleware
└─ authentication.js
loan
├─ controllers
│ └─ loanController.js
└─ entities
└─ loan.jsVe sık kullanılanlar işlevselliği:
favorites
├─ controllers
│ └─ favoritesController.js
└─ entities
└─ favorite.jsHerhangi bir kitap favori olarak işaretlenmişse, kitap aramasının da bilgi döndürmesi gerektiğini ekleyen herhangi bir yeni geliştirici için, kodda nerede görünmesi gerektiğini görmek gerçekten kolaydır.
Ardından, ürün sahibi süpürür ve sık kullanılanlar özelliğinin tamamen kaldırılması gerektiğini açıkladığında, kaldırması kolaydır.