"নিম্ন" অ্যাপ্লিকেশন স্তরগুলির জন্য "উচ্চতর "গুলির বিষয়ে সচেতন না হওয়া কেন একটি ভাল ধারণা?

66

একটি টিপিক্যাল (ভাল নকশাযুক্ত) এমভিসি ওয়েব অ্যাপে ডাটাবেসটি মডেল কোড সম্পর্কে সচেতন নয়, মডেল কোডটি নিয়ামক কোড সম্পর্কে সচেতন নয় এবং নিয়ামক কোডটি ভিউ কোড সম্পর্কে সচেতন নয়। (আমি ভাবছি আপনি এমনকি হার্ডওয়ার হিসাবে এমনকি নীচে থেকে শুরু করতে পারেন, অথবা আরও আরও, এবং প্যাটার্নটি একই হতে পারে))

অন্য দিকে যেতে, আপনি কেবল এক স্তর নীচে যেতে পারেন। দর্শনটি নিয়ন্ত্রণকারী সম্পর্কে সচেতন হতে পারে তবে মডেলটি নয়; নিয়ামকটি মডেল সম্পর্কে সচেতন হতে পারে তবে ডেটাবেস নয়; মডেলটি ডাটাবেস সম্পর্কে সচেতন হতে পারে তবে ওএস নয়। (আরও গভীর কিছু সম্ভবত অপ্রাসঙ্গিক।)

আমি স্বজ্ঞাতভাবে বুঝতে পারি যে এটি কেন ভাল ধারণা তবে আমি তা প্রকাশ করতে পারি না। লেয়ারিংয়ের এই একমুখী শৈলীটি কেন একটি ভাল ধারণা?

— জেসন সোয়েট
সূত্র

10

সম্ভবত এটি কারণ ডেটাবেস থেকে ভিউতে ডেটা "আপ" আসে। এটি ডাটাবেসে "শুরু" হয় এবং ভিউতে "আগত" হয়। তথ্য "ভ্রমণ হিসাবে" লেয়ার সচেতনতা বিপরীত দিকে যায়। আমি "উক্তি" ব্যবহার করতে পছন্দ করি।

— জেসন সোয়েট

1

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

— জিমি হোফা

2

নিয়ামক সম্পর্কে সচেতন হওয়ার জন্য বেশিরভাগ ক্ষেত্রে আমার পক্ষে এটি আসলে ভাল অনুশীলন বলে মনে হয় না। যেহেতু কন্ট্রোলাররা প্রায়শই ভিউ সম্পর্কে সচেতন, তাই নিয়ন্ত্রকের সাথে ভিউ অবগত থাকা একটি বিজ্ঞপ্তিগত রেফারেন্স

— এমি ব্লাকনশীপ

8

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

— হাইলেম

1

অবশ্যই একটি দৃশ্য দৃ strongly়ভাবে টাইপ করা ভিউ মডেল সম্পর্কে অবগত।

— DazManCat

121

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

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

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

— কিলিয়ান ফথ
সূত্র

1

"সিস্টেমকে সাধারণ মানুষ দ্বারা বোধগম্য করে" বলতে কী বোঝ ? আমি মনে করি যে এর মতো বাক্যযুক্ত এটি নতুন প্রোগ্রামারদের আপনার ভাল পয়েন্টগুলি প্রত্যাখ্যান করতে উত্সাহিত করে কারণ বেশিরভাগ লোকের মতো তারাও মনে করে যে তারা বেশিরভাগ লোকের চেয়ে স্মার্ট এবং এটি তাদের পক্ষে সমস্যা হবে না। আমি বলব "সিস্টেম মানুষের দ্বারা বোধগম্য করে তোলা"

— টমাস বনিনি

12

যারা সম্পূর্ণ decoupling জন্য চেষ্টা করার আদর্শ মনে করেন তাদের জন্য এটি পড়ার প্রয়োজন, তবে কেন এটি কার্যকর হয় না তা বুঝতে পারি না।

— রবার্ট হার্ভে

6

ঠিক আছে, @ আন্দ্রেয়াস, সবসময় মেল থাকে ।

— ট্রিগ

6

আমি মনে করি "বুঝতে সহজ" যথেষ্ট নয়। কোডটি সংশোধন, প্রসারিত এবং বজায় রাখা আরও সহজ করার বিষয়েও এটি।

— মাইক ওয়েলার

1

@Peri: এই ধরনের একটি আইন কোন অস্তিত্ব নেই দেখতে en.wikipedia.org/wiki/Law_of_Demeter । আপনি এর সাথে একমত হন বা না করেন এটি অন্য বিষয়।

— মাইক চেম্বারলাইন

61

