রুবি অন রেলস দক্ষতা: প্যাটার্ন, অ্যান্টি-প্যাটার্ন এবং সেরা অনুশীলন

রুবি অন রেলস প্যাটার্ন এবং অ্যান্টি-প্যাটার্ন সিরিজের প্রথম পোস্টে আপনাকে স্বাগতম। প্রতিটি পোস্টে, আমরা রেলস অ্যাপের সাথে কাজ করার সময় আপনার সামনে আসতে পারে সকল ধরনের প্যাটার্নে গভীরে उतব।

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

প্যাটার্ন এবং অ্যান্টি-প্যাটার্ন কী সেটি ব্যাখ্যা করার আগে, আমরা কীভাবে এখানে পৌঁছেছি সেটি জানি? আমাদের সফটওয়্যারের জন্য এই সব জিনিস কেন দরকার? আমাদের সমাধান ডিজাইন করার কেন দরকার?

হ্যাঁ, আপনি একজন ডিজাইনার

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

এই সব কথা মনে রেখে, ইঞ্জিনিয়ারদের প্রজন্ম दर প্রজন্ম তাদের ক্যারিয়ার 내내 কোড এবং আর্কিটেকচারে সাদৃশ্য ডিজাইন দেখতে পেয়েছে। লোকরা স্ট্যান্ডার্ড সমাধান এক্সট্র্যাক্ট এবং ডকুমেন্ট করা শুরু করল। কিছু লোক বলতে পারেন এটা মানুষ হিসেবে আমাদের কার্যক্রমের একটি প্রাকৃতিক পদ্ধতি। আমরা সব ক্যাটেগরাইজ করতে এবং সব জিনিসে প্যাটার্ন খুঁজে বের করতে পছন্দ করি, এবং সফটওয়্যার সেটি থেকে বাদ নয়।

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

ডিজাইন প্যাটার্ন কী?

সফটওয়্যার ইঞ্জিনিয়ারিং-এ, একটি প্যাটার্ন বর্ণনা করা হয় একটি সমাধান হিসেবে যেটি রি-ইউজ করা যায় একটি সাধারণ সমস্যা সমাধান করার জন্য। প্যাটার্ন হল কিছু যেটি সফটওয়্যার ইঞ্জিনিয়াররা ভালো অভ্যাস मानেন। যেহেতু সফটওয়্যার ইঞ্জিনিয়াররা সেগুলো সেট করে, সেগুলো দ্রুত প্যাটার্ন থেকে তাদের বিপরীত—অ্যান্টি-প্যাটার্ন—এ পরিবর্তন হতে পারে—but we'll get to that later. (কিন্তু আমরা সেটি পরে জানব।)

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

প্যাটার্ন ল্যাঙ্গুয়েজের আইডিয়া ৭০-এর দশকের শেষে আসে ক্রিস্টফার আলেকজান্ডারের বই A Pattern Language-এ। আপনি অবাক হয়ে যেতে পারেন, কিন্তু বইটি সফটওয়্যার ইঞ্জিনিয়ারিংয়ের সম্পর্কে নয় বরং বিল্ডিং আর্কিটেকচারের সম্পর্কে। প্যাটার্ন ল্যাঙ্গুয়েজ হল একটি সংগঠিত এবং কোহেরেন্ট প্যাটার্ন সেট, যারা প্রতিটি একটি সমস্যা এবং একটি সমাধানের কোর বর্ণনা করে যেটি অনেকভাবে ব্যবহার করা যায়। bekend লাগছে? (হিন্ট: ফ্রেমওয়ার্ক, আরেকটি হিন্ট: রেলস)

পরে, সফটওয়্যার ইঞ্জিনিয়ারিং-এ ডিজাইন প্যাটার্ন বিখ্যাত হয় বড় দর্শকদের কাছে গ্যাং অফ ফোরের পौरাণিক বই Design Patterns দিয়ে যা ১৯৯৪-এ প্রকাশিত হয়েছিল। বইতে প্যাটার্নের ব্যাখ্যা এবং ডেফিনিশন আছে যেগুলো আজকাল ব্যবহৃত হয় — ফ্যাক্টরি, সিঙ্গলটন, ডেকোরেটর, শুধু কিছু নাম বের করার জন্য।

