এমভিসিতে কোনও মডেলটির বৈধতা হ্যান্ডেল করা উচিত?

Question

এমভিসি প্যাটার্নটি ব্যবহার করার জন্য আমি যে ওয়েব অ্যাপ্লিকেশনটি বিকাশ করেছি তা পুনরায় আর্কিটেক্ট করার চেষ্টা করছি, তবে আমি নিশ্চিত নই যে মডেলটিতে বৈধতা হ্যান্ডেল করা উচিত কিনা। উদাহরণস্বরূপ, আমি আমার মডেলগুলির মধ্যে একটি সেট আপ করছি:

class AM_Products extends AM_Object 
{
    public function save( $new_data = array() ) 
    {
        // Save code
    }
}

প্রথম প্রশ্ন: তাই আমি ভাবছি যে আমার সংরক্ষণের পদ্ধতিটি $ নতুন_ডেটাতে কোনও বৈধতা ফাংশন কল করতে পারে বা ধরে নেওয়া উচিত যে ডেটা ইতিমধ্যে বৈধ হয়েছে?

এছাড়াও, যদি এটি বৈধতার প্রস্তাব দেওয়া হয়, তবে আমি ভাবছি যে ডেটা ধরণের সংজ্ঞায়িত করার জন্য কিছু মডেল কোড এটির মতো দেখাবে:

class AM_Products extends AM_Object
{
    protected function init() // Called by __construct in AM_Object
    {
        // This would match up to the database column `age`
        register_property( 'age', 'Age', array( 'type' => 'int', 'min' => 10, 'max' => 30 ) ); 
    }
}

দ্বিতীয় প্রশ্ন: এএম_অবজেক্টের প্রতিটি শিশু শ্রেণি সেই নির্দিষ্ট বস্তুর ডাটাবেসে প্রতিটি কলামের জন্য রেজিস্টার_প্রার্টি চালাবে। আমি নিশ্চিত না এটি এটি করার ভাল উপায় কিনা।

তৃতীয় প্রশ্ন: যদি বৈধকরণটি মডেল দ্বারা পরিচালনা করা উচিত, তবে এটি কোনও ত্রুটি বার্তা বা একটি ত্রুটি কোডটি ফিরিয়ে আনবে এবং ভিউটি কোনও উপযুক্ত বার্তা প্রদর্শনের জন্য কোডটি ব্যবহার করবে?

Answer 1

প্রথম উত্তর: মডেলটির মূল ভূমিকা হ'ল সততা বজায় রাখা। তবে ব্যবহারকারীর ইনপুট প্রক্রিয়াজাতকরণ একটি নিয়ামকের দায়িত্ব।

অর্থাৎ, নিয়ামককে অবশ্যই ব্যবহারকারী ডেটা অনুবাদ করতে হবে (যা বেশিরভাগ সময় কেবল স্ট্রিং থাকে) অর্থপূর্ণ কিছুতে। এর জন্য পার্সিং প্রয়োজন (এবং লোকেলের মতো জিনিসগুলির উপর নির্ভর করতে পারে, উদাহরণস্বরূপ, এখানে বিভিন্ন দশমিক অপারেটর রয়েছে))
সুতরাং প্রকৃত বৈধতা, যেমন "" ডেটাটি কি ভালভাবে তৈরি হয়? ", নিয়ন্ত্রক দ্বারা সম্পাদন করা উচিত। তবে যাচাইকরণ হিসাবে, "ডেটা কী বোঝায়?" মডেল মধ্যে সঞ্চালিত করা উচিত।

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

আপনার নিয়ামক ইনপুট (প্রক্রিয়াজাতকরণ) বিধি রয়েছে। আপনার মডেলটিতে ব্যবসায়ের বিধি রয়েছে। আপনি চান আপনার ব্যবসায়ের নিয়ম সর্বদা প্রয়োগ করা হোক, যাই ঘটুক না কেন। ধরে নিই যে কন্ট্রোলারে আপনার ব্যবসায়ের বিধি রয়েছে, তবে আপনার যদি সেগুলির অনুলিপি করতে হয়, আপনি যদি অন্য কোনও নিয়ামক তৈরি করেন তবে।

