কোনও সমাধানের ফোল্ডারগুলি কি নামের জায়গার সাথে মিলবে?


129

কোনও সমাধানের ফোল্ডারগুলি কি নামের জায়গার সাথে মিলবে?

আমার টিমের একটি প্রকল্পে, আমাদের একটি বর্গ গ্রন্থাগার রয়েছে যার প্রকল্পে অনেকগুলি সাব-ফোল্ডার রয়েছে।

প্রকল্পের নাম এবং নামস্থান: MyCompany.Project.Section

এই প্রকল্পের মধ্যে, বেশ কয়েকটি ফোল্ডার রয়েছে যা নেমস্পেস বিভাগের সাথে মেলে:

  • ফোল্ডারের নেমস্পেসে Vehiclesক্লাস রয়েছেMyCompany.Project.Section.Vehicles
  • ফোল্ডারের নেমস্পেসে Clothingক্লাস রয়েছেMyCompany.Project.Section.Clothing
  • প্রভৃতি

এই একই প্রকল্পের অভ্যন্তরে, অন্য দুর্বৃত্ত ফোল্ডার

  • ফোল্ডারের নেমস্পেসে BusinessObjectsক্লাস রয়েছেMyCompany.Project.Section

এর মতো কয়েকটি কেস রয়েছে যেখানে "সাংগঠনিক সুবিধার্থে" ফোল্ডার তৈরি করা হয়।

আমার প্রশ্ন: মান কী? ক্লাস লাইব্রেরিতে ফোল্ডারগুলি সাধারণত নেমস্পেসের কাঠামোর সাথে মেলে বা এটি একটি মিশ্র ব্যাগ?


9
দ্রষ্টব্য: রিমসার্পার অভিযোগ করবে যদি নেমস্পেসগুলি ফোল্ডার স্তরক্রমের সাথে মেলে না।
ফ্রেড

উত্তর:


77

এছাড়াও, মনে রাখবেন যে আপনি যদি কোনও ফোল্ডারে ক্লাস যুক্ত করতে অন্তর্নির্মিত টেম্পলেটগুলি ব্যবহার করেন তবে এটি ডিফল্টরূপে একটি নেমস্পেসে স্থাপন করা হবে যা ফোল্ডারের স্তরক্রমকে প্রতিফলিত করে।

ক্লাসগুলি সন্ধান করা আরও সহজ হবে এবং একা যথেষ্ট কারণগুলির কারণ হতে হবে।

আমরা যে নিয়মগুলি অনুসরণ করি তা হ'ল:

  • প্রজেক্ট / অ্যাসেমব্লির নাম .dll সমাপ্তি ব্যতীত রুট নেমস্পেসের সমান
  • উপরের নিয়ম ব্যতীত কেবলমাত্র একটি প্রকল্প .Core সমাপ্তি সহ .Core কেটে ফেলা হয়
  • ফোল্ডারগুলির নামস্থান সমান
  • প্রতি ফাইলের এক ধরণের (শ্রেণি, কাঠামো, এনাম, প্রতিনিধি ইত্যাদি) সঠিক ফাইলটি সন্ধান করা সহজ করে তোলে

1
জন্য +1 "উপরের নিয়মের একমাত্র ব্যতিক্রম একটি .Core বিভক্তি সঙ্গে একটি প্রকল্প, .Core খুলে হয়" একা। আমার একটি MyProject.Core.dllসমাবেশ আছে এবং সমস্ত ক্লাস শুরু হয় MyProject.Core.Coreপ্রত্যয়টি ছিটকে যাওয়া আরও বেশি অর্থবোধ করে।
লুইজ দামিম

