फोल्डर-बाय-टाइप या फोल्डर-बाय-फीचर

Question

मैं एक AngularJS स्टाइल गाइड का उपयोग करता हूं। इस गाइड के भीतर एक शैली है folder-by-feature, जिसके बजाय कहा जाता है folder-by-type, और मैं वास्तव में उत्सुक हूं कि सबसे अच्छा दृष्टिकोण क्या है (जावा के लिए इस उदाहरण में)

मान लीजिए कि मेरे पास एक एप्लिकेशन है जहां मैं उपयोगकर्ताओं और पालतू जानवरों को पुनः प्राप्त कर सकता हूं, सेवाओं, नियंत्रकों, रिपॉजिटरी और डोमेन डोमेन ऑब्जेक्ट का उपयोग करके।

फ़ोल्डर-दर-शैलियों को लेते हुए, हमारे पास हमारी पैकेजिंग संरचना के लिए दो विकल्प हैं:

1. फोल्डर-बाय-टाइप

com.example
├── domain
│    ├── User.java
│    └── Pet.java
├── controllers
│    ├── UserController.java
│    └── PetController.java
├── repositories
│    ├── UserRepository.java
│    └── PetRepository.java
├── services
│    ├── UserService.java
│    └── PetService.java
│   // and everything else in the project
└── MyApplication.java

2. फोल्डर-बाय-फीचर

com.example
├── pet
│    ├── Pet.java
│    ├── PetController.java
│    ├── PetRepository.java
│    └── PetService.java
├── user
│    ├── User.java
│    ├── UserController.java
│    ├── UserRepository.java
│    └── UserService.java
│   // and everything else in the project
└── MyApplication.java

एक अच्छा दृष्टिकोण क्या होगा, और ऐसा करने के लिए तर्क क्या हैं?

Comments

के संभावित डुप्लिकेट क्यों हर किसी को किसी अन्य रूप में एक फ़ोल्डर में नियंत्रकों और विचारों डाल करता है?

— रबरडक

मुझे @Laiv का पता नहीं है। क्या भाषा / रूपरेखा वास्तव में उत्तर को प्रभावित करती है? बावजूद, दूसरा सवाल निश्चित रूप से प्रासंगिक है।

— रबरडुक

फिर मुझे अपना उत्तर संपादित करना होगा। और यस्ट, यह एक संभावित डुप्लिकेट है

— Laiv

मैंने कभी भी फोल्डर-बाय-टाइप के लाभ को नहीं समझा। अगर मैं पालतू सुविधा से संबंधित टिकट पर काम कर रहा हूं, तो मुझे शायद Pet, नियंत्रक, भंडार और सेवा के इलाके से लाभ होगा । किस स्थिति में मुझे कभी भी सभी नियंत्रकों की आवश्यकता होगी, लेकिन गैर-विचारों, रेपो या सेवाओं के बिना?

— अलेक्जेंडर

किसी ने उल्लेख नहीं किया है कि जावा में पैकेज सिर्फ फ़ोल्डर नहीं हैं; वे निहित वर्गों के लिए पहुँच को भी प्रभावित करते हैं। इस कारण से, पैकेज-बाय-लेयर / प्रकार वास्तव में जावा में कुछ शब्दार्थ मूल्य प्रदान कर सकता है।

— एंगस गोल्डस्मिथ

Answer 1

फ़ोल्डर-दर-प्रकार केवल छोटे पैमाने पर परियोजनाओं पर काम करता है। अधिकांश मामलों में फोल्डर-बाय-फीचर बेहतर है।

फ़ोल्डर-दर-प्रकार ठीक है जब आपके पास केवल छोटी संख्या में फ़ाइलें होती हैं (10 प्रति प्रकार के अनुसार कहने देता है)। जैसे ही आप अपनी परियोजना में कई घटकों को प्राप्त करते हैं, सभी एक ही प्रकार की कई फ़ाइलों के साथ, यह उस वास्तविक फ़ाइल को खोजने के लिए बहुत कठिन हो जाता है जिसे आप खोज रहे हैं।

इसलिए, इसकी मापनीयता के कारण फ़ोल्डर-बाय-फीचर बेहतर है। हालाँकि, यदि आप फ़ीचर द्वारा फ़ोल्डर समाप्त करते controllerहैं, तो फ़ाइल किस प्रकार के घटक का प्रतिनिधित्व करती है, इसके बारे में जानकारी समाप्त हो जाती है (क्योंकि इसके फ़ोल्डर में अब ऐसा नहीं है ), इसलिए यह भी भ्रमित हो जाता है। इसके लिए 2 सरल उपाय हैं।

सबसे पहले, आप सामान्य नामकरण परंपराओं का पालन कर सकते हैं जो फ़ाइल नाम में समानता का अर्थ है। उदाहरण के लिए जॉन पापा के लोकप्रिय एंगुलरजेएस स्टाइल गाइड में निम्नलिखित हैं:

नामकरण दिशानिर्देश

• एक घटक का अनुसरण करने वाले सभी घटकों के लिए संगत नामों का उपयोग करें जो घटक की विशेषता का वर्णन करता है (वैकल्पिक रूप से) इसका प्रकार। मेरा
  अनुशंसित पैटर्न feature.type.js है। अधिकांश
  संपत्तियों के लिए 2 नाम हैं :

  • फ़ाइल का नाम (avengers.controller.js)
  • कोणीय (एवेंजर्सकंट्रोलर) के साथ पंजीकृत घटक का नाम