দ্বিতীয় উত্তর: পদ্ধতির কোনও অর্থ নেই, তবে পদ্ধতিটি আরও শক্তিশালী করা যেতে পারে। শেষ প্যারামিটারটি অ্যারে হওয়ার পরিবর্তে এটির উদাহরণ হওয়া উচিত IContstraintযা এরূপ হিসাবে সংজ্ঞায়িত হয়েছে:

interface IConstraint {
     function test($value);//returns bool
}

এবং সংখ্যার জন্য আপনি কিছু হতে পারে

class NumConstraint {
    var $grain;
    var $min;
    var $max;
    function __construct($grain = 1, $min = NULL, $max = NULL) {
         if ($min === NULL) $min = INT_MIN;
         if ($max === NULL) $max = INT_MAX;
         $this->min = $min;
         $this->max = $max;
         $this->grain = $grain;
    }
    function test($value) {
         return ($value % $this->grain == 0 && $value >= $min && $value <= $max);
    }
}

এছাড়াও আমি 'Age'প্রতিনিধিত্ব বলতে বোঝাতে চাইছি কি, সত্য বলতে। এটি কি প্রকৃত সম্পত্তির নাম? ডিফল্টরূপে একটি কনভেনশন আছে তা ধরে নিয়ে, প্যারামিটারটি সহজেই ফাংশনটির শেষে যেতে পারে এবং optionচ্ছিক হতে পারে। যদি সেট না করা থাকে তবে এটি ডিবি কলামের নামের__ ক্যামেল_কেসে ডিফল্ট হবে ।

সুতরাং উদাহরণ কল মত দেখতে হবে:

register_property('age', new NumConstraint(1, 10, 30));

ইন্টারফেসগুলি ব্যবহার করার বিষয়টি হ'ল আপনি যেতে যেতে আরও সীমাবদ্ধতা যুক্ত করতে পারেন এবং সেগুলি আপনার পছন্দ মতো জটিল হতে পারে। একটি স্ট্রিং জন্য একটি নিয়মিত অভিব্যক্তি মেলে। কমপক্ষে 7 দিন এগিয়ে যাওয়ার তারিখের জন্য। ইত্যাদি।

তৃতীয় উত্তর: প্রতিটি মডেল সত্তার মতো পদ্ধতি থাকা উচিত Result checkValue(string property, mixed value)। ডেটা সেট করার আগে নিয়ন্ত্রকের এটিকে কল করা উচিত । Resultকিনা যাচাই ব্যর্থ সম্পর্কে সব তথ্য থাকা উচিত, এবং কেস এটি না হলে, কোন কারণ দেখাবেন তাই নিয়ামক দৃশ্যে সেই অনুসারে বংশ বিস্তার করতে পারেন।
যদি কোনও মডেলকে একটি ভুল মান পাস করা হয়, তবে মডেলটির কেবল একটি ব্যতিক্রম উত্থাপন করে প্রতিক্রিয়া জানানো উচিত।

Comments

এই লেখার জন্য আপনাকে ধন্যবাদ। এটি এমভিসি সম্পর্কে অনেক কিছুই স্পষ্ট করেছে।

— AmadeusDrZaius

Answer 2

আমি "ব্যাক 2 ডস" এর সাথে পুরোপুরি একমত নই: আমার প্রস্তাবটি হ'ল সর্বদা একটি পৃথক ফর্ম / বৈধকরণ স্তর ব্যবহার করা, যা নিয়ামকটি মডেলটিতে প্রেরণের আগে ইনপুট ডেটা যাচাই করতে ব্যবহার করতে পারে।

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

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

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

আরও দেখুন: https://lastzero.net/2015/11/why-im-using-a-separate-layer- for-input-data-uthoration/

Comments

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

— অ্যান্টনি রটলেজ

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

— অ্যান্টনি রটলেজ

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

— অ্যান্টনি রাটলেজ

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