মৌলিক অনুপ্রেরণা হ'ল: আপনি একটি সম্পূর্ণ স্তরটি ছিঁড়ে ফেলতে এবং সম্পূর্ণ আলাদা (পুনর্লিখিত) একটিকে বিকল্প হিসাবে চিহ্নিত করতে এবং নোবিডি'র (বিজ্ঞপ্তি অনুসারে) বিজ্ঞপ্তিটি বিজ্ঞপ্তি দিতে সক্ষম হতে চান।

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

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

এই কাজটি করার একমাত্র উপায় যদি প্রতিটি স্তর উপরের স্তরের একটি পরিচিত, সংজ্ঞায়িত ইন্টারফেস রফতানি করে এবং নীচে স্তরটিতে একটি পরিচিত, সংজ্ঞায়িত ইন্টারফেসের প্রত্যাশা করে।

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

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

স্তরযুক্ত নকশার প্রথম (এবং সর্বোত্তম) ব্যাখ্যা হ'ল ডিজজস্ট্রার ক্লাসিক পেপার "স্ট্রাকচার অফ দ্য মাল্টিপ্রোগ্রামিং সিস্টেম" । এটি এই ব্যবসায়ে পড়া প্রয়োজন।

— জন আর স্ট্রোহম
সূত্র

এটি সহায়ক, এবং লিঙ্কটির জন্য ধন্যবাদ। আমি আশা করি আমি সেরা উত্তর হিসাবে দুটি উত্তর নির্বাচন করতে পারি। আমি মূলত আমার মাথায় একটি মুদ্রা উল্টিয়ে অন্যটিকে বাছাই করেছিলাম, তবে আমি আপনার আপত্তি তুলেছি।

— জেসন সোয়েট

দুর্দান্ত উদাহরণগুলির জন্য +1। আমি

— জেআরএস-এর

@ জেসনসওয়েট: আমি যদি মুদ্রাটি ফ্লিপ করে দিতাম, তবে উত্তরটি নির্দিষ্ট না করা পর্যন্ত আমি এটি উল্টিয়ে ফেলতাম! ^^ +1 জন।

— অলিভিয়ার ডুলাক

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

— অ্যান্ডি

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

— ইভান প্লেইস

8

কারণ উচ্চ স্তরের পরিবর্তন ~~হতে পারে~~ ।

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

4

আমি মনে করি যে প্রধান কারণ এটি জিনিসগুলি আরও দৃ tight়তার সাথে সংযুক্ত করে। এই সংঘটিতকরণটি আরও কঠোর হওয়ার পরে ইস্যুগুলি চালানোর সম্ভাবনা তত বেশি। এই নিবন্ধটি আরও তথ্য দেখুন: দম্পতি

এখানে একটি অংশ:

অসুবিধেও

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

যে কারণে একটি tigher যুগল সিস্টেম আছে কারণ বলা হচ্ছে পারফরম্যান্স কারণে। আমি যে নিবন্ধটি উল্লেখ করেছি সে সম্পর্কেও এই সম্পর্কে কিছু তথ্য রয়েছে।

— barrem23
সূত্র

4

আইএমও, এটি খুব সাধারণ। আপনি এমন কিছু ব্যবহার করতে পারবেন না যা এটি ব্যবহার করা প্রসঙ্গে রেফারেন্স রাখে।

— এরিক রেপেন
সূত্র

4

স্তরের দ্বি-মুখী নির্ভরতা থাকা উচিত নয়

স্তরযুক্ত আর্কিটেকচারের সুবিধাগুলি হ'ল স্তরগুলি স্বাধীনভাবে ব্যবহারের উপযোগী হওয়া উচিত:

আপনার নিম্ন স্তরটি পরিবর্তন না করে প্রথমটির পাশাপাশি একটি পৃথক উপস্থাপনা স্তর তৈরি করতে সক্ষম হওয়া উচিত (যেমন একটি বিদ্যমান ওয়েব ইন্টারফেসের পাশাপাশি একটি API স্তর তৈরি করুন)
আপনার উপরের স্তরটি পরিবর্তন না করে নীচের স্তরটি রিফ্যাক্টর বা শেষ পর্যন্ত প্রতিস্থাপন করতে সক্ষম হওয়া উচিত

এই অবস্থায় হয় মূলত প্রতিসম । তারা ব্যাখ্যা করে যে কেন কেবলমাত্র একটির নির্ভরতার দিকনির্দেশ দেওয়া ভাল তবে কোনটি নয় ।

নির্ভরতার দিক নির্দেশের নির্দেশ অনুসরণ করা উচিত follow

আমরা উপরের নিচে নির্ভরশীলতা কাঠামো কেন পছন্দ করি তার কারণ হ'ল শীর্ষ বস্তু নীচের বস্তুগুলি তৈরি করে এবং ব্যবহার করে । নির্ভরতা মূলত এমন একটি সম্পর্ক যার অর্থ "A B এর উপর নির্ভর করে যদি A বি ছাড়া কাজ করতে না পারে "। সুতরাং A এর অবজেক্টগুলি যদি বি তে অবজেক্টগুলি ব্যবহার করে, তবে নির্ভরশীলতাগুলি এভাবেই চলে।

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

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