दूसरा, आप फ़ोल्डर-दर-प्रकार और फ़ोल्डर-बाय-फ़ीचर शैलियों को फ़ोल्डर-बाय-फ़ीचर-बाय-टाइप में जोड़ सकते हैं:

com.example
├── pet
|   ├── Controllers
│   |   ├── PetController1.java
|   |   └── PetController2.java
|   └── Services
│       ├── PetService1.java
│       └── PetService2.java
├── user
|   ├── Controllers
│   |   ├── UserController1.java
│   |   └── UserController2.java
|   └── Services
│       ├── UserService1.java
│       └── UserService2.java

Comments

जॉन्पापा स्टाइल गाइड बिल्कुल वही था जिसके बारे में मैं फेकिंग कर रहा था :-)

— जेल

कुछ समय (जैसा हम सोचते हैं उससे अधिक) हम उन चीजों में बहुत अधिक जटिलता जोड़ते हैं जो आसान होने वाली थीं। नामकरण और पैकेजिंग इनमें से कुछ चीजें हैं। सबसे अच्छी सलाह यह सरल है। दोनों को मिलाने के फायदे और नुकसान दोनों हैं।

— Laiv

@Laiv उदाहरण में मैंने दिया कि मैं इसके ओवरकिल से सहमत हूं, लेकिन मेरे अधिकांश वास्तविक व्यावसायिक मामलों में, जहां प्रत्येक प्रकार-फ़ोल्डर में आसानी से 10-20 फाइलें हो सकती हैं, मुझे लगता है कि यह बहुत उपयोगी है क्योंकि समग्र फीचर-फ़ोल्डर 50 के आदेश पर होगा फ़ाइलें अन्यथा।

— मोनिका

फेकिंग, धन्यवाद iPhone ऑटो-सही! मेरा मतलब था 'बात करना'।

— जेल डेस

@Chaotic यह विशेष रूप से बात करने की बारीकियों को शुरू करने के लिए बहुत ही तुच्छ है, लेकिन ऐसे मामलों में जहां आपके पास ऐसे टुकड़े हैं जो कई घटकों में उपयोग किए जाते हैं, तो संभवतः यह स्वयं का एक घटक होना चाहिए जो अन्य घटकों पर निर्भर करता है।

— मोनिका

Answer 2

यह वास्तव में सवाल में प्रौद्योगिकी के साथ कुछ नहीं करना है, जब तक कि आप एक फ्रेमवर्क का उपयोग नहीं करते हैं जो एक कन्वेंशन-ओवर-कॉन्फ़िगरेशन दृष्टिकोण के भाग के रूप में फ़ोल्डर-दर-प्रकार को बाध्य करता है।

व्यक्तिगत रूप से, मैं इस बात पर पूरी तरह से राय रखता हूं कि फ़ोल्डर-दर-सुविधा बहुत बेहतर है और हर जगह यथासंभव उपयोग किया जाना चाहिए। यह उन समूहों को एक साथ समूहित करता है जो वास्तव में एक साथ काम करते हैं, जबकि फ़ोल्डर-बाय-टाइप सिर्फ उस चीज को दोहराता है जो आमतौर पर वर्ग नाम में पहले से मौजूद है।

Comments

मुझे लगता है कि फ़ोल्डर-दर-सुविधा में कक्षाएं और विधियों स्कोप (संरक्षित, पैकेज, ...) के साथ खेलना आसान हो जाता है।

— Laiv

छोटी परियोजनाओं के लिए आपके पास केवल एक सुविधा हो सकती है। उस परिदृश्य में टाइप करके व्यवस्थित करना बहुत आसान है।

— aaaaaa

एक उदाहरण के रूप में, Grails आपके डोमेन, नियंत्रकों, सेवाओं, आदि के लिए फोल्डर-बाय-टाइप को बाध्य करता है

— tylerwal

Answer 3

संकुल-दर-सुविधा के साथ कार्य करना उच्च प्रतिरूपता और सामंजस्य में है । यह हमें घटकों के दायरे के साथ खेलने की अनुमति देता है। उदाहरण के लिए, हम LoD और एकीकरण या / और एक्सटेंशन के लिए निर्भरता व्युत्क्रम को लागू करने के लिए एक्सेस संशोधक का उपयोग कर सकते हैं ।

अन्य कारण हैं:

• आसान कोड नेविगेशन
• अमूर्तता का एक उच्च स्तर
• स्कोप्स कम करें (संदर्भों को बाँधते हुए)
• कार्यक्षेत्र संशोधन

फ़ोल्डर-दर-परत डालता कार्यान्वयन विवरण पर बहुत अधिक जोर , (@ दाऊद उल्लेख किया) क्या नहीं आवेदन पर हम काम कर रहे हैं के बारे में बहुत ज्यादा बताता है। पैकेज-बाय-फ़ीचर के विपरीत , पैकेज-बाय-लेयर क्षैतिज संशोधन को प्रोत्साहित करता है। इस तरह का मॉडर्नाइजेशन क्रॉस-कटिंग घटकों के साथ कठिन और थकाऊ काम करता है।

अंत में, एक 3 विकल्प है। " पैकेज बाय कंपोनेंट ", जो अंकल बॉब के शब्दों में, उनके पैकेज सिद्धांतों के साथ बेहतर संरेखित लगता है । अगर अंकल की बॉब राय मायने रखती है या नहीं, तो मैं इसे आपको तय करने के लिए छोड़ देता हूं। मुझे यह दिलचस्प लग रहा है क्योंकि यह सम्मेलन उनके क्लीन आर्किटेक्चर के साथ जुड़ा हुआ है, जो मुझे पसंद है।