Spring Data JPA থেকে Spring Data JDBC-তে মাইগ্রেশন গাইড

পুরো ভিডিওটির মূল আলোচনা হলো কীভাবে একটি প্রজেক্টকে Spring Data JPA থেকে Spring Data JDBC-তে নিয়ে যাওয়া যায়। বক্তা জেন্স শাউডার (Jens Schauder) এখানে দেখিয়েছেন যে, এই মাইগ্রেশন বা পরিবর্তনটা শুধু কোড বদলানো নয়, বরং প্রজেক্টের আর্কিটেকচার বা গঠনকে আরও সহজ এবং শক্তিশালী করার একটি প্রক্রিয়া। তিনি ধাপে ধাপে (Baby steps) কাজ করার ওপর জোর দিয়েছেন।

১. মাইগ্রেশনের শুরুর প্রস্তুতি এবং সঠিক পদ্ধতি

রেফারেন্স: https://www.youtube.com/watch?v=WYa9n0F4CRM [05:23]

যেকোনো বড় পরিবর্তনের আগে বক্তা দুটি বিশেষ পদ্ধতির কথা বলেছেন:

• Baby Steps: ছোট ছোট পরিবর্তন করা, প্রতিবার কোড চেক করা এবং টেস্ট রান করা। একবারে সব বদলাতে গেলে পুরো প্রজেক্ট এলোমেলো হয়ে যেতে পারে।

• Mikado Method: এটি একটি রিফ্যাক্টরিং টেকনিক। প্রথমে একটি বড় লক্ষ্য ঠিক করা হয়, তারপর সেটি অর্জনে কী কী ছোট বাধা আছে তা গ্রাফ আকারে লিখে সমাধান করা হয়। যদি কোনো পরিবর্তন কাজ না করে, তবে আগের অবস্থায় ফিরে গিয়ে (Undo) সমস্যাটি বুঝে আবার শুরু করা হয়।

সহজ ব্যাখ্যা: * রিফ্যাক্টরিং (Refactoring): কোডের বাইরের কাজ বা আউটপুট ঠিক রেখে ভেতরের গঠন সুন্দর বা উন্নত করা।

• ডিপেন্ডেন্সি (Dependency): যখন একটি কাজ করার জন্য অন্য একটি কাজের ওপর নির্ভর করতে হয়।

২. এগ্রিগেট (Aggregates) চেনা এবং রিপোজিটরি কমানো

রেফারেন্স: [15:20]

Spring Data JDBC মূলত Domain Driven Design (DDD) এর 'Aggregate' কনসেপ্টের ওপর ভিত্তি করে চলে।

• একটি এগ্রিগেট হলো কতগুলো ক্লাসের একটা গ্রুপ যা একটি ইউনিট হিসেবে কাজ করে।

• এখানে একটি 'Aggregate Root' থাকে, যার মাধ্যমে বাকি ক্লাসগুলোকে নিয়ন্ত্রণ করা হয়।

• মাইগ্রেশনের সময় অপ্রয়োজনীয় রিপোজিটরিগুলো মুছে ফেলতে হবে। যেমন: যদি Shipment একটি এগ্রিগেট রুট হয় এবং Item তার ভেতরের অংশ হয়, তবে ItemRepository মুছে দিয়ে সব কাজ ShipmentRepository দিয়ে করতে হবে।

সহজ ব্যাখ্যা: * এগ্রিগেট (Aggregate): মনে করো একটি বইয়ের সেট। এখানে মূল বইটি হলো 'Root', আর তার ভেতরের চ্যাপ্টারগুলো হলো তার অংশ। আপনি যখন লাইব্রেরি থেকে বই নেবেন, পুরো সেটটাই একসাথে নেবেন।

৩. রিলেশনশিপ সহজ করা এবং M:N জয়েন হ্যান্ডেল করা

রেফারেন্স: [24:41] - [31:28]

JPA-তে আমরা সাধারণত 'Bidirectional reference' (উভয়মুখী সম্পর্ক) ব্যবহার করি, কিন্তু Spring Data JDBC-তে এটি সম্ভব নয় এবং প্রয়োজনও নেই।

• একমুখী সম্পর্ক: সম্পর্ক সবসময় রুট থেকে নিচের দিকে থাকবে। যেমন: Customer থেকে Shipment।

