কোনও শ্রেণি বা মডিউলটি কখন পৃথক সমাবেশ / ডিএলএলে থাকতে হবে?

Question

কোনও শ্রেণি তার নিজস্ব সমাবেশ / ডিএলএল এ কখন হওয়া উচিত তা সিদ্ধান্ত নেওয়ার জন্য কি কোনও গাইডলাইন রয়েছে? আমি প্রায়শই দুটি চিন্তা কেন্দ্র দেখি:

1) শ্রেণীর প্রতিটি "গোষ্ঠীকরণ" নিজস্ব ডিএলএল, যেমন সংগ্রহস্থল, পরিষেবা, ডিটিও, পরিকাঠামো ইত্যাদির অন্তর্ভুক্ত belongs

২) সমস্ত কিছু একক ডিএলএলে থাকতে হবে তবে নামস্থান / ফোল্ডারগুলির মাধ্যমে পৃথক করে রাখা উচিত যেমন অতিরিক্ত নেমস্পেসের সাথে একটি "কোর" ডিএলএল থাকতে হবে যেমন Core.Repositories, Core.Services, Core.DTO, ইত্যাদি etc.

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

আমি যে নতুন মডিউলে কাজ করছি তার জন্য আমার পৃথক ডেটা অ্যাক্সেস লেয়ার থাকা প্রয়োজন (একটি প্রাথমিক রিপোসিটরি বাস্তবায়ন মনে করুন) তবে আমি অন্য 160 টির সাথে এটি "বিজনেসঅবজেক্টস" ফোল্ডারের নীচে ফেলে দিতে চাই না (!) সেখানে ক্লাস। একই সাথে আমি নতুন ক্লাস লাইব্রেরি তৈরির বিষয়ে উদ্বিগ্ন যেহেতু প্রত্যেকে একক লাইব্রেরিতে ক্লাস স্টাফ করতে অভ্যস্ত; একটি ফোল্ডার / নেমস্পেস তবে কাজ করতে পারে।

Answer 1

আমি দেখতে পাচ্ছি যে প্রতিটি প্রকল্পে বিভাগের সাথে বিভাগে বিভাগে আরও ভাগ প্রকল্পের (যেমন অ্যাসেমব্লিগুলি) পৃথক নেমস্পেসে এই শ্রেণীর সমস্তগুলির সাথে একটি প্রকল্পের চেয়ে বিভাগ আরও ভাল। আপনার প্রকল্পগুলি পুনরায় ব্যবহারযোগ্য এবং কোনও অ্যাপ্লিকেশনটিতে বিভিন্ন স্তর উপস্থাপন করার লক্ষ্য রাখে aim তারপরে আপনি ভবিষ্যতের অ্যাপ্লিকেশনগুলিতে অপ্রয়োজনীয় ক্লাসের পুরো গুচ্ছটি অন্তর্ভুক্ত না করে সম্ভাব্যভাবে এই প্রকল্পগুলি পুনরায় ব্যবহার করতে পারেন।

উদাহরণস্বরূপ, আপনি যা উল্লেখ করেছেন তার উপর ভিত্তি করে আমার অবশ্যই নিম্নলিখিত প্রকল্পগুলি থাকবে:

• মূল
• উপাত্ত
• ডোমেন (বা বিজনেসঅবজেক্টস)
• সার্ভিস
• ইউটিলিটিস (বা সাহায্যকারী)

Comments

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

— আলেহরো

বিভাগ দ্বারা শ্রেণি ভাগ করে নেওয়া বড় প্রকল্পগুলিতে গোলযোগ সৃষ্টি করে। এগুলি বৈশিষ্ট্য / দিক দিয়ে ভাগ করুন। তারপরে নেমস্পেসগুলি কেবল এই বিভাগটিকে মিরর করবে। এবং পুরো কাঠামো স্পেসিফিকেশন থেকে অভিধান মিরর হবে। বিভাগ অনুসারে শ্রেণি ভাগ করা পরিবর্তনশীল নামে টাইপ সংক্ষেপণ যুক্ত করার মতো - সাধারণত দুর্গন্ধযুক্ত।

