आप अपनी परियोजनाओं को कैसे व्यवस्थित करते हैं? [बन्द है]

Question

क्या आपके पास परियोजनाओं के आयोजन की कोई विशेष शैली है?

उदाहरण के लिए, वर्तमान में मैं यहां बोलीविया के कुछ स्कूलों के लिए एक प्रोजेक्ट बना रहा हूं, यह है कि मैंने इसे कैसे आयोजित किया:

TutoMentor (Solution)
TutoMentor.UI   (Winforms project)
TutoMentor.Data (Class library project)

आप वास्तव में अपनी परियोजना को कैसे व्यवस्थित करते हैं? क्या आपके पास किसी ऐसी चीज का उदाहरण है जिसे आपने संगठित किया है और गर्व कर रहे हैं? क्या आप समाधान फलक का स्क्रीनशॉट साझा कर सकते हैं?

मेरे आवेदन के UI क्षेत्र में, मुझे विभिन्न रूपों को व्यवस्थित करने और जहां वे हैं, एक अच्छे स्कीमा पर निर्णय लेने में परेशानी हो रही है।

---

संपादित करें:

.UI परियोजना में विभिन्न रूपों के आयोजन के बारे में क्या? मुझे अलग-अलग फॉर्म कहां / कैसे चाहिए? इन सभी को परियोजना के मूल स्तर पर लाना एक बुरा विचार है।

Comments

वाह, एक 450 इनाम !?

— मतीन उल्हाक

@ मंटू: हाँ, मैं वास्तव में कुछ बेहतरीन जवाबों में दिलचस्पी लेता हूँ। :)

यह स्पष्ट रूप से कहा जाना चाहिए कि आप C # के बारे में पूछते हैं। मैं व्यक्तिगत रूप से टैग नहीं देखता हूं।

— पिथिकोस

.Net रिपॉजिटरी विशिष्ट संरचना के लिए देखें gist.github.com/davidfowl/ed7564297c61fe9ab814

— माइकल फ्रीजिम

हमेशा की तरह, XYZ कारणों से कई अच्छे प्रश्न बंद हो जाते हैं। हमें कई अन्य अच्छे उत्तर मिल सकते हैं।

— मोहम्मद नौलेडिन

Answer 1

जब एक परियोजना की रूपरेखा तैयार करना और वास्तुकला का निर्माण करना मैं दो दिशाओं से शुरू करता हूं। पहले मैं डिजाइन की जा रही परियोजना को देखता हूं और निर्धारित करता हूं कि किस समस्या को हल करने की आवश्यकता है। मैं उन लोगों को देखता हूं जो इसका उपयोग कर रहे हैं और एक कच्चे यूआई डिजाइन के साथ शुरू करेंगे। इस बिंदु पर मैं डेटा को अनदेखा कर रहा हूं और केवल यह देख रहा हूं कि उपयोगकर्ता क्या पूछ रहे हैं और इसका उपयोग कौन करेगा।

एक बार मुझे इस बात की बुनियादी समझ हो जाती है कि वे मुझसे क्या पूछ रहे हैं, यह निर्धारित करते हैं कि मुख्य डेटा क्या है, तो वे हेरफेर करेंगे और उस डेटा के लिए एक बुनियादी डेटाबेस लेआउट शुरू करेंगे। फिर मैं उन व्यावसायिक नियमों को परिभाषित करने के लिए सवाल पूछना शुरू करता हूं जो डेटा को घेरते हैं।

दोनों छोर से शुरू करके मैं स्वतंत्र रूप से इस तरह से एक परियोजना को पूरा करने में सक्षम हूं जो दो छोरों को एक साथ पिघला देता है। मैं हमेशा कोशिश करता हूं कि डिजाइनों को एक साथ पिघलने से पहले जितनी देर तक अलग रखा जा सके, लेकिन जब तक मैं आगे बढ़ूं, सभी की आवश्यकताओं को ध्यान में रखें।

एक बार जब मुझे समस्या के प्रत्येक सिरे के बारे में अच्छी समझ हो जाती है तो मैं उस परियोजना के ढांचे को तैयार करना शुरू कर देता हूँ जो समस्या के समाधान के लिए बनाई जाएगी।