• M:N (Many-to-Many): JPA এই রিলেশনশিপটি লুকিয়ে রাখে, কিন্তু JDBC-তে আমাদের একটি 'Join Table' বা আলাদা ক্লাস (যেমন: ProductCategory) তৈরি করে দিতে হয়।

• ID ভিত্তিক রেফারেন্স: এক এগ্রিগেট থেকে অন্য এগ্রিগেটের সাথে সরাসরি অবজেক্ট রেফারেন্স না রেখে শুধু ID ব্যবহার করতে হয়। এটি কোডকে অনেক পরিষ্কার করে।

সহজ ব্যাখ্যা: * Bidirectional (উভয়মুখী): যখন দুই বন্ধু একে অপরের ঠিকানা জানে।

• Join Table: দুই ধরনের তথ্যের মধ্যে সংযোগ তৈরি করার জন্য মাঝখানে ব্যবহৃত একটি টেবিল।

৪. সেভ (Save) মেথড ব্যবহার এবং আইডেন্টিটি জেনারেশন

রেফারেন্স: [21:29]

JPA-তে কোনো ডাটা পরিবর্তন করলে তা অটোমেটিক সেভ হয়ে যায় (Dirty checking), কিন্তু JDBC-তে আপনাকে স্পষ্টভাবে .save() মেথড কল করতে হবে। এছাড়া, ডাটাবেসে নতুন ডাটা ঢোকানোর সময় ID তৈরি করার জন্য আলাদা 'Id Generator' বা 'Callback' ব্যবহার করার প্রয়োজন হতে পারে।

Java

// একটি সহজ Callback উদাহরণ যা ID সেট করে
public class BeforeConvertCallback {
    public Object onBeforeConvert(Object entity) {
        if (entity.getId() == null) {
            // ডাটাবেস থেকে নতুন ID নিয়ে সেট করা
            entity.setId(jdbcTemplate.queryForObject("SELECT nextval('my_seq')", Long.class));
        }
        return entity;
    }
} 

এই কোডটির মাধ্যমে আমরা নিশ্চিত করি যে ডাটাবেসে সেভ হওয়ার আগেই অবজেক্টটির একটি সঠিক ID আছে।

---

এনালাইসিস এবং আমার ভাবনা (Analysis & Perception)

সারাংশ ও উদ্দেশ্য: কন্টেন্ট ক্রিয়েটর বোঝাতে চেয়েছেন যে Spring Data JDBC ব্যবহার করলে আমাদের কোড অনেক বেশি সুশৃঙ্খল এবং "Strict" হয়। JPA অনেক কিছু পর্দার আড়ালে (Magic) করে দেয়, যা ছোট প্রজেক্টে ভালো হলেও বড় প্রজেক্টে নিয়ন্ত্রণ হারানো বা পারফরম্যান্সের সমস্যার কারণ হতে পারে।

বাস্তবতা ও পরামর্শ:

• কঠিন কাজ: মাইগ্রেশন করাটা আসলেই অনেক সময়ের ব্যাপার এবং এটি সব প্রজেক্টের জন্য জরুরি নয়।

• বিকল্প উপায়: যদি পুরো প্রজেক্ট মাইগ্রেট করা সম্ভব না হয়, তবে বক্তার পরামর্শ অনুযায়ী নতুন ফিচারের জন্য JDBC ব্যবহার করা যেতে পারে এবং পুরনো গুলোর জন্য JPA রাখা যেতে পারে। একে Co-existence বলা হয়।

• পরামর্শ: আপনি যদি আপনার ডাটাবেস কোয়েরির ওপর পূর্ণ নিয়ন্ত্রণ চান এবং "Magic" কমাতে চান, তবেই JDBC-তে যান। তবে যাওয়ার আগে অবশ্যই ভালো Unit Tests লিখে নিতে হবে যাতে মাইগ্রেশনের সময় কিছু ভেঙে গেলে সহজে ধরা পড়ে।

সহজ শব্দে শেষ কথা: JPA হলো অটোমেটিক গিয়ারের গাড়ির মতো, আর JDBC হলো ম্যানুয়াল গিয়ারের মতো। ম্যানুয়াল চালাতে দক্ষতা লাগে কিন্তু নিয়ন্ত্রণ অনেক বেশি থাকে।

[

Migrating from (Spring Data) JPA to Spring Data JDBC by Jens Schauder @ Spring I/O 2024

Spring I/O · 27K views

](http://www.youtube.com/watch?v=WYa9n0F4CRM)