যখনই কোনও বিকাশকারী "এটি করার অর্থ কী?" জিজ্ঞাসা করেন, তাদের সত্যিকারের অর্থ হ'ল "আমি কোনও ব্যবহারের ক্ষেত্রে দেখি না যেখানে এটি করার ফলে কোনও সুবিধা পাওয়া যায়"। সেই লক্ষ্যে, আমি আপনাকে কয়েকটি উদাহরণ দেখাব।
সমস্ত উদাহরণ এই সাধারণ ডেটা মডেলের উপর ভিত্তি করে তৈরি করা হবে:
একটি Personসত্তার পাঁচটি বৈশিষ্ট্য রয়েছে:Id, FirstName, LastName, Age, CityId
এবং আপনি ধরে নিতে পারেন যে অ্যাপ্লিকেশনটি এই ডেটাটি বিভিন্ন ধরণের (রিপোর্ট, ফর্ম, পপআপ, ...) ব্যবহার করে।
পুরো অ্যাপ্লিকেশন ইতিমধ্যে বিদ্যমান। আমি যে সমস্ত বিষয় উল্লেখ করেছি তা হ'ল বিদ্যমান কোডবেসে পরিবর্তন। এটি মনে রাখা গুরুত্বপূর্ণ।
উদাহরণ 1 - অন্তর্নিহিত ডেটা কাঠামো পরিবর্তন করা - ডিটিও ছাড়াই
প্রয়োজনীয়তা পরিবর্তন হয়েছে। সরকারের ডেটাবেস থেকে ব্যক্তির বয়স গতিশীলভাবে পুনরুদ্ধার করা দরকার (আসুন তাদের প্রথম এবং শেষ নামের ভিত্তিতে ধরে নেওয়া যাক)।
যেহেতু আপনাকে Ageআর স্থানীয়ভাবে মান সংরক্ষণ করার দরকার নেই, সুতরাং এটি Personসত্তা থেকে অপসারণ করা দরকার । এটি উপলব্ধি করা এখানে গুরুত্বপূর্ণ যে সত্তা ডাটাবেস ডেটা এবং আরও কিছু উপস্থাপন করে । এটি ডাটাবেসে না থাকলে এটি সত্তায় নেই in
আপনি যখন সরকারের ওয়েব পরিষেবা থেকে বয়সটি পুনরুদ্ধার করবেন, তখন এটি কোনও ভিন্ন অবজেক্টে (বা কোনও int) সংরক্ষণ করা হবে।
তবে আপনার সীমানা এখনও একটি বয়স প্রদর্শন করে। সমস্ত দর্শন Person.Ageসম্পত্তি ব্যবহার করার জন্য সেট আপ করা হয়েছে , যা এখন আর নেই। একটি সমস্যা নিজেকে উপস্থাপন করে: কোনও ব্যক্তির মতামত উল্লেখ করে এমন সমস্ত মতামত Ageসংশোধন করা দরকার ।
উদাহরণ 2 - অন্তর্নিহিত ডেটা কাঠামো পরিবর্তন করা - ডিটিও সহ
পুরাতন সিস্টেম, সেখানে হয় PersonDTOএকই পাঁচটি বৈশিষ্ট্য সঙ্গে সত্তা: Id, FirstName, LastName, Age, CityId। একটি পুনরুদ্ধার করার পরে Person, পরিষেবা স্তরটি এটিকে রূপান্তর করে PersonDTOএবং তারপরে এটি ফিরিয়ে দেয়।
তবে এখন, প্রয়োজনীয়তা পরিবর্তন হয়েছে। সরকারের ডেটাবেস থেকে ব্যক্তির বয়স গতিশীলভাবে পুনরুদ্ধার করা দরকার (আসুন তাদের প্রথম এবং শেষ নামের ভিত্তিতে ধরে নেওয়া যাক)।
যেহেতু আপনাকে Ageআর স্থানীয়ভাবে মান সংরক্ষণ করার দরকার নেই, সুতরাং এটি Personসত্তা থেকে অপসারণ করা দরকার । এটি উপলব্ধি করা এখানে গুরুত্বপূর্ণ যে সত্তা ডাটাবেস ডেটা এবং আরও কিছু উপস্থাপন করে । এটি ডাটাবেসে না থাকলে এটি সত্তায় নেই in
যাইহোক, যেহেতু আপনি একটি মধ্যবর্তী আছে PersonDTO, এটা গুরুত্বপূর্ণ দেখতে এই শ্রেণীর পারেন রাখাAge সম্পত্তি। পরিষেবা স্তরটি আনবে Person, এটিকে রূপান্তরিত করবে PersonDTO, এটি তার পরে সরকারের ওয়েব পরিষেবা থেকে ব্যক্তির বয়স আনবে, সেই মানটি সংরক্ষণ করবে PersonDTO.Ageএবং সেই বস্তুকে পাস করবে।
এখানে গুরুত্বপূর্ণ অংশটি হ'ল যে কেউ পরিষেবা স্তরটি ব্যবহার করেন সে পুরানো এবং নতুন সিস্টেমের মধ্যে পার্থক্য দেখতে পাবে না । এটিতে আপনার অগ্রভাগ অন্তর্ভুক্ত। পুরানো সিস্টেমে এটি একটি সম্পূর্ণ PersonDTOবস্তু পেয়েছে । এবং নতুন সিস্টেমে এটি এখনও একটি সম্পূর্ণ PersonDTOবস্তু গ্রহণ করে । মতামতগুলি আপডেট করার দরকার নেই ।
আমরা যখন উদ্বেগের পৃথকীকরণটি বাক্যাংশটি ব্যবহার করি তখন এর অর্থ আমরা এই : দুটি আলাদা উদ্বেগ রয়েছে (ডাটাবেসে ডেটা সংরক্ষণ করে, উপস্থানে ডেটা উপস্থাপন করা) এবং তাদের প্রতিটি আলাদা আলাদা ডেটা টাইপের দরকার হয় need এমনকি যদি এখনই সেই দুটি ডেটা ধরণের একই ডেটা থাকে তবে ভবিষ্যতে এটি পরিবর্তিত হতে পারে।
প্রদত্ত উদাহরণে, Ageদুটি তথ্য প্রকারের মধ্যে একটি পার্থক্য: Person(ডাটাবেস সত্তা) এর কোনও প্রয়োজন নেই Age, তবে PersonDTO(সীমান্তের ডেটা টাইপ) এর প্রয়োজন নেই।
উদ্বেগগুলি (= পৃথক ডেটা ধরণের তৈরি করা) শুরু থেকে আলাদা করে, কোডবেস ডেটা মডেলটিতে করা পরিবর্তনগুলিতে অনেক বেশি স্থিতিস্থাপক।
আপনি তর্ক করতে পারেন যে একটি ডিটিও অবজেক্ট থাকাকালীন, যখন একটি নতুন কলামটি ডাটাবেসে যুক্ত হয়, তার অর্থ আপনাকে দ্বিগুণ কাজ করতে হবে, সত্তা এবং ডিটিও উভয় ক্ষেত্রেই সম্পত্তি যুক্ত করতে হবে। এটি প্রযুক্তিগতভাবে সঠিক। এটির পরিবর্তে দুটি ক্লাস বজায় রাখতে কিছুটা অতিরিক্ত প্রচেষ্টা প্রয়োজন।
যাইহোক, আপনার প্রয়োজনীয় প্রচেষ্টাটির তুলনা করতে হবে। যখন এক বা একাধিক নতুন কলাম যুক্ত হয়, কয়েকটি বৈশিষ্ট্য অনুলিপি / আটকানো এত বেশি সময় নেয় না। যখন ডেটা মডেলটি কাঠামোগতভাবে পরিবর্তিত হয়, সীমান্ত পরিবর্তন করতে হয়, সম্ভবত রানটাইম (এবং সংকলনের সময় নয়) যে কারণে বাগগুলি ঘটে তার জন্য যথেষ্ট বেশি প্রচেষ্টা গ্রহণ করা হয় এবং এর জন্য বিকাশের জন্য বিকাশকারীদের প্রয়োজন হয়।
আমি আপনাকে আরও উদাহরণ দিতে পারলাম তবে নীতিটি সর্বদা একই থাকবে।
সংক্ষেপ
- পৃথক দায়িত্ব (উদ্বেগ) একে অপরের থেকে পৃথকভাবে কাজ করা প্রয়োজন। তাদের কোনও সংস্থান যেমন ডেটা ক্লাস (যেমন
Person) ভাগ করা উচিত নয়
- কেবল কোনও সত্তা এবং এর ডিটিওর একই বৈশিষ্ট্য রয়েছে তার অর্থ এই নয় যে আপনাকে সেগুলি একই সত্তায় মার্জ করা দরকার। কোণ কাটাবেন না।
- আরও স্পষ্ট উদাহরণ হিসাবে, আসুন আমরা আমাদের ডাটাবেসে দেশ, গান এবং মানুষ ধারণ করি। এই সমস্ত সত্তা একটি
Name। তবে কেবলমাত্র তাদের সবার Nameসম্পত্তি থাকার অর্থ এই নয় যে আমাদের তাদের ভাগ করা EntityWithNameবেস শ্রেণীর কাছ থেকে উত্তরাধিকারী করা উচিত । বিভিন্ন Nameবৈশিষ্ট্যের কোনও অর্থপূর্ণ সম্পর্ক নেই।
- বৈশিষ্ট্যগুলির মধ্যে কোনওটি যদি কখনও পরিবর্তিত হয় (যেমন কোনও গানের
Nameনাম বদলে যায় Title, বা কোনও ব্যক্তি পায় FirstNameএবং LastName), তাদের আপনাকে যে উত্তরাধিকারটির প্রথম স্থানটিতেও প্রয়োজন ছিল না, সেই উত্তরাধিকারটি পূর্বাবস্থায় ফেরানোর জন্য আরও বেশি ব্যয় করতে হবে ।
- যদিও নির্লজ্জ নয়, আপনার যুক্তি যে কোনও সত্তা থাকলে আপনার কোনও ডিটিও প্রয়োজন হয় না need আপনি এখন খুঁজছেন , কিন্তু আপনি ভবিষ্যতের কোনও পরিবর্তনের জন্য প্রস্তুত নন। যদি সত্তা এবং DTO ঠিক একই আছে, এবং যদি আপনি গ্যারান্টি করতে পারে সেখানে তথ্য মডেল কোনো পরিবর্তন হবে না; তাহলে আপনি সঠিক যে আপনি ডিটিও বাদ দিতে পারেন। তবে বিষয়টি হ'ল আপনি কখনই গ্যারান্টি দিতে পারবেন না যে ডেটা মডেলটি কখনই বদলে যাবে না।
- ভাল অনুশীলন সবসময় অবিলম্বে পরিশোধ করা হয় না। ভবিষ্যতে এটি পরিশোধ করা শুরু হতে পারে, যখন আপনাকে কোনও পুরানো অ্যাপ্লিকেশনটি পুনরায় দেখা দরকার।
- বিদ্যমান কোডবেসগুলির প্রধান হত্যাকারী কোডের মান কমিয়ে দেওয়া, ক্রমাগত কোডবেস বজায় রাখা আরও কঠিন করে তোলে যতক্ষণ না এটি স্প্যাগেটি কোডের অকেজো জগতে পরিণত হয় যতক্ষণ না এটি কল্পনাযোগ্য।
- যথাসম্ভব দীর্ঘকাল ধরে কোডবেসকে বজায় রাখার জন্য উত্তম অনুশীলন, যেমনটি পাওয়া থেকে উদ্বেগের পৃথকীকরণ বাস্তবায়ন করার লক্ষ্যে খারাপ রক্ষণাবেক্ষণের সেই পিচ্ছিল opeালটিকে এড়াতে লক্ষ্য করা।
চিন্তার বিভাজন বিবেচনা করার জন্য থাম্বের নিয়ম হিসাবে, এটিকে এভাবে ভাবুন:
মনে করুন যে প্রতিটি উদ্বেগ (ইউআই, ডাটাবেস, যুক্তি) একটি ভিন্ন লোকের দ্বারা পৃথক স্থানে পরিচালিত হয়। তারা কেবল ইমেলের মাধ্যমে যোগাযোগ করতে পারে।
একটি পৃথক পৃথক কোডবেজে, কোনও নির্দিষ্ট উদ্বেগের পরিবর্তনের জন্য কেবলমাত্র একজন ব্যক্তির দ্বারা পরিচালিত হওয়া প্রয়োজন:
- ব্যবহারকারী ইন্টারফেস পরিবর্তন শুধুমাত্র UI দেব জড়িত।
- ডেটা স্টোরেজ পদ্ধতি পরিবর্তন করতে কেবল ডেটাবেস ডিভ জড়িত।
- ব্যবসায়ের যুক্তি পরিবর্তন করা কেবলমাত্র ব্যবসায় ডেভ এর সাথে জড়িত।
যদি এই বিকাশকারীরা সকলেই একই Personসত্তা ব্যবহার করত এবং সত্তায় একটি সামান্য পরিবর্তন করা হয়, তবে প্রত্যেককে এই প্রক্রিয়াতে যুক্ত হতে হবে।
তবে প্রতিটি স্তরের জন্য পৃথক ডেটা ক্লাস ব্যবহার করে, সমস্যাটি তেমন প্রচলিত নয়:
- যতক্ষণ ডেটাবেস ডেভ কোনও বৈধ
PersonDTOঅবজেক্ট ফিরিয়ে দিতে পারে ততক্ষণ ব্যবসায় এবং ইউআই দেব কোনওভাবেই ডেটা সংরক্ষণ / পুনরুদ্ধার করে কীভাবে পরিবর্তন করেছে তা সে চিন্তা করে না।
- যতক্ষণ না ব্যবসায় ডেটাবেস ডাটাবেসে ডেটা সঞ্চয় করে এবং সীমান্তে প্রয়োজনীয় ডেটা সরবরাহ করে, ডাটাবেস এবং ইউআই ডেভস তার ব্যবসায়ের নিয়মগুলি পুনরায় কাজ করার সিদ্ধান্ত নিয়েছে কিনা সেদিকে খেয়াল রাখে না।
- যতক্ষণ না ইউআই designed পার্সোনভিউমোডেলের চারপাশে ডিজাইন করা যায় ততক্ষণ ইউআই দেব তারা চাইলে ইউআই তৈরি করতে পারে। এটি কীভাবে এটি করা হয় তা ডেটাবেস এবং ব্যবসায় ডেভসগুলি যত্ন করে না, কারণ এটি তাদের প্রভাবিত করে না।
এখানে মূল বাক্যাংশ যেহেতু এটি তাদের প্রভাবিত করে না । উদ্বেগের একটি ভাল বিভাজন কার্যকর করা অন্যান্য পক্ষগুলিকে প্রভাবিত করে (এবং তাই জড়িত থাকতে হবে) হ্রাস করার চেষ্টা করে।
অবশ্যই, কিছু বড় পরিবর্তন একাধিক ব্যক্তিকে অন্তর্ভুক্ত করতে পারে না, যেমন যখন সম্পূর্ণ নতুন সত্তা ডাটাবেসে যুক্ত হয় to তবে কোনও অ্যাপ্লিকেশন চলাকালীন আপনাকে যে পরিমাণ ছোটখাটো পরিবর্তন করতে হবে তা হ্রাস করবেন না। বড় পরিবর্তনগুলি একটি সংখ্যালঘু সংখ্যালঘু।
What's the benefit of these conversions?ভোক্তাদের দেওয়া ডেটা মডেল (উপস্থাপনা) থেকে অধ্যবসায় ডেটা মডেলটিকে ডিক্লুপিং করা। এসইতে ডিকপলিংয়ের সুবিধাগুলি ব্যাপকভাবে আলোচনা করা হয়েছে তবে, ডিটিওর নীচে লক্ষ্য ছিল ক্লায়েন্টদের সার্ভারে কলগুলি সংরক্ষণের জন্য প্রয়োজনীয় হিসাবে বিবেচিত অনেকগুলি তথ্য এককভাবে জড়ো করা। যোগাযোগ ক্লায়েন্ট-সার্ভারকে কি মসৃণ করে তোলে।