एक बार परियोजना समाधान का मूल लेआउट बनाया जाता है, मैं परियोजना की कार्यक्षमता को देखता हूं और काम करने के प्रकार के आधार पर उपयोग किए जाने वाले नामस्थानों का आधार सेट करता हूं। यह खाते, खरीदारी की टोकरी, सर्वेक्षण आदि जैसी चीजें हो सकती हैं।

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

SolutionName

.ProjectNameDocuments
    For large projects there are certain documents that need to be kept with
    it. For this I actually create a separate project or folder within the 
    solution to hold them.
.ProjectNameUnitTest
    Unit testing always depends on the project - sometimes it is just really 
    basic to catch edge cases and sometimes it is set up for full code 
    coverage.  I have recently added graphical unit testing to the arsenal.
.ProjectNameInstaller
    Some projects have specific installation requirements that need to be 
    handled at a project level.
.ProjectNameClassLibrary
    If there is a need for web services, APIs, DLLs or such.
.ProjectNameScripts (**Added 2/29/2012**)
    I am adding this because I just found a need for one in my current project.  
    This project holds the following types of scripts: SQL (Tables, procs, 
    views), SQL Data update scripts, VBScripts, etc.
.ProjectName
    .DataRepository 
        Contains base data classes and database communication.  Sometimes 
        also hold a directory that contains any SQL procs or other specific 
        code.  
    .DataClasses
        Contains the base classes, structs, and enums that are used in the 
        project.  These may be related to but not necessarily be connected
        to the ones in the data repository.
    .Services 
        Performs all CRUD actions with the Data, done in a way that the 
        repository can be changed out with no need to rewrite any higher 
        level code.
    .Business
        Performs any data calculations or business level data validation,
        does most interaction with the Service layer.
    .Helpers
        I always create a code module that contains helper classes.  These 
        may be extensions on system items, standard validation tools, 
        regular expressions or custom-built items.  
    .UserInterface
        The user interface is built to display and manipulate the data.  
        UI Forms always get organized by functional unit namespace with 
        additional folders for shared forms and custom controls.

Comments

अब तक का सबसे अच्छा जवाब!

इनाम का आनंद लें, आपके जवाब से मुझे काफी मदद मिली।

@ वे सभी परियोजनाएं हैं? या सिर्फ शीर्ष-स्तरीय आइटम? मैं .Net के लिए काफी नया हूं और यह तय करने में परेशानी हो रही है कि क्या कोई प्रोजेक्ट होना चाहिए या किसी प्रोजेक्ट का सब-फोल्डर।

— कार्सन मायर्स

शीर्ष स्तर की वस्तुओं में से प्रत्येक @Carson मायर्स परियोजनाएं हैं, दूसरे स्तर के आइटम एक परियोजना के भीतर फ़ोल्डर हैं। शीर्ष स्तर की कुछ वस्तुएं ऐसी परियोजनाएं हैं जिन्हें उन dll में संकलित किया जाता है जिन्हें आवश्यकतानुसार अन्य परियोजनाओं द्वारा संदर्भित किया जाता है।

— एमी पैटरसन

@ मैं आपके जवाब को बहुत पसंद करता हूं, बहुत विस्तृत विवरण। लेकिन मैंने कुछ उदाहरणों में देखा है कि लोग DataRepository, DataClasses, Services, Business, आदि को एक ही प्रोजेक्ट में अलग-अलग फ़ोल्डरों के बजाय अलग-अलग प्रोजेक्ट्स में विभाजित करते हैं। इस संबंध में आप क्या कहेंगे? दो विकल्पों के बीच क्या फायदे / नुकसान हैं? धन्यवाद!

— इमेजरो

Answer 2

मुझे अपनी परियोजनाओं को परतों में विभाजित करना पसंद है

इस तरह से चक्रीय निर्भरता का प्रबंधन करना आसान है। मैं गारंटी दे सकता हूं कि कोई भी परियोजना उदाहरण के लिए, दृश्य परियोजना (परत) को गलती से आयात नहीं कर रही है। मैं उप-परतों में भी अपनी परतों को तोड़ता हूं। तो मेरे सभी समाधानों में इस तरह की परियोजनाओं की एक सूची है:

• Product.Core
• उत्पाद नमूना
• Product.Presenter
• Product.Persistence
• Product.UI
• Product.Validation
• Product.Report
• Product.Web

