১ ৪। দুই জায়গায় (কন্ট্রোলার এবং রাউটস)

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

এখানে কিছু মূল পয়েন্ট দেওয়া হলো কেন createUserSchema কন্ট্রোলার এবং রাউটস উভয় জায়গায় ব্যবহৃত হয় এবং এর উপকারিতা:

১. ডেটা ভ্যালিডেশনের স্তর বিভক্ত করা (Layered Validation)

• রাউটস স্তরে ভ্যালিডেশন: যখন আপনি রাউটস-এ Joi স্কিমা ব্যবহার করেন, তখন আপনি ইনপুট ডেটা (যেমন req.body বা req.params) প্রথমে চেক করেন। এর মানে হল যে, আপনি সঠিক ধরনের ডেটা গ্রহণ করছেন কি না তা নিশ্চিত করছেন, এবং অ্যাপ্লিকেশনের লজিকের আগে ত্রুটির সম্ভাবনা কমে যাবে।
• কন্ট্রোলার স্তরে ভ্যালিডেশন: কন্ট্রোলারে যে ডেটা চলে আসে, সেটা লজিক্যাল এবং বিজনেস রুলস অনুযায়ী আরও প্রক্রিয়া করা হয়। সেখানে আপনি শুধু ডেটা গ্রহণ করার পর, আপনার বিজনেস লজিক অনুযায়ী আরও কিছু যাচাই বা প্রক্রিয়া করতে পারেন। যেমন, আপনার অ্যাপ্লিকেশনে কোনো বিশেষ কন্ডিশন বা কাস্টম রুল থাকতে পারে (যেমন, email এর ইউনিক হওয়া প্রয়োজন) যা রাউটস স্তরে চেক করা সম্ভব নয়।

২. কোড রিইউসেবিলিটি (Code Reusability)

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

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

৩. ডাবল চেকিং এবং আরো নির্ভুল (Double Checking for Better Assurance)

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

৪. বিজনেস লজিক এবং কন্ট্রোলার আলাদা রাখা (Separation of Concerns)

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

উপসংহার:

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

কোড পরিমার্জিত করে নিচে দেওয়া হলো:

// routes/userRoutes.js

const express = require("express");
const userController = require("../controllers/userController");
const { validateRequest } = require("../utils/validateRequest");

// এখানে ইমপোর্ট করবো স্কিমাগুলো
const {
  createUserSchema,
  updateUserSchema,
  getUserSchema,
  deleteUserSchema
} = require("../validation/userValidation");

const router = express.Router();

// POST /users - Create a new user
router.post("/", validateRequest(createUserSchema), userController.createUser);

// GET /users/:id - Get user by ID
router.get("/:id", validateRequest(getUserSchema), userController.getUserById);

// GET /users - Get all users
router.get("/", userController.getAllUsers);

// PATCH /users/:id - Update user by ID
router.patch("/:id", validateRequest(updateUserSchema), userController.updateUser);

// DELETE /users/:id - Delete user by ID
router.delete("/:id", validateRequest(deleteUserSchema), userController.deleteUser);

module.exports = router;

এতে validateRequest ইউটিলিটি ব্যবহার করেও রাউটস স্তরে ভ্যালিডেশন নিশ্চিত করা হচ্ছে এবং কন্ট্রোলারেই বিস্তারিত লজিক এবং ডেটা প্রসেসিং করা হচ্ছে।