2
আমি যুক্ত করতে পারি অন্য একটি ব্যতিক্রম ব্যতিক্রম। ব্যতিক্রমগুলি ইতিমধ্যে 'ব্যতিক্রম' এর সাথে প্রত্যয়যুক্ত তাই একটি অতিরিক্ত নাম স্থান অপ্রয়োজনীয়। এটি এক্সপেনশন শব্দের সাথে নেমস্পেসের একটি অংশ থাকার সাথে অগোছালোও হতে পারে (সিস্টেমটি বিভ্রান্তির দিকে নিয়ে যেতে পারে)। তবে এগুলি ফোল্ডারে সংগঠিত করা বেশ সহায়ক।
ফিলিপওয়ে

55

না।

আমি একক (আমি) এবং বিকাশকারীদের একটি দল উভয়ই ছোট এবং বড় প্রকল্পে উভয় পদ্ধতি চেষ্টা করেছি tried

আমি খুঁজে পেয়েছি যে সবচেয়ে সহজ এবং সর্বাধিক উত্পাদনশীল রুটটি ছিল প্রতি প্রকল্পের জন্য একটি একক নেমস্পেস এবং সমস্ত শ্রেণি name নামস্থানে চলে। তারপরে আপনি যে কোনও প্রকল্পের ফোল্ডারগুলিতে যা চান ক্লাস ফাইলগুলি ফ্রি করতে পারেন। কেবলমাত্র একটি একক নেমস্পেস থাকায় সারাক্ষণ ফাইলগুলির শীর্ষে স্টেটমেন্টগুলি যুক্ত করার বিষয়ে কোনও গোলযোগ নেই।

ফোল্ডারগুলিতে উত্স ফাইলগুলি সংগঠিত করা গুরুত্বপূর্ণ এবং আমার মতে যে সমস্ত ফোল্ডারটি ব্যবহার করা উচিত। এই ফোল্ডারগুলিও নেমস্পেসে মানচিত্রের প্রয়োজনীয়তা অপ্রয়োজনীয়, আরও কাজ তৈরি করে, এবং আমি খুঁজে পেলাম যে সংস্থার পক্ষে আসলেই ক্ষতিকারক কারণ যুক্ত হওয়া বোঝাটি বিভাজনকে উত্সাহ দেয়।

উদাহরণস্বরূপ এই FxCop সতর্কতা নিন:

CA1020: কয়েকটি ধরণের
কারণ সহ নেমস্পেসগুলি এড়িয়ে চলুন : গ্লোবাল নেমস্পেস বাদে অন্য একটি নেমস্পেসে পাঁচ ধরণের চেয়ে কম https://msdn.microsoft.com/en-gb/library/ms182130.aspx রয়েছে

এই সতর্কতাটি জেনেরিক প্রজেক্টে নতুন ফাইলগুলির ডাম্পিংকে উত্সাহ দেয় ene জেনারাল ফোল্ডার, এমনকি প্রজেক্টের রুট পর্যন্ত আপনার চারটি ক্লাস না হওয়া পর্যন্ত একটি নতুন ফোল্ডার তৈরি সমর্থনযোগ্য। তা কি কখনও ঘটবে?

ফাইলগুলি সন্ধান করা হচ্ছে

গৃহীত উত্তরটি বলে "ক্লাসগুলি সন্ধান করা আরও সহজ হবে এবং এটি একা যথেষ্ট কারণ হতে হবে।"

আমার সন্দেহ হয় যে উত্তরটি কোনও প্রকল্পে একাধিক নেমস্পেস থাকার কথা উল্লেখ করছে যা ফোল্ডার কাঠামোর মানচিত্র রাখে না, আমি যা প্রস্তাব দিচ্ছি তার চেয়ে একক নেমস্পেসের সাথে একটি প্রকল্প।

নাম স্থান থেকে কোনও শ্রেণীর ফাইল কোন ফোল্ডারে রয়েছে তা আপনি নির্ধারণ করতে না পারার ক্ষেত্রে, আপনি Go To Definition বা ভিজ্যুয়াল স্টুডিওতে অনুসন্ধান সমাধান এক্সপ্লোরার বাক্স ব্যবহার করে এটি সন্ধান করতে পারেন। এছাড়াও এটি আমার মতে সত্যিই বড় সমস্যা নয়। আমি এটির অনুকূলীকরণের জন্য ফাইলগুলি খুঁজে পেতে সমস্যা করতে আমার বিকাশের সময়কালে 0.1% ব্যয় করি না।