वे मेरे आवेदन के बड़े "बिल्डिंग ब्लॉक" हैं। फिर प्रत्येक परियोजना के अंदर मैं नाममात्र में अधिक तार्किक रूप से व्यवस्थित करता हूं लेकिन यह बहुत भिन्न होता है। UI के लिए जब बहुत सारे रूप बनाते हैं तो मैं एक स्थानिक विभाजन में सोचने की कोशिश करता हूं और फिर प्रत्येक "स्पेस" के लिए नाम स्थान बनाता हूं। मान लीजिए कि उपयोगकर्ता की प्राथमिकताएं और नियंत्रणों का एक समूह है, मेरे पास उनके लिए UserPreferences नामक एक नाम स्थान है, और इसी तरह।

Comments

के बारे में क्या: उत्पाद - कोर - मॉडल - प्रस्तुतकर्ता - दृढ़ता - यूआई - मान्यता - रिपोर्ट - वेब

— डैनियल फिशर लेनीबाकन

मुझे लगता है कि Coreयह काफी खतरनाक है, क्योंकि यह एक अखंड कोड डिजाइन की ओर जाता है, जहां अधिकांश तर्क अंदर जा सकते हैं या नहीं जा सकते हैं Core। उदाहरण के लिए: एक मॉडल, प्रस्तोता, दृढ़ता, यूआई, मान्यता, रिपोर्ट, वेब की तरह नहीं लगता है कि तर्क, स्वाभाविक रूप से फेंक दिया जाएगा Core।

— Yeo

@ यह दोनों पक्षों को खेल सकता है, या तो अपनी Coreपरियोजना को कचरे के एक अखंड टुकड़े में बदलकर या आपको सैकड़ों परियोजनाओं वाले समाधान से बचाकर। यह निर्णय लेने वाले डेवलपर की जिम्मेदारी है, कोई भी परियोजना संरचना खराब कोडर्स को बुरे काम करने से नहीं बचा सकती है।

— एलेक्स

@Prokurors हाँ, आम तौर पर Product.Core के अंदर होता है, जहाँ मैं सिस्टम के "कोर" बिजनेस लॉजिक को रखता हूँ। "Ui व्यापार तर्क" Product.Presenter में जाना चाहिए। उदाहरण के लिए, यदि आपका सिस्टम तय करता है कि एक बटन को निष्क्रिय किया जाना चाहिए, जबकि कुछ डेटा लोड हो रहा है, तो यही है कि मैं एक "ui व्यापार तर्क" कहता हूं और मैं इसे प्रस्तुतकर्ता में डालूंगा। "कोर बिजनेस लॉजिक" आपके कोर मॉडल (या डोमेन मॉडल) से सीधे संबंधित है। एक मैसेजिंग सिस्टम अधिकतम वर्णों की संख्या 140 अक्षर तय कर सकता है, यह एक तर्क है जो आपके व्यवसाय के मूल में है।

— एलेक्स

उत्पाद UI या वेब से कैसे भिन्न है?

— डोपाट्रमन

Answer 3

परियोजनाओं का आयोजन

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

उदाहरण के लिए, कभी-कभी, इस परियोजना के पास, जिसमें चौखटे का पूरा सेट होता है (ईमेल, लॉगिंग आदि) पर्याप्त है:

MyCompany.Frameworks

दूसरी बार, मैं रूपरेखाओं को टुकड़ों में तोड़ना चाहूंगा, ताकि उन्हें व्यक्तिगत रूप से आयात किया जा सके:

MyCompany.Frameworks.Networking
MyCompany.Frameworks.Logging
MyCompany.Frameworks.SomeLOBFramework

---

आयोजन सूत्र

UI प्रोजेक्ट के तहत फॉर्म का आयोजन वास्तव में आपके प्रोजेक्ट के विस्तार के रूप में होगा।

• छोटा - एक साधारण फॉर्म फ़ोल्डर बहुत छोटी परियोजना के लिए पर्याप्त हो सकता है। कभी-कभी आप संरचनाओं को ओवरपाइन कर सकते हैं, जैसे कि आप नाम स्थान बना सकते हैं और चीजों को अधिक जटिल बना सकते हैं, जैसे कि उन्हें होना चाहिए।

