2015-07-14 13 views
10

का उपयोग कर एक PHP वेबसाइट के लिए निर्देशिका संरचना मैं एक php वेबसाइट के लिए निर्देशिका संरचना को समझने की कोशिश कर रहा हूं।संगीतकार, गल्प और ट्रैविस

वेबसाइट का उपयोग करेगा:

  • एक बहुत ही बुनियादी php MVC ढांचे (अर्थात्, MinimalMVC, लेकिन मैं एक सामान्य समाधान के लिए देख रहा हूँ, इसलिए ढांचे शायद ध्यान नहीं दिया जा सकता है)
  • संगीतकार प्रबंधन करने के लिए पीएचपी
  • घूंट स्टाइल (देव निर्माण के लिए) एससीएसएस संकलन करने के लिए
  • एससीएसएस निर्भरता, और भी कम करें और जे एस और सीएसएस उत्पादन के साथ-साथ कम करें छवियों, आदि (केवल तैनाती निर्माण के लिए) को श्रेणीबद्ध करने के लिए
  • सीआई सामान के लिए Travis CI

तो बाद सोच और योजना और निर्देशिका संरचना के विभिन्न प्रकार है कि मैं के साथ आया के साथ मुद्दों को देखने का एक बहुत, मैं अभी भी नहीं कुछ है कि मेरी मानदंडों को पूरा करती पा सकते हैं:

  • gulp deploy एक तैनाती फ़ोल्डर, जो जब एक अपाचे सर्वर पर एक /var/www/html/ निर्देशिका में डाल दिया, बस काम करना चाहिए उत्पन्न करने के लिए सक्षम होना चाहिए टीएम

    नोट: MinimalMVC (और यह भी CodeIgniter और अन्य समान चौखटे) वास्तव में निर्माण द्वारा कार्रवाई कभी नहीं है एक ही निर्देशिका

  • पीएचपी बाद में एक app और sys फ़ोल्डर के साथ, रूट निर्देशिका में उनके index.php फ़ाइल की आवश्यकता होती है प्रक्रिया, build/**/*.php जैसी कुछ चीज़ों में src/**/*.php फ़ाइलों की अनावश्यक प्रतिलिपि बनाने से यह बहुत अच्छा होगा। असल में, PHP भाग gulp नहीं रखता है, मैं इसके लिए gulp से अप्रभावित रहना पसंद करेंगे।

अब, मेरे विचारों को एक मेस का एक छोटा सा क्योंकि मैं इस बारे में बहुत ज्यादा सोच किया गया है, इसलिए इस सवाल का भी एक मेस का एक सा होने के लिए मुझे माफ कर दो, लेकिन बुनियादी सवाल है, कैसे है निर्देशिका संरचना दिखानी चाहिए?

एक विचार:

. 
|-- composer.json 
|-- gulpfile.js 
|-- package.json 
|-- src 
| |-- app 
| | |-- controllers 
| | |-- models 
| | `-- <other_framework_stuff> 
| |-- assets 
| | |-- css 
| | |-- img 
| | |-- js 
| | `-- raw 
| |  `-- scss 
| |-- index.php 
| `-- sys 
|  `-- <framework_stuff> 
|-- test 
`-- vendor 
    `-- <composer_stuff> 

इस संरचना, डेवलपर्स केवल /src निर्देशिका के भीतर काम करते हैं। एससीएसएस /src/assets/raw/scss/ से src/assets/css से संकलित हो जाता है। इस तरह, PHP निर्माण प्रक्रिया से हटा दिया गया है। deploy निर्देशिका उत्पन्न करने का प्रयास करते समय, src फ़ोल्डर की प्रतिलिपि बनाई गई है, /src/assets/raw/ (इसलिए /build/assets/raw) निर्देशिका मौजूद नहीं है, और उत्पादन/तैनाती तैयार सीएसएस, जेएस और छवियां /build/assets/ में पाई जाती हैं।

इस समाधान के साथ पहली समस्या अजीब src/assets/raw निर्देशिका है, जो बदसूरत imho लगता है। दूसरी समस्या /vendor निर्देशिका है। इसका मतलब है कि PHP संदर्भ बाहरी स्रोत से सामग्री संदर्भित करता है। तो यदि /src/index.php इसकी देखभाल कर रहा है, तो इसमें ../vendor/autoload.php शामिल होगा। तब इसका मतलब यह होगा कि एक ही कोड /build/index.php में कॉपी हो जाता है।और फिर /build/, /var/www/html में बस इसे छोड़ने के द्वारा नहीं चलेगा जब तक vendor/var/www सिर्फ अजीब लगता है, जिसमें है।

अन्य सामान मैं के बारे में सोचा गया है की एक बहुत कुछ नहीं है, लेकिन यह सभी बदसूरत लगता है कुछ ही रास्ता या अन्य। इस सवाल को बहुत लंबा बनाने से बचने के लिए, मैं यहां रुक जाऊंगा।

सहायता, कृपया। मैं सिर्फ /src/composer.json में vendor-dir का उपयोग करते हुए vendor रखना चाहिए? (मुझे पता है, ओह।) मैं किस प्रकार की निर्देशिका संरचना का उपयोग करूँ?

+4

आप मौजूदा चौखटे से प्रेरणा लेना चाहिए, उदाहरण के लिए Laravel के लिए एक संरचना बहुत करीब का उपयोग करता है कि आप क्या कर रहे हैं: http://laravelbook.com/laravel-architecture/ Btw, यदि आप कर सकते हैं, मैं नहीं की सलाह देते हैं अपनी बिल्ड निर्देशिका में विक्रेता फ़ोल्डर होने और इसके बजाय आपके उत्पादन सर्वर में 'संगीतकार इंस्टॉल' चलाना। – Korri

+0

@ कोरी, धन्यवाद, इससे मदद मिली। –

+2

@ कोररी की टिप्पणी से सहमत हैं। जब तक आप अपनी संगीतकार फ़ाइल को लॉक करते हैं, तब तक 'संगीतकार इंस्टॉल' को लंबे समय तक नहीं लेना चाहिए जब आप तैनात नहीं होते हैं। सीधे आपके प्रश्न से संबंधित नहीं है, लेकिन मुख्य बात जो मैं बदलूंगा वह अलग हो जाएगी जो वास्तव में वेब सर्वर से स्थिर रूप से उपयोग की जाती है 'src'। यह उन उपयोगकर्ताओं से आपकी रक्षा करेगा जो सीधे PHP फ़ाइलों तक पहुंचने का प्रयास कर रहे हैं, जहां कई सुरक्षा समस्याएं होती हैं। दस्तावेज़ सर्वर के रूप में 'सार्वजनिक' निर्देशिका तक पहुंचने के लिए वेब सर्वर को कॉन्फ़िगर किया जाएगा। अधिकांश ढांचे को स्थापित करने के तरीके का पालन करें। –

उत्तर

5

मैं ऊपर Korri से टिप्पणी से सहमत हैं, कि आप मौजूदा चौखटे से प्रेरणा लेने से फायदा हो सकता है।

व्यक्तिगत रूप से, निर्देशिका संरचना इस तरह की सही लगता है, मेरे लिए।

. 
|-- composer.json 
|-- gulpfile.js 
|-- package.json 
|-- changelog.md 
|-- readme.md 
|-- /src (This is the API code that *I'm* responsible for, and that I *own*.). 
| |-- /app 
| | |-- /controllers 
| | |-- /models 
| | `-- <other_framework_stuff> 
| /public (Keeping this outside of the src dir, means that you can give this to your front-end devs without needing to have the entire codebase). 
| | |-- /styles 
| | |-- /images 
| | |-- /js 
| /config (Put all configuration files outside of the src scope, so you can keep it outside of source control) 
| /build (CI build related configuration) 
| | |--phpcs.xml 
| | |--phpdocx.xml 
|-- /tests (separating out your tests in this way can help you run tests separately, more easily) 
| | |--acceptance 
| | |--integration 
| | |--unit 
|-- /vendor (Depenedencies installed via Composer) 

वास्तव में, आपके प्रश्न के लिए कोई समुदाय संचालित सही उत्तर नहीं है। सही जवाब अपने व्यापार के लिए विशिष्ट है, टीम आप में काम, और इस परियोजना का।

मैं अपने /src निर्देशिका के भीतर /vendor निर्देशिका कभी नहीं डाल चाहते हैं - क्योंकि आप नहीं खुद करते हैं। आप अपनी परियोजना की निर्भरताओं के भीतर कोड में किए गए परिवर्तनों के लिए ज़िम्मेदार नहीं हैं, इसलिए इसे अपनी परियोजनाओं की दीवारों के बाहर अपने दायरे में छोड़ा जाना चाहिए।

PSR-4 ऑटोलोडिंग के साथ, यह वास्तव में आपकी निर्देशिका संरचना के बारे में बहुत अधिक मायने रखता नहीं है, इसे किसी भी समय आसानी से बदला जा सकता है, आपके कोड पर कोई प्रभाव नहीं पड़ता है। तो, प्रयोग करें और देखें कि आपके लिए सही है।