নাম সংঘর্ষ

অবশ্যই একাধিক নেমস্পেস তৈরি করা প্রকল্পকে একই নামের সাথে দুটি ক্লাস করার অনুমতি দেয়। কিন্তু আসলেই কি এটি একটি ভাল জিনিস? কেবল সম্ভব হওয়া থেকে এড়িয়ে যাওয়া কি সহজ? একই নামে দুটি ক্লাসের অনুমতি দেওয়া আরও জটিল পরিস্থিতি তৈরি করে যেখানে 90% সময়ের জিনিস নির্দিষ্ট উপায়ে কাজ করে এবং তারপরে হঠাৎ করেই আপনি দেখতে পান যে আপনার একটি বিশেষ কেস রয়েছে। বলুন যে আপনি দুটি আয়তক্ষেত্রের ক্লাস পৃথক নেমস্পেসে সংজ্ঞায়িত করেছেন:

  • বর্গ প্রকল্প 1.আমজ। আয়তক্ষেত্র
  • বর্গ প্রকল্প 1. উইন্ডো। আয়তক্ষেত্র

কোনও উত্স ফাইলের উভয় নেমস্পেস অন্তর্ভুক্ত করা দরকার এমন কোনও সমস্যায় আঘাত করা সম্ভব। এখন আপনাকে সেই ফাইলের যে কোনও জায়গায় পুরো নেমস্পেসটি লিখতে হবে:

var rectangle = new Project1.Window.Rectangle();

বা কিছু বাজে ব্যবহারের বিবৃতি দিয়ে গোলমাল করুন:

using Rectangle = Project1.Window.Rectangle;

আপনার প্রকল্পের একক নেমস্পেসের সাথে আপনাকে আলাদা আলাদাভাবে আসতে বাধ্য করা হবে এবং আমি আরও বর্ণনামূলক, এই জাতীয় নাম যুক্তি দিয়ে যুক্তি দেব:

  • বর্গ প্রকল্প 1
  • বর্গ প্রকল্প 1. উইন্ডো আয়তক্ষেত্র

এবং ব্যবহার সর্বত্র একইরকম, যখন কোনও ফাইল উভয় প্রকারের ব্যবহার করে তখন আপনাকে কোনও বিশেষ ক্ষেত্রে মোকাবেলা করতে হবে না।

বিবৃতি ব্যবহার করে

using Project1.General;  
using Project1.Image;  
using Project1.Window;  
using Project1.Window.Controls;  
using Project1.Shapes;  
using Project1.Input;  
using Project1.Data;  

বনাম

using Project1;

কোড লেখার সময় সর্বদা নেমস্পেস যুক্ত না করার স্বাচ্ছন্দ্য। এটি সত্যিকারের সময় লাগে না, এটি করার প্রবাহে বিরতি এবং কেবলমাত্র প্রচুর বিবৃতি দিয়ে ফাইলগুলি পূরণ করা - কীসের জন্য? এটা কি মূল্য?

প্রকল্পের ফোল্ডার কাঠামো পরিবর্তন করা হচ্ছে