— অ্যান্টনি রটলেজ

ন্যূনতম নিয়ন্ত্রণ, সর্বাধিক নিয়ন্ত্রণ, সঠিক নিয়ন্ত্রণ, ইনপুট এনকোডিং এবং সর্বোচ্চ ইনপুট আকার সমস্ত অনুরোধের প্রকৃতির সাথে সম্পর্কিত (এক উপায় বা অন্যভাবে)। কিছু লোক এই পাঁচটি মূল বিষয়টিকে কোনও অনুরোধকে সম্মানিত করা উচিত কিনা তা নির্ধারণের জন্য চিহ্নিত করেননি। যদি এই সমস্ত জিনিস সন্তুষ্ট না হয় তবে আপনি এই তথ্যটি মডেলটিতে কেন পাঠাচ্ছেন? ভাল প্রশ্ন.

— অ্যান্টনি রটলেজ

Answer 3

হ্যাঁ, মডেলটির বৈধতা সম্পাদন করা উচিত। ইউআই এর ইনপুটটিও বৈধ করা উচিত।

বৈধ মান এবং রাজ্য নির্ধারণ করার বিষয়টি মডেলটির স্পষ্টভাবে দায়িত্ব। কখনও কখনও এই জাতীয় নিয়ম প্রায়শই পরিবর্তিত হয়। সেক্ষেত্রে আমি মেটাটাটা থেকে মডেলটি ফিড করব এবং / অথবা এটি সাজাতে পারি।

Comments

ব্যবহারকারীর অভিপ্রায় পরিষ্কারভাবে দূষিত বা ত্রুটিযুক্ত ক্ষেত্রে কী করা যায়? উদাহরণস্বরূপ, একটি নির্দিষ্ট এইচটিটিপি অনুরোধের সাত (7) এর বেশি ইনপুট মান না থাকার কথা, তবে আপনার নিয়ামক সত্তর (70) পান। অনুরোধটি পরিষ্কারভাবে দুর্নীতিগ্রস্থ হয়ে গেলে আপনি কি মডেলটিকে দশবার (10x) অনুমোদিত মানগুলিকে হিট করার অনুমতি দিচ্ছেন? এই ক্ষেত্রে, এটি সম্পূর্ণ অনুরোধের রাজ্য যা প্রশ্নে রয়েছে, কোনও একটি নির্দিষ্ট মানের রাষ্ট্র নয়। গভীরতার কৌশলটিতে একটি প্রতিরক্ষা পরামর্শ দেয় যে মডেলটির কাছে ডেটা পাঠানোর আগে এইচটিটিপি অনুরোধের প্রকৃতিটি পরীক্ষা করা উচিত।

— অ্যান্টনি রটলেজ

(অবিরত) এইভাবে, আপনি যে নির্দিষ্ট ব্যবহারকারীর সরবরাহিত মান এবং রাজ্যগুলি বৈধ তা পরীক্ষা করে দেখছেন না, তবে অনুরোধের সামগ্রিকতা বৈধ is এখনও পর্যন্ত ড্রিল করার প্রয়োজন নেই। তেলটি ইতিমধ্যে পৃষ্ঠে রয়েছে।

— অ্যান্টনি রটলেজ

(অব্যাহত) ফ্রন্ট-এন্ড বৈধতা জোর করার কোনও উপায় নেই। একজনকে বিবেচনা করতে হবে যে স্বয়ংক্রিয় সরঞ্জামগুলি আপনার ওয়েব অ্যাপ্লিকেশনের সাথে ইন্টারফেস ব্যবহার করতে পারে।

— অ্যান্থনি রটলেজ