বেশি, এখন যেহেতু আমরা ডিজাইন এবং প্যাটার্ন সম্পর্কে পরিচিত বা আমাদের জ্ঞান রিফ্রেশ করেছি, চলুন জানি অ্যান্টি-প্যাটার্ন কী।

ডিজাইন অ্যান্টি-প্যাটার্ন কী?

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

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

কিন্তু, ছোট আপনি জানতেন না, আপনার বর্তমান জবের ফ্রন্ট এন্ড অ্যাপ্লিকেশনগুলো उतना কমপ্লেক্স নয়, এবং সেগুলো কন্টেইনারে রাখা সবচেয়ে ইফেক্টিভ সমাধান নয়। প্রথমে এটা ভালো আইডিয়া লাগে, কিন্তু পরে রাস্তার নিচে যেতে যেতে সেটি কাউন্টারপ্রোডাক্টিভ সাবিত হয়। এই অ্যান্টি-প্যাটার্নকে বলা হয় "Golden Hammer" (সোনার হাতুড়ি)।

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

এই জিনিসগুলো ঘটে এবং ঘটবে। ভালো লোক খারাপ লোক বনে, এবং বিপরীতও। কিন্তু রুবি এবং রেলস এই ছবিতে কোথায় ফিট হয়?

রুবি প্রথম, তারপর রেলস

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

রেলস ফ্রেমওয়ার্ক ছিল একটি go-to ফ্রেমওয়ার্ক যখন আপনার একটি আইডিয়া থাকত এবং দ্রুত বানাতে চাইতেন। আজকাল, এটি পুরোপুরি আলাদা গল্প, রেলস এখনও ব্যবহৃত হয়, কিন্তু তার প্রাইম টাইমের পরিমাণে নয়। এত সহজে ব্যবহার এবং চালানোর কারণে, অনেক বিগিনার `rails new` কমান্ড ব্যবহার করে তাদের ওয়েব অ্যাপ বানাতে বসে। তখন হয় কী, রাস্তার সাথে সাথে, সমস্যা শুরু হয়। একজন বিগিনার হিসেবে, আপনি রেলসের গতি এবং সাদگی দ্বারা প্রলোভিত হয়েন, এবং সব কিছু যাদু처럼 সুন্দর এবং স্মুথলি কাজ করে প্রথমে। তারপর আপনি দেখেন আপনি অনেক 'যাদু' গ্র্যান্টেড নেওয়া আছে, এবং আপনি বুঝতে পারছেন না পর্দার পেছনে কী হচ্ছে।

আমার এই সমস্যা ছিল, এবং আমি নিশ্চিত অনেক বিগিনার এবং অ্যাডভান্সড বিগিনার এর ভুগছেন। আপনি হাতে একটি ফ্রেমওয়ার্ক নিয়ে শুরু করেন, সেটির ওপর বিল্ড করেন, এবং যখন আপনি কিছু হাইলি কাস্টম যোগ করার চেষ্টা করেন, আপনি পারেন না, কারণ আপনি সেই ফ্রেমওয়ার্ক থেকে সব মэдিক পয়েন্ট ব্যবহার করে ফেলেছেন। সেটি পয়েন্টে, আপনাকে শুরুতে ফিরে যেতে হয় এবং বেসিকস শিখতে হয়। ফিরে যাওয়া কোনো বড় ব্যাপার নয়, বেস্টদের সাথে ও হয়। কিন্তু সমস্যা বড় হয় যদি আপনি এগিয়ে যান এসেনশিয়াল জিনিসগুলো শিখা ছাড়া, যেমন রুবি। এই বিষয়ে আপনাকে সাহায্য করতে একটি ভালো বই হল The Well-Grounded Rubyist।

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

MVC: রেলসের রুটি ও মাখন

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