• मध्यम से बड़े - यहाँ, मैं आमतौर पर अपने रूपों को कार्यात्मक क्षेत्रों में विभाजित करना शुरू करता हूं। अगर मेरे पास मेरे ऐप का एक हिस्सा है जिसमें उपयोगकर्ता को प्रबंधित करने के लिए 3 रूप हैं और कुछ जो फुटबॉल के खेल और स्कोर का ट्रैक रखते हैं, तो मेरे पास एक फ़ॉर्म> उपयोगकर्ता क्षेत्र और एक फ़ॉर्म> गेम्स क्षेत्र या ऐसा कुछ होगा। यह वास्तव में परियोजना के बाकी हिस्सों पर निर्भर करता है, मेरे पास कितने रूप हैं कि मैं इसे कैसे ठीक करता हूं।

याद रखें, दिन के अंत में नामस्थान और फ़ोल्डर्स बस व्यवस्थित करने और चीजों को तेज़ी से खोजने में आपकी सहायता करने के लिए हैं।

---

वास्तव में, यह आपकी टीम, आपकी परियोजनाओं और आपके लिए क्या आसान है पर निर्भर करता है। मेरा सुझाव है कि सामान्य तौर पर, आप अपने सिस्टम की प्रत्येक परत / घटक के लिए अलग-अलग प्रोजेक्ट बनाते हैं, लेकिन हमेशा अपवाद होते हैं।

सिस्टम आर्किटेक्चर पर मार्गदर्शन के लिए Microsoft के पैटर्न और अभ्यास साइट देखें।

Answer 4

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

• Wadmt (समाधान)
  • Wadmt.Common
  • Wadmt.Data
    • Wadmt.Data.MySql
    • Wadmt.Data.SqlServer
    • Wadmt.Data.Oracle
  • Wadmt.Domain
  • Wadmt.Services
  • Wadmt.Tests
    • Wadmt.Tests.Common
    • Wadmt.Tests.Domain
    • Wadmt.Tests.Services
    • Wadmt.Tests.Integration
  • Wadmt.Web

उम्मीद है कि यह आपके लिए उपयोगी है। अलग होने के स्तरों को जानने में मुझे कुछ समय लगा।

Comments

मैं "Wadmt" को कम कर दूंगा। फ़ाइल सिस्टम को सूखा रखें। सांत्वना पर काम करते समय यह बहुत मदद करता है ...

— डैनियल फिशर लेनिबैकोन

Answer 5

अपने समाधानों को व्यवस्थित करने के लिए योजना बनाना अच्छा है, और इसे करने के कई तरीके हैं। हमारे पास कुछ कार्यक्षमता है जो कई परियोजनाओं में साझा की जाती है, जो हमारे उपयोगकर्ताओं के लिए निरंतरता भी प्रदान करती है। परियोजना संगठन इस बात पर निर्भर करता है कि हम क्या कर रहे हैं। इसके मूल में हमारे पास होगा:

Company (solution)
  Company.Common (shared library)
  Company.Project (Main application UI)
  Company.Project.UnitTests (Unit tests for all project modules)
  Company.Project.IntegrationTests (integration tests for all project modules)
  Company.Project.AutomationTests (tests that invoke the UI)

वहाँ से यह वास्तव में सेटअप पर निर्भर करता है। यदि हमारे पास क्लाइंट एप्लिकेशन और वेब फ्रंट एंड (क्लासरूम या अन्य शोध में उपयोग परिणाम एकत्र करने के लिए उपयोगी) दोनों हैं, तो हमें एक ऐसी परियोजना की आवश्यकता होती है, जिसमें आमतौर पर साझा कोड (यानी डेटा ऑब्जेक्ट्स जो क्रमबद्ध होंगे)।

  Company.Project.Model (ORM and business logic layer)
  Company.Project.Webapp (Web frontend/web service layer)
  Company.Project.WebClient (client code for web services)

