উপযুক্ত iOS আর্কিটেকচারটি কীভাবে চয়ন করবেন (পার্ট 2)

এমভিসি, এমভিপি, এমভিভিএম, ভিআইপিআর বা ভিআইপি

আপনি এখানে প্রথম অংশ পরামর্শ করতে পারেন।

সবচেয়ে গুরুত্বপূর্ণ আইওএস আর্কিটেকচার

একটি সংক্ষিপ্ত বর্ণনা.

এমভিসি

এমভিসি স্তরগুলি নিম্নরূপ:

এম: ব্যবসায়িক যুক্তি, নেটওয়ার্ক স্তর এবং ডেটা অ্যাক্সেস স্তর

ভি: ইউআই স্তর (ইউআইকিট অবজেক্টস, স্টোরিবোর্ড, এক্সবস)

সি: মডেল এবং দর্শনের মধ্যস্থতা সমন্বয় করে ates

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

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

এমভিসি চক্রের একটি উদাহরণ:

  1. একটি ব্যবহারকারীর ক্রিয়া / দর্শন স্তরের কোনও ব্যবহারকারীর ইভেন্ট (উদাঃ "আপডেট অ্যাকশন") ট্রিগার করা হয় এবং এই ক্রিয়াটি নিয়ামকের কাছে জানানো হয়
  2. নিয়ন্ত্রণকারী যা মডেল স্তরে ডেটা প্রেরণ করে
  3. নিয়ন্ত্রকের কাছে ফিরে আসা ডেটা মডেল করুন
  4. নিয়ামক বলছেন যে ভিউটি তার নতুন স্ট্যাটাসের সাথে তার স্থিতি আপডেট করবে
  5. এর আপডেট আপডেট দেখুন

অ্যাপল এমভিসি

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

ভিউকন্ট্রোলারটিতে মডেলটি দেখুন এবং তার মালিকানাধীন। সমস্যাটি হ'ল আমরা কন্ট্রোলার কোড এবং ভিউ কোড উভয়ই ভিউকন্ট্রোলারে লিখছি।

এমভিসি প্রায়শই যাকে বলে ম্যাসিভ ভিউ কন্ট্রোলার সমস্যা হিসাবে ডেকে আনে, তবে এটি কেবলমাত্র পর্যাপ্ত জটিলতাযুক্ত অ্যাপগুলিতে ঘটে এবং গুরুতর ব্যবসায় হয়ে ওঠে।

কিছু নিয়মিত পদ্ধতি রয়েছে যা বিকাশকারী নিয়ামককে আরও পরিষ্কার করার জন্য ব্যবহার করতে পারেন। কিছু উদাহরণ:

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

এমভিসি বনাম এমভিপি

আপনি যেমন এমভিপির ডায়াগ্রামটি দেখতে পাচ্ছেন, এমভিসি খুব সাদৃশ্যপূর্ণ

এমভিসি এক ধাপ এগিয়ে ছিল, তবে এটি এখনও কিছু বিষয় সম্পর্কে অনুপস্থিতি বা নীরবতার দ্বারা চিহ্নিত ছিল।

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

এমভিসিতে, আমার মতে, এমন কোনও ইঙ্গিত নেই যে নিয়ন্ত্রণকারীর ভিউ (অনুপস্থিতি) এর নির্দিষ্ট প্রয়োগটি না জানা উচিত।

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

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

উপস্থাপনা যুক্তি হ'ল যুক্তি যা ব্যবহারকারী ইন্টারফেসটি প্রদর্শিত হবে এবং ব্যবহারকারী ইন্টারফেস উপাদানগুলি একে অপরের সাথে কীভাবে ইন্টারঅ্যাক্ট করে তা নিয়ন্ত্রণ করে। একটি লোডিং সূচক কখন প্রদর্শিত / অ্যানিমেটিং শুরু করা উচিত এবং কখন এটি প্রদর্শন / অ্যানিমেট করা বন্ধ করে দেওয়া উচিত তার নিয়ন্ত্রণ যুক্তি example

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

