হ্যালো হাসিব! আমরা আর্কিটেকচার রিফ্যাক্টরিংয়ের একটি গুরুত্বপূর্ণ থিওরিটিক্যাল অংশে আছি।
তুমি ইন্টারভিউ দিতে গেলে বা কোনো সিনিয়র সফটওয়্যার ইঞ্জিনিয়ারের সাথে আর্কিটেকচার নিয়ে কথা বললে, এই প্রশ্নটা অবধারিতভাবেই আসবে: “আমরা তো সরাসরি Service থেকে DbContext কল করেই সব কাজ করে ফেলতে পারি, তাহলে খামোখা Repository Pattern কেন ব্যবহার করবো?”
এই লেকচারটিতে লেকচারার ঠিক এই প্রশ্নেরই ৩টি সলিড উত্তর দিয়েছেন। চলো পয়েন্টগুলো কুইক সামারি এবং ডিপ ডাইভ করে বুঝে নিই।
📝 Lecture Summary at a Glance
- Loose Coupling: Service Layer (Business Logic) এবং Data Access Layer (DB Logic) আলাদা হয়ে যায়। ফলে ডাটাবেস চেঞ্জ করলে সার্ভিস লেয়ারে হাত দিতে হয় না।
- Easy Migration: ভবিষ্যতে SQL Server থেকে PostgreSQL বা Cloud Data Store-এ শিফট করা অনেক সহজ হয়।
- Simplified Unit Testing:
DbContext-কে মক (Mock) করা খুবই জটিল এবং পেইনফুল। কিন্তু একটিRepositoryইন্টারফেসকে মক করা একদম পানির মতো সহজ। - The Only Drawback: প্রজেক্টে একটি অতিরিক্ত লেয়ার বা ফোল্ডার বেড়ে যায় (Overengineering for small apps)।
🧠 Comprehensive Breakdown & Deep Dive
১. Loosely Coupled Business and Data Access Logic [Importance: 10/10]
- The “Why”: তোমার “Chatrabash” প্রজেক্টের
PersonsServiceক্লাসে তুমি চেক করছো ইউজারের বয়স ১৮ এর ওপরে কিনা, ইমেইল ভ্যালিড কিনা—এগুলো হলো Business Logic। আবার ডাটাবেসে_db.Persons.Add(...)করে সেভ করছো—এটি হলো Data Access Logic। - The Problem: দুটো একসাথে থাকলে তুমি যখন ডাটাবেসের কোনো কোড আপডেট করবে, তখন তোমাকে পুরো বিজনেস লজিকটাও নতুন করে টেস্ট করতে হবে (যাকে Regression Testing বলে)।
- The Solution: রিপোজিটরি প্যাটার্নে সার্ভিস শুধু বলে “ডাটা সেভ করো”। ডাটা কীভাবে সেভ হলো তা রিপোজিটরি জানে। ফলে ডাটাবেসে চেঞ্জ এলে শুধু রিপোজিটরির টেস্ট রান করলেই হয়, সার্ভিস সেভ থাকে।
২. Data Store Migration [Importance: 9/10]
- The “Why”: ধরো তুমি প্রথমে Entity Framework Core (SQL Server) ব্যবহার করে প্রজেক্ট শুরু করলে। ২ বছর পর তোমার ক্লায়েন্ট বললো, “ডাটাবেস অনেক স্লো হয়ে গেছে, চলো আমরা MongoDB বা Dapper (Micro-ORM) ব্যবহার করি।”
- The Repository Magic: তুমি যদি রিপোজিটরি প্যাটার্ন ব্যবহার করে থাকো, তবে তোমার সার্ভিস লেয়ারে এক লাইন কোডও চেঞ্জ করতে হবে না! তুমি জাস্ট
IPersonsRepositoryইমপ্লিমেন্ট করে নতুন একটিMongoPersonsRepositoryক্লাস বানাবে এবংProgram.cs-এ ইনজেকশনটা চেঞ্জ করে দেবে। ম্যাজিকের মতো পুরো ডাটাবেস চেঞ্জ হয়ে যাবে, কিন্তু বিজনেস লজিক ঠিক থাকবে!
৩. Simple Unit Testing (The Game Changer) [Importance: 10/10]
- The “Why”: আমরা এর আগের সেকশনগুলোতে দেখেছি
DbContext-কেMoqএবংEntityFrameworkCoreMockদিয়ে মক করতে গিয়ে কতটা ঝামেলা পোহাতে হয়েছে (যেমনvirtualকিওয়ার্ড অ্যাড করা,NotSupportedExceptionফেস করা)। - The Fix: কিন্তু তুমি যদি
IPersonsRepositoryকে মক করো, তবে সেটি জাস্ট একটা ইন্টারফেস! একটি ইন্টারফেসকে মক করাDbContextমক করার চেয়ে ১০০ গুণ সহজ। এটিই মূলত টেস্টিং-ড্রিভেন ডেভেলপমেন্টের (TDD) সবচেয়ে বড় কারণ। (পরবর্তী লেকচারে আমরা এটি প্র্যাকটিক্যালি দেখবো)।
🚀 When NOT to use Repository Pattern? (The Real-World Truth)
হাসিব, লেকচারার ভিডিওর শেষে যে কথাটি বলেছেন তা খুবই খাঁটি কথা: “It is optional to implement for small projects.” তুমি যখন প্রফেশনাল জগতে যাবে, দেখবে অনেক এক্সপার্ট ডেভেলপার রিপোজিটরি প্যাটার্নের বিপক্ষে কথা বলছেন। এর কারণ কী?
- EF Core itself is a Repository! Entity Framework Core এর
DbSet<T>নিজেই একটি রিপোজিটরি এবংDbContextনিজেই একটি Unit of Work। তাই EF Core-এর ওপরে আরেকটি রিপোজিটরি বসানোকে অনেকেই “Over-engineering” বা “লেয়ারের ওপরে লেয়ার” বলে মনে করেন।
✅ The Final Verdict for You:
- যদি তোমার প্রজেক্ট খুব ছোট হয় এবং তুমি ১০০% শিওর থাকো যে ভবিষ্যতে EF Core বা SQL Server চেঞ্জ করবে না, তবে রিপোজিটরি প্যাটার্ন দরকার নেই। সরাসরি Service থেকে DbContext কল করতে পারো।
- কিন্তু “Chatrabash”-এর মতো এন্টারপ্রাইজ লেভেলের SaaS প্রজেক্ট, যেখানে প্রচুর ইউনিট টেস্ট লিখতে হবে এবং আর্কিটেকচার ক্লিন রাখতে হবে, সেখানে Repository Pattern মাস্ট!
পরবর্তী লেকচারে আমরা দেখবো কীভাবে এই নতুন আর্কিটেকচারে (Repository Pattern-এ) Unit Test লিখতে হয়। তুমি রেডি হলে ট্রান্সক্রিপ্টটি দিতে পারো!