একক দিক বজায় রাখার অন্যান্য উপায়ও উদাহরণস্বরূপ:

ধারাবাহিকতা (একটি ল্যাম্বডা বা একটি পদ্ধতিটি অ্যাসিঙ্ক পদ্ধতিতে কল করা এবং ইভেন্টটি পাস করা)
সাবক্লাসিং (বি এর মধ্যে প্যারেন্ট ক্লাসের একটিতে একটি সাবক্লাস তৈরি করুন যা নীচের স্তরে ইনজেকশন দেওয়া হয়, কিছুটা প্লাগইনের মতো)

— Sklivvz
সূত্র

3

আমি ইতিমধ্যে ম্যাট ফেনউইক এবং কিলিয়ান ফথ যা ব্যাখ্যা করেছি তার সাথে আমার দুটি সেন্ট যুক্ত করতে চাই।

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

সুতরাং, একটি স্তরযুক্ত আর্কিটেকচারে নীচের স্তরগুলি হল কালো বক্স যা উপরের স্তরগুলি নির্মিত যার উপরে বিমূর্ত স্তরগুলি প্রয়োগ করে। যদি একটি নিম্ন স্তর (বলুন, স্তর বি) একটি উপরের স্তর ক এর বিশদ দেখতে পারে, তবে বি আর একটি কালো বাক্স নয়: এর বাস্তবায়ন বিশদটি তার নিজস্ব ব্যবহারকারীর কিছু বিবরণের উপর নির্ভর করে, তবে একটি কালো বাক্সের ধারণাটি এটির সামগ্রী (এর বাস্তবায়ন) এর ব্যবহারকারীর জন্য অপ্রাসঙ্গিক!

— জর্জিও
সূত্র

3

শুধুই মজার জন্য.

চিয়ারলিডারদের একটি পিরামিডের কথা ভাবুন। নীচের সারিটি তাদের উপরের সারিগুলিকে সমর্থন করছে।

যদি সেই সারিটির চিয়ারলিডারটি নীচের দিকে তাকিয়ে থাকে তবে তারা স্থিতিশীল এবং তারা ভারসাম্য বজায় থাকবে যাতে তার উপরের লোকেরা যাতে না পড়ে।

যদি তার উপরে দেখানো হয় যে তার উপরে থাকা সবাই কীভাবে কাজ করে তবে সে তার ভারসাম্যটি looseিলা করবে যার ফলে পুরো স্ট্যাকটি নীচে পড়ে যায়।

সত্যিই প্রযুক্তিগত নয়, তবে এটি এমন একটি উপমা ছিল যা আমি ভেবেছিলাম সাহায্য করতে পারে।

— বিল লেপার
সূত্র

3

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

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

উদাহরণটির সাথে চালিয়ে যাওয়ার জন্য, এখন ধরুন A B এবং B এর উপর নির্ভর করে এ I IW এর উপর, একটি বিজ্ঞপ্তি নির্ভরতা। এখন, যে কোনও সময় যে কোনও জায়গায় পরিবর্তন করা গেলে এটি অন্যান্য মডিউলটি সম্ভাব্যভাবে ভেঙে দিতে পারে। বি-তে পরিবর্তন এটিকে এখনও ভেঙে দিতে পারে, তবে এখন এ-তে পরিবর্তনও বি ভেঙে যেতে পারে B.

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

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

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

— ডাঙ্ক
সূত্র

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

— রবভি

1

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

মনে রাখবেন যে "নিম্ন স্তরগুলি" আসলে মাঝারি স্তরগুলি।

এমন কোনও অ্যাপ্লিকেশন সম্পর্কে ভাবুন যা কিছু ডিভাইস ড্রাইভারের মাধ্যমে বাইরের বিশ্বে যোগাযোগ করে। অপারেটিং সিস্টেমটি মাঝখানে রয়েছে ।

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

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

— Kaz
সূত্র

আমি যতক্ষণ না নির্দিষ্ট সিপিইউ

— পিনগুলিতে

1

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

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

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

— মাহমুত কঙ্গা
সূত্র

1

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

কল্পনা করুন যে আপনি একটি নতুন বিকাশকারী স্তরযুক্ত সিস্টেমে একটি বাগ ফিক্সিংয়ের দায়িত্ব পেয়েছেন।

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

এজন্য টপ-ডাউন স্তর সংযোগ থাকা প্রয়োজনীয়। এখন, কেন আমাদের সংযোগগুলি উভয় পথে চলছে না?