যদি ফোল্ডারগুলি নেমস্পেসে ম্যাপ করা থাকে তবে প্রকল্প ফোল্ডারের পথটি প্রতিটি উত্স ফাইলে কার্যকরভাবে হার্ড-কোডড থাকে। এর অর্থ প্রকল্পের কোনও ফাইল বা ফোল্ডারের যেকোন নাম পরিবর্তন বা সরানোর জন্য প্রকৃত ফাইলের সামগ্রীগুলি পরিবর্তন করা দরকার। উভয়ই সেই ফোল্ডারে ফাইলের নামস্থান ঘোষণা এবং সেই ফোল্ডারে থাকা ক্লাসগুলিকে রেফারেন্স করে এমন অন্যান্য ফাইলের পুরো গোছায় বিবৃতি ব্যবহার করে। পরিবর্তনগুলি নিজেরাই টুলিংয়ের সাথে তুচ্ছ, যদিও এটির ফলাফল সাধারণত অনেকগুলি ফাইল সমন্বিত একটি বৃহত প্রতিশ্রুতিতে আসে যার ক্লাসগুলিও পরিবর্তন হয় নি।

প্রকল্পের একটি একক নেমস্পেসের সাহায্যে আপনি প্রকল্প ফোল্ডার কাঠামো পরিবর্তন করতে পারেন তবে আপনি কোনও উত্স ফাইলগুলি নিজেরাই সংশোধন না করেই চান।

ভিজ্যুয়াল স্টুডিওটি এটির মধ্যে নির্মিত প্রোজেক্ট ফোল্ডারে একটি নতুন ফাইলের নাম স্থানটি স্বয়ংক্রিয়ভাবে মানচিত্র করে

দুর্ভাগ্যজনক, তবে আমি খুঁজে পেয়েছি যে নাম স্থানটি সংশোধন করার ঝামেলা তাদের সাথে আচরণ করার ঝামেলার চেয়ে কম। এছাড়াও আমি অ্যাড-> নতুন ব্যবহার না করে একটি বিদ্যমান ফাইল কপি করার অভ্যাসে চলে এসেছি।

ইন্টেলিজেন্স এবং অবজেক্ট ব্রাউজার

বড় প্রকল্পগুলিতে একাধিক নেমস্পেসগুলি ব্যবহার করার বিষয়ে আমার মতে সবচেয়ে বড় সুবিধা হ'ল নামকরণ ক্ষেত্রের শ্রেণিবিন্যাসে ক্লাস প্রদর্শনকারী কোনও সরঞ্জামাদানের ক্লাসগুলি দেখার সময় অতিরিক্ত সংস্থাগুলি হচ্ছে। এমনকি ডকুমেন্টেশন। স্পষ্টতই প্রকল্পের ফলাফলগুলির মধ্যে কেবলমাত্র একটি নেমস্পেস থাকার ফলে বিভাগগুলিতে ভাঙার পরিবর্তে সমস্ত শ্রেণীর একক তালিকায় প্রদর্শিত হবে। তবে ব্যক্তিগতভাবে আমি এর অভাবের কারণে কখনও স্টাম্পড বা বিলম্বিত হইনি তাই একাধিক নেমস্পেসকে ন্যায়সঙ্গত করার পক্ষে এটি আমার পক্ষে যথেষ্ট বড় সুবিধা বলে মনে হয় না।

যদি আমি একটি বৃহৎ পাবলিক ক্লাস গ্রন্থাগার লেখা ছিল তারপর আমি যদিও হবে সম্ভবত প্রকল্পে একাধিক নামব্যবধান ব্যবহার যাতে সমাবেশ সাধনী দ্বারা প্রয়োগকরণ এবং ডকুমেন্টেশনে ঝরঝরে লাগছিল।


30
এটি আমি শুনেছি এমন সবচেয়ে দুঃস্বপ্ন সমাধানের জন্য সত্যই। আপনি যদি ছোট হ্যালো ওয়ার্ল্ড প্রকল্পগুলিতে কাজ করেন তবে এই পরামর্শটি কার্যকর হয় তবে ভাবুন আপনার কাছে 1000+ .cs ফাইল রয়েছে। এটি এত সমস্যার সৃষ্টি করবে যে আমি কোথায় শুরু করব জানি না।
বেনটনকোডিং