• মডেল ডেটা এবং বিজনেস লজিক হ্যান্ডেল করে।
• ভিউ ডেটা প্রেজেন্টেশন এবং ইউজার ইন্টারফেসের জন্য।
• কন্ট্রোলার দুটোকে বাঁধে মডেল থেকে ডেটা নিয়ে ইউজারকে ভিউ দেখিয়ে।

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

MVC ওয়েব ডেভেলপমেন্ট কমিউনিটির জুড়ে জঙ্গল আগুন처럼 ছড়িয়ে পড়ল। এমনকি রিয়েক্ট जैसी লাইব্রেরি, যেটি আজকাল পাগলপন জনপ্রিয়, ভিউ লেয়ার হিসেবে বোঝানো হয়। অন্য কোনো প্যাটার্ন এত জনপ্রিয় হয়নি যে সেটি ঝাড়ু দিয়ে দূর করা যায়। রেলস পাবলিশ-সাবস্ক্রাইব একশনকেবলের সাথে যোগ করল, যেখানে চ্যানেলের কনসেপ্টকে MVC প্যাটার্নের কন্ট্রোলার হিসেবে বর্ণনা করা হয়।

কিন্তু অ্যান্টি-প্যাটার্নগুলো কোথায়, এত ব্যাপকভাবে ব্যবহৃত প্যাটার্নে? চলুন MVC-এর প্রতিটি অংশের সবচেয়ে সাধারণ অ্যান্টি-প্যাটার্নগুলো দেখি।

মডেল সমস্যা

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

বিখ্যাত 'ফ্যাট মডেল, স্কিনি কন্ট্রোলার' প্যাটার্ন কেউ কেউ খারাপ লোক বলে চিনেন, কিছু ভালো লোক। আমরা বলব যে ফ্যাট যেকোনো থাকা অ্যান্টি-প্যাটার্ন। ভালো বুঝতে, আসুন একটি উদাহরণে घुसি। কল্পনা করুন আমাদের একটি স্ট্রিমিং সার্ভিস আছে যেমন স্পোটিফাই বা ডিজার। সেটির ভিতরে, গানের জন্য একটি মডেল আছে এইরকম:

class Song < ApplicationRecord belongs_to :album belongs_to :artist belongs_to :publisher has_one :text has_many :downloads validates :artist_id, presence: true validates :publisher_id, presence: true after_update :alert_artist_followers after_update :alert_publisher def alert_artist_followers return if unreleased? artist.followers.each { |follower| follower.notify(self) } end def alert_publisher PublisherMailer.song_email(publisher, self).deliver_now end def includes_profanities? text.scan_for_profanities.any? end def user_downloaded?(user) user.library.has_song?(self) end def find_published_from_artist_with_albums ... end def find_published_with_albums ... end def to_wav ... end def to_mp3 ... end def to_flac ... end end

এই ধরনের মডেলের সমস্যা হল সেগুলো একটি গানের সাথে সম্পর্কিত বিভিন্ন লজিকের ডাম্পিং গ্রাউন্ড হয়ে যায়। এটি হয় মেথডগুলো একে بعد একে করে সময়ের সাথে সাথে যোগ হয়। পুরো মডেলটি বড় এবং কমপ্লেক্স মনে হয়, এবং লজিককে এক Paar অন্য জায়গায় ভাগ করা ভবিষ্যতে উপকারি হতে পারে।

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

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

ফলোয়ার এবং পাবলিশার নোটিফাই করা কলব্যাকগুলো এক্সট্র্যাক্ট করা যায় জবসে। জবগুলো এনকিউ হবে এবং লজিক মডেলের বাইরে থাকবে, এইভাবে:

class NotifyFollowers < ApplicationJob def perform(followers) followers.each { |follower| follower.notify } end end class NotifyPublisher < ApplicationJob def perform(publisher, song) PublisherMailer.song_email(publisher, self).deliver_now end end

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

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

class SongDecorator < Draper::Decorator delegate_all def includes_profanities? object.text.scan_for_profanities.any? end def user_downloaded?(user) object.user.library.has_song?(self) end end

তারপর, আপনি আপনার কন্ট্রোলারে decorate কল করবেন, উদাহরণস্বরূপ:

def show @song = Song.find(params[:id]).decorate end

এবং আপনার ভিউতে এইভাবে ব্যবহার করবেন:

<%= @song.includes_profanities? %> <%= @song.user_downloaded?(user) %>

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

module SongFinders def find_published_from_artist_with_albums ... end def find_published_with_albums ... end end module SongConverter def to_wav ... end def to_mp3 ... end def to_flac ... end end

Song মডেল SongFinders মডিউল এক্সটেন্ড করবে, যাতে এর মেথডগুলো ক্লাস মেথড হিসেবে উপলব্ধ থাকে। Song মডেল SongConverter মডিউল ইনক্লুড করবে, যাতে এর মেথডগুলো মডেল ইনস্ট্যান্সে উপলব্ধ থাকে।

এই সব জিনিস আমাদের Song মডেলকে খুব পাতলা এবং পয়েন্টে আনতে পারে:

class Song < ApplicationRecord extend SongFinders include SongConverter belongs_to :album belongs_to :artist belongs_to :publisher has_one :text has_many :downloads validates :artist_id, presence: true validates :publisher_id, presence: true after_update :alert_artist_followers, if: :published? after_update :alert_publisher def alert_artist_followers NotifyFollowers.perform_later(self) end def alert_publisher NotifyPublisher.perform_later(publisher, self) end end

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

ভিউ সমস্যা

মডেল সমস্যার বাইরে, রেলস ফোকসের লোকরা কখনো কখনো তাদের ভিউর কমপ্লেক্সিটির সাথে স্ট্রাগল করেন। পুরाने দিনে, HTML এবং CSS ভিউ পার্টের রাজা ছিল ওয়েব অ্যাপ্লিকেশনের। ধীরে ধীরে সময়ের সাথে, জাভাস্ক্রিপ্ট রাজ্যে এল, এবং ফ্রন্ট এন্ডের প্রায় সব দিক জাভাস্ক্রিপ্টে লেখা হয়েছে। রেলস এই বিষয়ে কিছুটা আলাদা প্যারাডাইম ফলো করে। ভিউতে সব কিছু জাভাস্ক্রিপ্টে রাখার বদলে, আপনাকে শুধু JS "ছড়িয়ে দিতে" হয়।

যাই হোক, HTML, CSS, JS, এবং রুবি একই জায়গায় হ্যান্ডেল করা গুলগুলি হতে পারে। রেলস ভিউ বানানো যা ট্রিকি সেটি হল ডোমেন লজিক কখনো কখনো ভিউর ভিতরে পাওয়া যায়। এটি একটি নো-নো যেহেতু এটি MVC প্যাটার্ন লঙ্ঘন করে, শুরুতেই।

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

কন্ট্রোলার সমস্যা

রেলস কন্ট্রোলারও বিভিন্ন ধরণের সমস্যা থেকে ভুগতে পারে। उनमें से একটি হল ফ্যাট কন্ট্রোলার অ্যান্টি-প্যাটার্ন।

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

কিছু লোক Trailblazer বা dry-transaction যেন জেম ব্যবহার করে। এখানে আইডিয়া হল ক্লাস তৈরি করা যা নির্দিষ্ট ট্রানজ্যাকশন ডিল করে। কন্ট্রোলার থেকে সব কিছু বের করে এবং মডেলকে পাতলা রাখা, আপনি লজিক স্টোর এবং টেস্ট করুন এই আলাদা ক্লাসগুলোতে, যাকে কেউ সার্ভিস, কেউ ট্রানজ্যাকশন, কেউ অ্যাকশন, এবং অনুরূপ বলে।

উপসংহার

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

পরবর্তীটি পর্যন্ত, চেয়ার্স!

P.S. আপনি যদি রুবি ম্যজিক পোস্টগুলো প্রেস থেকে বের होते সাথে সাথে পড়তে চান, আমাদের রুবি ম্যজিক নিউজলেটার সাবস্ক্রাইব করুন এবং কখনো একটি পোস্টও মিস করবেন না!