ডেটা ইনপুট বৈধতা সবসময় আমার কাছে বেশ অভ্যন্তরীণ লড়াই ছিল।
আমাদের উত্তরাধিকার অ্যাপ্লিকেশন পুনর্লিখন প্রকল্পে সত্যিকারের সুরক্ষা কাঠামো এবং কোড যুক্ত করার প্রান্তে (যা এখন পর্যন্ত কার্ড-ক্যাসেল-শক্তিশালী উত্তরাধিকার সুরক্ষা কোড এবং ডেটা বৈধকরণকে রাখে), আমি আবারও ভাবছি যে আমার কতটা বৈধকরণ করা উচিত, কোথায়, ইত্যাদি
পেশাদার জাভা বিকাশকারী হিসাবে আমার 5 বছরেরও বেশি সময় ধরে আমি ডেটা ইনপুট বৈধতা এবং সুরক্ষা ব্যবস্থার জন্য আমার ব্যক্তিগত নিয়ম তৈরি ও পরিমার্জন করেছি। যেহেতু আমি আমার পদ্ধতিগুলি উন্নত করতে চাই, আমি আপনাকে কিছু লোকের কাছ থেকে কিছু ধারণা শুনতে চাই। সাধারণ নিয়মাবলী এবং পদ্ধতি খুব ভাল, এবং জাভা-নির্দিষ্টও।
সংক্ষিপ্ত বিবরণে, এগুলি আমার নির্দেশিকা (তিন স্তরের ওয়েব অ্যাপ্লিকেশন শৈলীতে প্রকাশিত), সংক্ষিপ্ত ব্যাখ্যা সহ:
প্রথম স্তরের ক্লায়েন্টের দিক (ব্রাউজার): ন্যূনতম বৈধতা, কেবল অদৃশ্য নিয়ম (বাধ্যতামূলক ইমেল ক্ষেত্র, অবশ্যই একটি আইটেম নির্বাচন করতে হবে এবং এর মতো); "ation থেকে ২০ টি অক্ষরের মধ্যে" যেমন অতিরিক্ত বৈধতার ব্যবহার কম ঘন ঘন ঘটে থাকে, কারণ এটি পরিবর্তনের উপর রক্ষণাবেক্ষণের কাজ বাড়ায় (ব্যবসায়ের কোডটি স্থিতিশীল হওয়ার পরে যুক্ত হতে পারে);
প্রথম স্তরের সার্ভার সাইড (ওয়েব যোগাযোগের হ্যান্ডলিং, "কন্ট্রোলারস"): আমার এটির কোনও নিয়ম নেই, তবে আমি বিশ্বাস করি যে এখানে কেবল ডেটা ম্যানিপুলেশন এবং সমাবেশ / পার্সিং ত্রুটিগুলি পরিচালনা করা উচিত (জন্মদিনের ক্ষেত্রটি বৈধ তারিখ নয়); এখানে আরও বৈধতা যুক্ত করা সহজেই এটি সত্যিই বিরক্তিকর প্রক্রিয়া করে তোলে;
২ য় স্তর (ব্যবসায় স্তর): রক কঠিন বৈধতা, কম নয়; ইনপুট ডেটা ফর্ম্যাট, ব্যাপ্তি, মান, অভ্যন্তরীণ অবস্থা যাচাইকরণ পদ্ধতিটি যে কোনও সময় বলা যায় না, ব্যবহারকারীর ভূমিকা / অনুমতি ইত্যাদি; যতটা সম্ভব ইউজার ইনপুট ডেটা ব্যবহার করুন, প্রয়োজনে ডাটাবেস থেকে এটি পুনরুদ্ধার করুন; যদি আমরা পুনরুদ্ধারকৃত ডাটাবেস ডেটাটিকে ইনপুট হিসাবেও বিবেচনা করি তবে আমি কেবলমাত্র এটির বৈধতা দেব যদি কিছু নির্দিষ্ট ডেটা ডিবিতে অবিশ্বাস্য বা যথেষ্ট পরিমাণে দুর্নীতিগ্রস্থ বলে পরিচিত হয় - শক্তিশালী টাইপিং এখানে বেশিরভাগ কাজ করে, আইএমএইচও;
তৃতীয় স্তরের (ডেটা স্তর / ডএএল / ডিএও): কখনও বিশ্বাস করেনি যে এখানে খুব বেশি বৈধতা পাওয়া দরকার, কারণ কেবলমাত্র ব্যবসায় স্তরটি ডেটা অ্যাক্সেস করার কথা বলেছে ("প্যারাম 1 সত্য হলে" প্যারাম 2 অবশ্যই নਾਲ হওয়া উচিত নয় "এর মতো কোনও ক্ষেত্রে বৈধতা প্রমাণ করতে পারে); তবে খেয়াল করুন, যখন আমি "এখানে" আমি "কোড" ডাটাবেস অ্যাক্সেস করি "বা" এসকিউএল-এক্সিকিউটিভ পদ্ধতি "ব্যবহার করি তখন ডাটাবেস নিজেই সম্পূর্ণ বিপরীত হয়;
ডাটাবেস (ডেটা মডেল): ডিবিতে যতটা সম্ভব ভুল এবং দুর্নীতিগ্রস্থ তথ্য যথাসম্ভব এড়াতে যথাযথভাবে বিবেচনা করা উচিত, শক্তিশালী এবং স্ব-প্রয়োগকারী হওয়া দরকার, ভাল প্রাথমিক কী, বিদেশী কী, সীমাবদ্ধতা, ডেটা টাইপ / দৈর্ঘ্য / আকার সহ / যথার্থতা এবং আরও - এগুলি থেকে ট্রিগারগুলি ছেড়ে চলেছি, কারণ তাদের নিজস্ব ব্যক্তিগত আলোচনা রয়েছে।
আমি জানি প্রাথমিক ডেটা যাচাইকরণটি দুর্দান্ত এবং কার্য সম্পাদন ভিত্তিক, তবে বারবার ডেটা বৈধকরণ একটি বিরক্তিকর প্রক্রিয়া এবং আমি স্বীকার করি যে ডেটা বৈধতা নিজেই বেশ বিরক্তিকর। তাই অনেক কোডার এটিকে এড়িয়ে যান বা অর্ধেক করে এটি করেন। এছাড়াও, প্রতিটি সদৃশ বৈধতা যদি সম্ভাব্য ত্রুটি হয় তবে যদি তারা সমস্ত সময় সিঙ্ক্রোনাইজ হয় না। সেগুলি প্রধান কারণ যা আমি আজকাল বেশিরভাগ বৈধতাকে ব্যবসায়ের স্তর পর্যন্ত সময়, ব্যান্ডউইথ এবং সিপিইউ ব্যয় করে কেস-কেস-কেস ব্যয়ে পরিচালনা করা ব্যয়ে ব্যয় করে prefer
তো, এই ব্যাপারে তোমার মতামত কী? বিপরীত মতামত? আপনার কি অন্যান্য পদ্ধতি আছে? এই জাতীয় বিষয়ের একটি রেফারেন্স? যে কোনও অবদান বৈধ।
দ্রষ্টব্য: আপনি যদি জাভা পদ্ধতিতে কাজ করার চিন্তাভাবনা করে থাকেন তবে আমাদের অ্যাপ্লিকেশনটি স্প্রিং এমভিসি এবং মাইবাটিস (পারফরম্যান্স এবং খারাপ ডেটাবেস মডেলকে ORM সমাধানগুলি বাতিল করে দেয়) এর ভিত্তিতে স্প্রিং ভিত্তিক; আমি আমাদের সুরক্ষা সরবরাহকারী প্লাস জেএসআর 303 (হাইবারনেট ভ্যালিডেটর?) হিসাবে স্প্রিং সিকিউরিটি যুক্ত করার পরিকল্পনা করছি
ধন্যবাদ!
সম্পাদনা করুন: তৃতীয় স্তরের কিছু অতিরিক্ত স্পষ্টতা।