10
"তবে কল্পনা করুন আপনার কাছে 1000+ .cs ফাইল রয়েছে"। আমি একটি একক নেমস্পেসের সাথে সেই আকারের প্রকল্পগুলিতে কাজ করেছি। এটা ভাল. আপনার কি মনে হয় কোন বিপর্যয় ঘটবে?
ওয়েল্যান্ডল্যান্ড ইউটানি

14
ভাবনার জন্য +1 আমি মনে করি না যে আমি আমার প্রকল্পের জন্য আমার নামের স্থানগুলি হ্রাস করতে প্রস্তুত কিন্তু একটি বৃহত ফ্রেমওয়ার্কে কাজ করার পরে আমি বিবৃতি ব্যবহারের সংখ্যা হ্রাস করতে এবং এক্সটেনশন পদ্ধতির আবিষ্কারে সহায়তা করতে নেমস্পেসের সংখ্যা হ্রাস করতে অন্বেষণ করছি। আমি মনে করি এই উত্তরটি চিন্তার জন্য কিছু ভাল খাবার দেয়। ধন্যবাদ।
লি গ্ন

3
@ ওয়েল্যান্ড ইয়ুটানি আমি জানি আমি দেরী করেছি তবে আমার এই কথাটি উল্লেখ করা দরকার: you can find it by using Go To Definition or the search solution explorer box in Visual Studioসর্বদা সত্য নয়। এটি অনেক উত্তরাধিকার এবং ইন্টারফেস সহ চেষ্টা করে দেখুন ... সঠিক ফাইলটি সন্ধানের জন্য শুভকামনা।
এমমানুয়েল এম।

11
এটি আমি দেখেছি এমন সেরা পরামর্শগুলির একটি। নেমস্পেসগুলি কেবল সংঘর্ষের সমাধানের জন্য, শ্রেণি সংগঠনের জন্য নয়। কেবলমাত্র নেমস্পেসগুলি ব্যবহার করুন যেখানে এটি ব্যবহার করার জন্য বোধগম্য হবে যেমন আপনার অন্যান্য প্রকল্পের সাথে নামকরণের বিরোধ রয়েছে যা আপনার প্রকল্প ব্যবহার করছে এমন নির্দিষ্ট নামের স্থানগুলিকে অন্তর্ভুক্ত করার অনুমতি দেয় বা বিবৃতি ব্যবহার করে বাদ দেওয়া হয়। এটি 3 বা 4 বা আরও বেশি নামস্থান যা প্রায়শই ব্যবহৃত হয় তা নিয়ে ভয়ানক টির একটি প্রকল্প রয়েছে কারণ এটি সর্বদা আপনার হাস্যকর সংখ্যার বিবৃতি ব্যবহার করে যা আপনাকে যুক্ত করতে এবং যুক্ত করতে এবং যুক্ত করতে হবে। আপনার প্রকল্পগুলি বিচ্ছিন্ন করুন।
ট্রায়ঙ্কো

31

আমি মনে করি। নেট এর মধ্যে স্ট্যান্ডার্ডটি হ'ল সম্ভব হলে এটি করার চেষ্টা করা তবে এটি একটি কঠোর নিয়ম হিসাবে মেনে চলার জন্য অযথা গভীর কাঠামো তৈরি করা নয়। আমার প্রকল্পগুলির কোনওটিই নেমস্পেস == কাঠামো নিয়মের 100% সময় অনুসরণ করে না, কখনও কখনও এটি কেবল পরিষ্কার / এই জাতীয় নিয়মগুলি থেকে বেরিয়ে আসা ভাল।

জাভাতে আপনার কোনও পছন্দ নেই। আমি কল করতে চাই যে বাস্তবে যা তত্ত্বে যা কাজ করে তার একটি সর্বোত্তম কেস।