(চিন্তার পরে) মডেলটিতে বৈধ মান এবং তথ্যসমূহ গুরুত্বপূর্ণ, তবে আমি কন্ট্রোলারের মাধ্যমে আসা অনুরোধের অভিপ্রায় হিটগুলি বর্ণনা করেছি । অভিপ্রায় যাচাইয়ের ছাড় দেওয়া আপনার অ্যাপ্লিকেশনটিকে আরও দুর্বল করে leaves অভিপ্রায় কেবল ভাল (আপনার নিয়ম অনুসারে খেলতে) বা খারাপ (আপনার নিয়মের বাইরে যাওয়া) হতে পারে। ইনপুটটিতে বেসিক চেক দ্বারা অভিপ্রায় যাচাই করা যেতে পারে: ন্যূনতম নিয়ন্ত্রণ, সর্বাধিক নিয়ন্ত্রণ, সঠিক নিয়ন্ত্রণ, ইনপুট এনকোডিং এবং সর্বোচ্চ ইনপুট আকার। এটি একটি সব বা কিছুই প্রস্তাব। সবকিছু পাস, বা অনুরোধটি অবৈধ। মডেলটিতে কিছু প্রেরণের দরকার নেই।

— অ্যান্টনি রটলেজ

Answer 4

দুর্দান্ত প্রশ্ন!

ওয়ার্ল্ড ওয়াইড ওয়েব বিকাশের ক্ষেত্রে, আপনি যদি নিম্নলিখিতগুলিও জিজ্ঞাসা করেন তবে কি।

"যদি খারাপ ব্যবহারকারীর ইনপুট কোনও ব্যবহারকারীর ইন্টারফেস থেকে কোনও নিয়ামককে সরবরাহ করা হয়, তবে কন্ট্রোলারকে কি এক ধরণের চক্রীয় লুপে ভিউ আপডেট করতে হবে, প্রসেসের আগে কমান্ড এবং ইনপুট ডেটা সঠিক হতে বাধ্য করা হয় ? কীভাবে? দৃশ্যটি কীভাবে স্বাভাবিকের অধীনে আপডেট হয়? শর্তসমূহ? কোনও দৃশ্যে কি কোনও মডেলের সাথে দৃled়ভাবে মিলিত হয়? ব্যবহারকারীর ইনপুট বৈধতা কী মডেলটির মূল ব্যবসায়িক যুক্তি, বা এটি এর প্রাথমিক? এবং এভাবে নিয়ামকের ভিতরে হওয়া উচিত (কারণ ব্যবহারকারী ইনপুট ডেটা অনুরোধের অংশ)?

(কার্যকরভাবে ইনপুট অর্জিত না হওয়া পর্যন্ত কোনও মডেল ইনস্ট্যান্ট করতে বিলম্ব হতে পারে?)

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

সারমর্ম।

1) আপনার রুটটি বৈধ করুন (ইউআরএল থেকে পার্স করা), কারণ অন্য যে কোনও কিছু এগিয়ে যাওয়ার আগে নিয়ামক এবং পদ্ধতি থাকা আবশ্যক। প্রকৃত নিয়ামকের কাছে যাওয়ার আগে অবশ্যই এটি অবশ্যই সামনের-নিয়ামক অঞ্চলে (রাউটার শ্রেণি) হওয়া উচিত। Duh। :-)

2) কোনও মডেলের ইনপুট ডেটার অনেকগুলি উত্স থাকতে পারে: একটি HTTP অনুরোধ, একটি ডাটাবেস, একটি ফাইল, একটি API, এবং হ্যাঁ, একটি নেটওয়ার্ক। আপনি যদি সমস্ত ইনপুট বৈধতা মডেলটিতে স্থাপন করতে চলেছেন তবে আপনি এইচটিটিপি অনুরোধ ইনপুট বৈধতা প্রোগ্রামটির ব্যবসায়ের প্রয়োজনীয়তার অংশ বিবেচনা করবেন । মামলা বন্ধ.

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

নিম্নলিখিত পরীক্ষা করুন:

ক) এইচটিটিপি অনুরোধ পদ্ধতি (জিইটি, পোস্ট, পুট, প্যাচ, মোছা ...)

খ) সর্বনিম্ন এইচটিএমএল নিয়ন্ত্রণ (আপনার কি যথেষ্ট আছে?)

গ) সর্বাধিক এইচটিএমএল নিয়ন্ত্রণ (আপনার কি খুব বেশি?)