এমভিসির একটি সমস্যা হ'ল এটি উপস্থাপনার যুক্তিটি কোথায় যাওয়া উচিত তা পরিষ্কার নয়। তিনি এ সম্পর্কে খালি নীরব। উপস্থাপনা যুক্তিটি ভিউ স্তরে বা মডেল স্তরে হওয়া উচিত?

যদি মডেলটির ভূমিকাটি কেবল "কাঁচা ডেটা" সরবরাহ করে তবে এর অর্থ হল ভিউটিতে কোডটি নিম্নরূপ:

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

যদি মডেলের ভূমিকাটি "কাঁচা ডেটা" সরবরাহ করা হয়, তার মানে হল যে ভিউটিতে কোডটি নিম্নরূপ:

প্রথমে নাম = ব্যবহারকারীমোডেল.সেট ফার্স্টনাম () এর সর্বশেষ নাম = ব্যবহারকারীমোডেল.সেটলাস্টনেম () নাম লেবেল.টেক্সট = শেষ নাম + "," + প্রথম নাম দিন

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

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

নাম = userModel.getDisplayName () nameLabel.text = নাম দিন

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

সাধারণত এমভিপি বাস্তবায়নে একটি ইন্টারফেস / প্রোটোকলের পিছনে ভিউটি লুকানো থাকে এবং উপস্থাপকটিতে ইউআইকিট সম্পর্কিত কোনও রেফারেন্স থাকতে হবে না।

আর একটি বিষয় লক্ষ্যণীয় হ'ল ট্রানজিটিভ নির্ভরতা।

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

বিভিন্ন স্তরও বিভিন্ন কারণে এবং বিভিন্ন হারে পরিবর্তিত হয়। সুতরাং আপনি যদি একটি স্তর স্যুইচ করেন তবে এটি অন্যান্য স্তরে গৌণ প্রভাব / সমস্যা সৃষ্টি করার কথা নয়।

প্রোটোকলগুলি ক্লাসের চেয়ে বেশি স্থিতিশীল। লগগুলিতে কোনও প্রয়োগের বিবরণ থাকে না এবং চুক্তিতে লিঙ্ক থাকে না। অতএব, অন্য স্তরের উপর প্রভাব ফেলে না করেই এক স্তরের প্রয়োগের বিশদ পরিবর্তন করা সম্ভব।

চুক্তিগুলি (প্রোটোকল) স্তরগুলির মধ্যে একটি ডিউপলিং তৈরি করে।

এমভিপি বনাম এমভিভিএম

এমভিভিএম ডায়াগ্রাম

এমভিপি এবং এমভিভিএমের মধ্যে প্রধান পার্থক্যগুলির মধ্যে একটি হ'ল এমভিপিতে উপস্থাপক ইন্টারফেসের সাথে ইন্টারফেস করে এবং এমভিভিএম-এ ভিউটি ডেটা এবং ইভেন্টের পরিবর্তনের উপর দৃষ্টি নিবদ্ধ করে।

এমভিপিতে আমরা উপস্থাপক এবং ইন্টারফেস / প্রোটোকল ব্যবহার করে দেখার মধ্যে একটি ম্যানুয়াল লিঙ্ক তৈরি করি। এমভিভিএম-এ আমরা আরএক্সএসউইফ্ট, কেভিও বা জেনেরিকস এবং ক্লোজারগুলির সাথে একটি প্রক্রিয়াটির সাথে একটি স্বয়ংক্রিয় ডেটা বাঁধাই করি।

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

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

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

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

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

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

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

পড়ার জন্য আপনাকে ধন্যবাদ! আপনি যদি এই নিবন্ধটি উপভোগ করেছেন তবে দয়া করে তালি দাও যাতে অন্যরাও এটি পড়তে পারে :)