1
আমি বলব "যখন আপনি সত্যিকার অর্থে নিজের নামের জায়গায় থাকতে চান তখন এটি করুন"। এটি একটি সচেতন সিদ্ধান্ত হওয়া উচিত। যদি আপনার প্রকল্পগুলি যথাযথভাবে বিচ্ছিন্ন হয় তবে প্রতি প্রকল্পে এটির একটি নামস্থান হওয়া উচিত। যদি আপনার শ্রেণিটি কোনও একটি নেমস্পেসে থাকে, তবে এটি সেই নেমস্পেসের একটি ফোল্ডারে বা একটি সাবফোল্ডার অবস্থানের মধ্যে থাকা উচিত যা অন্ততপথ নেমস্পেসের মতো নির্দিষ্ট । কার.ফোর্ড.ফিউশন (যেমন কার.ফোর্ড আপনার একমাত্র নামস্থান) এর মতো একটি বর্গ কার / ফোর্ডের মতো ফোল্ডারে বা গাড় / ফোর্ড / সেডানসের মতো গভীরতর ফোল্ডারে থাকতে হবে যেমন ফোল্ডারটি অন্তত নেমস্পেসের মতো নির্দিষ্ট। কেবল এটিকে গাড় / আনলেটেড / ফোর্ডে রাখবেন না; এটি বিভ্রান্তিকর
ট্রায়ঙ্কো

25

@ লাসেভেক: আমি এই নিয়মগুলির সাথে একমত, এবং আরও একটি যুক্ত করার আছে।

আমি যখন ক্লাস করে নেস্ট করেছি, তখনও আমি সেগুলি ভাগ করে নিই, প্রতি ফাইলের জন্য একটি। এটার মত:

// ----- Foo.cs
partial class Foo
{
    // Foo implementation here
}

এবং

// ----- Foo.Bar.cs
partial class Foo
{
    class Bar
    {
        // Foo.Bar implementation here
    }
}

5

আমি হ্যাঁ বলব।

প্রথমে নেমস্পেসগুলি অনুসরণ করে প্রকৃত কোড ফাইলগুলি খুঁজে পাওয়া সহজ হবে (বলুন, যখন কেউ আপনাকে একটি নগ্ন ব্যতিক্রম কল স্ট্যাক ইমেল করে)। যদি আপনি আপনার ফোল্ডারগুলিকে নেমস্পেসের সাথে সিঙ্কের বাইরে যেতে দেন তবে বড় কোডবেসে ফাইলগুলি খুঁজে পাওয়া ক্লান্তিকর হয়ে ওঠে।

দ্বিতীয়ত, ভিএস তার মূল ফোল্ডারের কাঠামোর একই নাম স্থান সহ আপনি ফোল্ডারে নতুন ক্লাস তৈরি করবে। আপনি যদি এর বিরুদ্ধে সাঁতার কাটতে স্থির করেন তবে নতুন ফাইল যুক্ত করার সময় এটি করা কেবলমাত্র আরও একটি নদীর গভীরতানির্ণয় কাজ হবে।

অবশ্যই, এটি বলা ছাড়াই যায় যে গভীর Xis ফোল্ডার / নেমস্পেসের স্তরক্রমটি কীভাবে যায় সে সম্পর্কে রক্ষণশীল হওয়া উচিত।


4

হ্যাঁ তাদের উচিত, অন্যথায় বিভ্রান্তির দিকে নিয়ে যায়।


2

মান কী?

কোনও অফিশিয়াল স্ট্যান্ডার্ড নেই তবে প্রচলিতভাবে ফোল্ডার-টু-নেমস্পেস ম্যাপিং প্যাটার্নটি বহুল ব্যবহৃত হয়।

ক্লাস লাইব্রেরিতে ফোল্ডারগুলি সাধারণত নেমস্পেসের কাঠামোর সাথে মেলে বা এটি একটি মিশ্র ব্যাগ?

হ্যাঁ, বেশিরভাগ শ্রেণিবদ্ধ লাইব্রেরিতে ফোল্ডারগুলি সাংগঠনিক স্বাচ্ছন্দ্যের জন্য নেমস্পেসের সাথে মেলে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.