— আলেহরো

উভয় প্রস্তাবিত সমাধানের অপব্যবহার করা সহজ (যেমন অনেকগুলি প্রকল্প বা খুব কম)। পুনরায় ব্যবহারযোগ্যতা এবং কম সংযুক্তিকে মাথায় রাখা হয় এমন একটি ভাল ভারসাম্য সন্ধান করার ফলে আরও কিছু পরীক্ষাযোগ্য এবং রক্ষণাবেক্ষণযোগ্য হতে হবে।

— বার্নার্ড

Answer 2

ক্লিন কোডের "চাচা বব" মার্টিন, সলিড নীতিমালা খ্যাতি এখানে তিনটি নীতির রূপরেখা দিয়েছেন :

• রিলিজ রিউজ ইক্যুভ্যালেন্সি নীতি: পুনঃব্যবহারের গ্রানুল হ'ল মুক্তির দানা।
• সাধারণ সমাপ্তির নীতি: একসাথে পরিবর্তিত ক্লাসগুলি এক সাথে প্যাকেজ করা হয়।
• সাধারণ পুনঃব্যবহারের নীতি: একসাথে ব্যবহৃত ক্লাসগুলি একত্রে প্যাকেজ করা হয়।

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

Comments

এই নীতিগুলি +1 ভাল নির্দেশিকা। ক্লাসগুলি পৃথক পৃথক সমাবেশে পৃথক করা অতিরিক্ত নকশার বিবেচনার (উদাহরণস্বরূপ, প্রতিটি সমাবেশের সংস্করণগুলিকে একসাথে কাজ করার অনুমতি দেওয়া হয়) সামগ্রিক কোডবেস বৃদ্ধি করে এইভাবে রক্ষণাবেক্ষণের ব্যয় বাড়িয়ে তোলে increasing

— বেন

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

— বেন

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

— জ্যামাইক্যাক্স

"এক বা একাধিক নির্দিষ্ট ব্যবহারকারীর গল্প বাস্তবায়নের জন্য আপনার যদি এমনটি করার প্রয়োজন হয় তবে বা একক সমাবেশে পরিমাপযোগ্য পারফরম্যান্সের সমস্যা দেখা দিচ্ছে (সাধারণত তারা যখন বেশ কয়েকটি মেগাবাইট আকারে নিয়ে আসে)" কেবলমাত্র সেগুলি বিভক্ত করুন। - সম্পূর্ণরূপে এলোমেলো এবং বাস্তবের পরামর্শে ভিত্তিহীন নয়

— হায়ানকভ

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

— জ্যামাইক্যাক্স

Answer 3

আমি কাজ করি এমন আরও কিছু গাইডিং প্রিনসিপলস:

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

• আপনি কি পুরো প্রকল্পটি পুনরায় স্থাপন / পুনরায় সংশোধন না করে এই কোডটি সংশোধন / মোতায়েন করতে সক্ষম হতে চান? কখনও কখনও এটি কেবল মডিউলটি পুনর্নির্মাণ, ওয়েব অ্যাপ্লিকেশন মোতায়েন এবং পুনঃসূচনা করতে দরকারী।

মনে হচ্ছে আপনার ক্ষেত্রে একটি বেসিক এবং জেনেরিক ভাণ্ডার ভবিষ্যতে আবার কার্যকর হতে পারে, আপনি যদি পারেন তবে এটি একটি নতুন ডিএলএলে আলাদা করা ভাল worth

Comments

আমি মনে করি আপনার দ্বিতীয় পয়েন্টটি সত্যই যুক্তিসঙ্গত। মডিউলগুলিতে ভাগ করার সময় বিকাশ / পরীক্ষা এবং সংকলনের সময় সহায়তা করা উচিত।

— ডাব্লুএম