d) HTML নিয়ন্ত্রণগুলি সঠিক করুন (আপনার কি সঠিক আছে?)

e) ইনপুট এনকোডিং (সাধারণত, এনকোডিংটি ইউটিএফ -8?)

চ) সর্বাধিক ইনপুট আকার (ইনপুটগুলির মধ্যে কি সীমানার বাইরে কিছু আছে?)

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

আমি এখানে যা বর্ণনা করেছি তা নিয়ামকের মাধ্যমে আসা অনুরোধের অভিপ্রায়কে আঘাত করে । অভিপ্রায় যাচাইয়ের ছাড় দেওয়া আপনার অ্যাপ্লিকেশনটিকে আরও দুর্বল করে leaves উদ্দেশ্য কেবল ভাল (আপনার মৌলিক নিয়মগুলি দ্বারা খেলতে) বা খারাপ (আপনার মৌলিক নিয়মের বাইরে যাওয়া) হতে পারে।

ইন্টেন্ট একটি HTTP অনুরোধের জন্য একটি সব অথবা কিছুই প্রতিজ্ঞা হয়। সবকিছু পাস, বা অনুরোধটি অবৈধ । মডেলটিতে কিছু প্রেরণের দরকার নেই।

HTTP- র এই মৌলিক স্তর অনুরোধ অভিপ্রায় রয়েছে কিছুই নিয়মিত ব্যবহারকারীর ইনপুট ত্রুটি এবং বৈধতা সঙ্গে কাজ করতে। আমার অ্যাপ্লিকেশনগুলিতে, এইচটিটিপি অনুরোধটি সম্মানের জন্য আমার অবশ্যই উপরের পাঁচটি পদ্ধতিতে বৈধ হতে হবে। একটি প্রতিরক্ষা-ইন-গভীরতা বলার ভাবে, আপনি কখনোই ব্যবহারকারীর ইনপুট বৈধতা মধ্যে সার্ভার পাশ যদি পেতে কোনো এই পাঁচটি জিনিস ব্যর্থ হয়।

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

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

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

রায়টি কেবল এই নয় যে ব্যবহারকারী একটি যুক্তিসঙ্গত ইনপুট ভুল করেছেন, তবে এইচটিটিপি অনুরোধটি এতটাই সীমার বাইরে যে এটি অবশ্যই দূষিত ঘোষণা করা উচিত এবং তত্ক্ষণাত বন্ধ করা উচিত।

)) সুতরাং, আমার অর্থের জন্য, এইচটিটিপি অনুরোধ (পদ্ধতি, ইউআরএল / রুট, এবং ডেটা) হয় সবই ভাল, বা অন্য কোনও কিছুই এগিয়ে যেতে পারে। একটি শক্তিশালী মডেলটির সাথে ইতিমধ্যে উদ্বেগের জন্য বৈধতা কাজ রয়েছে তবে একটি ভাল সংস্থান রাখাল বলে "আমার উপায়, বা উচ্চতর পথ correct সঠিকভাবে আসুন, বা আদৌ আসেন না।"

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

যদি আপনার ভ্যালিডিটারগুলি মডুলার হয় তবে নিয়ামকটিতে বেসিক * এইচটিটিপি অনুরোধ ইনপুট ** যাচাই করা কোনও সমস্যা হওয়া উচিত নয়। কেবলমাত্র একটি কৌশলযুক্ত ভ্যালিডেটর শ্রেণি ব্যবহার করুন, যেখানে বৈধতাদানকারীরা কখনও কখনও বিশেষায়িত ভ্যালিডেটরগুলির সমন্বয়ে তৈরি হন (ই-মেইল, ফোন, ফর্ম টোকন, ক্যাপচা, ...)।

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

================================================== ========================

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

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

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

আপডেট : ডায়াগ্রামে, আমি বলছি যে Viewরেফারেন্সটি উল্লেখ করা উচিত Model। না । আলগা সংযোগ সংরক্ষণের জন্য আপনার Viewকাছ থেকে ডেটা পাস করা উচিত Model।