ঠিক আছে, আপনার কাছে তিনটি পরিস্থিতি রয়েছে কীভাবে সেই বাগটি ঘটতে পারে।

এটি নিজেই ইউআই কোডে ঘটতে পারে এবং তাই সেখানে স্থানীয়করণ করা যায়। এটি সহজ, আপনার কেবল একটি জায়গা খুঁজে পেতে এবং এটি ঠিক করতে হবে।

এটি ইউআই থেকে কল করার ফলে সিস্টেমের অন্যান্য অংশেও ঘটতে পারে। যা পরিমিতরূপে কঠিন, আপনি কলগুলির একটি গাছ সনাক্ত করে, ত্রুটি হওয়ার জায়গাগুলি খুঁজে বের করে এটি ঠিক করুন।

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

যতটা সম্ভব কেসটি কেটে ফেলার জন্য, বিজ্ঞপ্তি নির্ভরতা দৃ strongly়ভাবে নিরুৎসাহিত করা হয়, স্তরগুলি বেশিরভাগ উপরে-ডাউন ফ্যাশনে সংযুক্ত থাকে। এমনকি অন্য কোনও সংযোগের প্রয়োজন হওয়ার পরেও এটি সাধারণত সীমিত এবং স্পষ্টভাবে সংজ্ঞায়িত হয়। উদাহরণস্বরূপ, কলব্যাকগুলির সাথেও, যা এক ধরণের বিপরীত সংযোগ, কলব্যাকের মধ্যে কল করা কোডটি সাধারণত প্রথমে এই কলব্যাক সরবরাহ করে, বিপরীত সংযোগগুলির জন্য "অপ্ট-ইন" প্রয়োগ করে এবং একটি প্রভাব বোঝার ক্ষেত্রে তাদের প্রভাবকে সীমাবদ্ধ করে দেয় পদ্ধতি.

স্তর স্থাপন একটি সরঞ্জাম এবং মূলত একটি বিদ্যমান সিস্টেমকে সমর্থন করে এমন বিকাশকারীদের লক্ষ্য। ঠিক আছে, স্তরগুলির মধ্যে সংযোগগুলি এটিও প্রতিফলিত করে।

— Kaerber
সূত্র

-1

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

আপনি ড্রাইভার বিকাশ কল্পনা করুন। এটি আপনার কাজ এবং আপনি বেশ গুচ্ছ লিখুন। প্রোটোকল সম্ভবত শারীরিক মিডিয়া হিসাবে কিছু সময় পুনরাবৃত্তি শুরু হতে পারে।

সুতরাং আপনি যা করা শুরু করবেন - যদি না আপনি বার বার একই জিনিস করার দুর্দান্ত অনুরাগী হন - তবে এই বিষয়গুলির জন্য পুনরায় ব্যবহারযোগ্য স্তরগুলি লিখতে হয়।

বলুন আপনাকে Modbus ডিভাইসগুলির জন্য 5 ড্রাইভার লিখতে হবে। এর মধ্যে একটি মোডবাস টিসিপি ব্যবহার করে, দু'জন আরএস ৪85৫-তে মোডবাস ব্যবহার করে এবং বাকীগুলি আরএস 232 এর উপরে চলে যায়। আপনি 5 বার মোডবাসকে পুনরায় প্রতিস্থাপন করতে যাবেন না, কারণ আপনি 5 জন ড্রাইভার লিখছেন। এছাড়াও আপনি মোডবাসকে 3 বার রিম্পিমেন্ট করতে যাচ্ছেন না, কারণ আপনার নীচে 3 টি বিভিন্ন শারীরিক স্তর রয়েছে।

আপনি যা করেন তা হ'ল, আপনি একটি টিসিপি মিডিয়া অ্যাক্সেস, একটি আরএস ৪85৫ মিডিয়া অ্যাক্সেস এবং সম্ভবত একটি আরএস 232 মিডিয়া অ্যাক্সেস লিখেন। এই মুহুর্তে উপরে একটি মোডবাস স্তর হতে চলেছে তা জানা কি স্মার্ট? সম্ভবত না. আপনি যে ড্রাইভারটি প্রয়োগ করতে চলেছেন তারা ইথারনেট ব্যবহার করতে পারে তবে HTTP-REST ব্যবহার করতে পারে। HTTP এর মাধ্যমে যোগাযোগের জন্য যদি আপনাকে ইথারনেট মিডিয়া অ্যাক্সেসটিকে পুনরায় প্রয়োগ করতে হয় তবে এটি লজ্জার বিষয় হবে।

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

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

— juwi
সূত্র

পুনর্ব্যাবহার্যোগ্যতা ইতিমধ্যে একটি ইন স্পষ্টভাবে উল্লিখিত হয়েছে উত্তর অর্ধেক বছর পূর্বে তুলনায় আরো পোস্ট

— মশা