अन्य उपप्रकारों को आवश्यकतानुसार जोड़ा जा सकता है। जैसा कि मैंने कहा, यह वास्तव में परियोजना पर निर्भर करता है। कुछ परियोजनाएं वास्तव में सरल हैं, और केवल मुख्य तत्वों की आवश्यकता है। हम मनमाने ढंग से प्रोजेक्ट सेपरेशन से लड़ने की कोशिश करते हैं, इसलिए लेयर्स द्वारा विभाजन करना वास्तव में मायने रखता है। परतों को इस बात से परिभाषित किया जाता है कि परियोजनाओं, समाधानों, या प्लगइन्स / एक्सटेंशन के लिए क्या आवश्यक है।

Answer 6

यह दिलचस्प है कि इतने सारे लोग यहाँ DRY पर विचार नहीं करते हैं। यह मेरे जीवन में कुछ बार हुआ कि डेवलपर्स ने निर्देशिका संरचनाएं बनाईं जो उस वजह से निर्माण करने में सक्षम नहीं थीं। समाधान और परियोजना निर्देशिका से परियोजना का नाम बाहर रखें!

तो यहाँ मेरा तरीका है:

{drive}:\{customer}\{apps|libs|tools}\{project}
  - cer
  - res
  - src
   - Common
   - Data
   - UI
   - Logic
   - Logic._Tests  

Comments

क्या है DRY? किसी चीज के लिए संक्षेप?

— पिथिकोस

@ पिथिकोस इट्स ए ब्रीफ फॉर ए डू रिपीट यू योरसेल्फ

— पेरो पी।

क्या है Logic? के Commonरूप में अच्छी तरह से फ़ोल्डर में तर्क नहीं हो सकता है ?

— डोपाट्रमन

मैंने रिज्यूमेबल सामान को कॉमन में डाल दिया। कुछ लोग फ्रेमवर्क या कोर भी कह सकते हैं ...

— डैनियल फिशर लेनीबाकन

Answer 7

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

खैर, उन मॉड्यूल हैं परियोजनाओं मेरी तहत समाधान (आमतौर पर वर्ग पुस्तकालयों )। प्रत्येक मॉड्यूल का एक अलग नामस्थान और उसका अपना डिजाइन ( वर्ग , आदि) होता है।

उन मॉड्यूलों में से एक जीयूआई ( ग्राफिकल यूजर इंटरफेस ) है।

मैं भी हमेशा प्रत्येक परियोजना में परिवर्तनों को ट्रैक करने के लिए एक संशोधन नियंत्रण उपकरण का उपयोग करता हूं । मेरा सुझाव है Git । यह ओपनसोर्स, वितरित और उपयोग करने के लिए स्वतंत्र है।

Answer 8

हर बार जब मैं एक नई परियोजना शुरू करता हूं तो मुझे एक व्यापक विनिर्देश मिलता है कि यह क्या करना चाहिए। इस इनपुट के होने से मुझे एक संदर्भ प्रदान करने में मदद मिलती है, इसलिए मैं आगे बढ़ता हूं और परियोजनाओं के लक्ष्यों को प्राप्त करने के लिए सबसे अच्छा (या सबसे उपयुक्त) तरीका सोचता हूं। इस बिंदु पर मैं यह सोचना शुरू करता हूं कि कौन से देसी पैटर्न मुझे इच्छित समाधान प्रदान कर सकते हैं। यहाँ मैं परियोजना का आयोजन शुरू कर रहा हूँ, इस परियोजना के लिए डिज़ाइन किए गए पैटर्न को ध्यान में रखते हुए।

कुछ उदाहरण:

1. यदि परियोजना केवल इनपुट डेटा स्क्रीन के निर्माण के लिए पीड़ित है। सबसे शायद मैं एक एमवीसी पैटर्न का उपयोग करूंगा।
2. यदि परियोजना को एक भारी शुल्क यूआई के रूप में इस्तेमाल किया जा रहा है जो अधिकांश प्लेटफार्मों का समर्थन करता है, तो एक एमवीवीएम डीजाइन पैटर्न सहायक हो जाता है।

ध्यान रखें कि इसमें से प्रत्येक आपको एक विशिष्ट तरीके से अपनी परियोजना को व्यवस्थित करने के लिए मजबूर करेगा।

यहाँ आपके लिए कुछ पढ़ना है:

नेट डिजाइन पैटर्न ।

डिजाइन पैटर्न ।

ऑब्जेक्ट ओरिएंटेड डिज़ाइन ।

उम्मीद है की यह मदद करेगा।