ในรูปแบบ MVC ควรจัดการตรวจสอบความถูกต้อง?

ฉันพยายามสร้างเว็บแอปพลิเคชันที่ฉันพัฒนาขึ้นเพื่อใช้รูปแบบ MVC แต่ฉันไม่แน่ใจว่าควรตรวจสอบความถูกต้องในรูปแบบหรือไม่ ตัวอย่างเช่นฉันกำลังตั้งค่าแบบจำลองของฉันแบบนี้:

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

คำถามแรก:ดังนั้นฉันสงสัยว่าวิธีการบันทึกของฉันควรจะเรียกใช้ฟังก์ชันการตรวจสอบความถูกต้องใน $ new_data หรือสมมติว่าข้อมูลได้รับการตรวจสอบแล้ว?

นอกจากนี้หากมีการตรวจสอบความถูกต้องฉันคิดว่ารหัสบางรุ่นเพื่อกำหนดประเภทข้อมูลจะมีลักษณะดังนี้:

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 ) ); 
    }
}

คำถามที่สอง:คลาสย่อยของ AM_Object จะเรียกใช้ register_property สำหรับแต่ละคอลัมน์ในฐานข้อมูลของวัตถุเฉพาะนั้น ฉันไม่แน่ใจว่านี่เป็นวิธีที่ดีในการทำหรือไม่

คำถามที่สาม:หากการตรวจสอบความถูกต้องควรได้รับการจัดการโดยตัวแบบมันควรส่งคืนข้อความแสดงข้อผิดพลาดหรือรหัสข้อผิดพลาดและให้มุมมองใช้รหัสเพื่อแสดงข้อความที่เหมาะสมหรือไม่

คำตอบแรก:บทบาทสำคัญของแบบจำลองคือการรักษาความสมบูรณ์ อย่างไรก็ตามการประมวลผลอินพุตของผู้ใช้เป็นความรับผิดชอบของคอนโทรลเลอร์

นั่นคือคอนโทรลเลอร์จะต้องแปลข้อมูลผู้ใช้ (ซึ่งส่วนใหญ่เป็นเพียงสตริง) เป็นสิ่งที่มีความหมาย สิ่งนี้ต้องมีการแยกวิเคราะห์ (และอาจขึ้นอยู่กับสิ่งต่าง ๆ เช่นภาษาเนื่องจากมีตัวดำเนินการทศนิยมที่แตกต่างกันเป็นต้น)
ดังนั้นการตรวจสอบจริงเช่นเดียวกับใน "เป็นข้อมูลที่เกิดขึ้นได้ดี?" ควรจะดำเนินการโดยตัวควบคุม อย่างไรก็ตามการตรวจสอบเช่นเดียวกับใน "ข้อมูลมีเหตุผลหรือไม่" ควรดำเนินการภายในตัวแบบ

ในการชี้แจงเรื่องนี้ด้วยตัวอย่าง:
สมมติว่าแอปพลิเคชันของคุณอนุญาตให้คุณเพิ่มเอนทิตีบางอย่างพร้อมกับวันที่ (ตัวอย่างเช่นปัญหาเกี่ยวกับเส้นตาย) คุณอาจมี API ซึ่งวันที่อาจแสดงเป็นเพียงการประทับเวลา Unix ขณะที่เมื่อมาจากหน้า HTML จะเป็นชุดของค่าที่แตกต่างกันหรือสตริงในรูปแบบ MM / DD / YYYY คุณไม่ต้องการข้อมูลนี้ในโมเดล คุณต้องการให้แต่ละตัวควบคุมพยายามที่จะคิดออกวัน อย่างไรก็ตามเมื่อวันที่นั้นถูกส่งผ่านไปยังตัวแบบโมเดลนั้นต้องรักษาความสมบูรณ์ ตัวอย่างเช่นมันอาจสมเหตุสมผลที่จะไม่อนุญาตให้มีวันที่ในอดีตหรือวันที่ที่อยู่ในช่วงวันหยุด / วันอาทิตย์เป็นต้น

คอนโทรลเลอร์ของคุณมีกฎอินพุต (กำลังประมวลผล) แบบจำลองของคุณมีกฎเกณฑ์ทางธุรกิจ คุณต้องการให้มีการบังคับใช้กฎธุรกิจของคุณเสมอไม่ว่าจะเกิดอะไรขึ้น สมมติว่าคุณมีกฎเกณฑ์ทางธุรกิจในตัวควบคุมแล้วคุณจะต้องทำซ้ำพวกเขาหากคุณเคยสร้างตัวควบคุมที่แตกต่างกัน

คำตอบที่สอง:วิธีการนี้สมเหตุสมผล แต่วิธีนี้สามารถทำให้มีประสิทธิภาพมากขึ้น แทนที่จะเป็นพารามิเตอร์สุดท้ายที่เป็นอาร์เรย์มันควรเป็นอินสแตนซ์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'หมายถึงการเป็นตัวแทนที่จะซื่อสัตย์ เป็นชื่อจริงหรือไม่? สมมติว่ามีการประชุมโดยค่าเริ่มต้นพารามิเตอร์สามารถไปที่ท้ายฟังก์ชั่นและเป็นทางเลือก หากไม่ได้ตั้งค่าจะเป็นการเริ่มต้นที่to_camel_caseของชื่อคอลัมน์ DB

ดังนั้นการเรียกตัวอย่างจะมีลักษณะดังนี้:

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

จุดประสงค์ของการใช้อินเทอร์เฟซคือคุณสามารถเพิ่มข้อ จำกัด มากขึ้นเมื่อคุณไปและสิ่งเหล่านั้นอาจซับซ้อนตามที่คุณต้องการ สำหรับสตริงเพื่อให้ตรงกับการแสดงออกปกติ สำหรับวันที่จะล่วงหน้าอย่างน้อย 7 วัน และอื่น ๆ

คำตอบที่สาม:ทุกรุ่นของเอนทิตีควรมีวิธีการResult checkValue(string property, mixed value)ดังนี้ คอนโทรลเลอร์ควรเรียกมันก่อนการตั้งค่าข้อมูล Resultควรมีข้อมูลทั้งหมดที่เกี่ยวกับว่าการตรวจสอบล้มเหลวและในกรณีที่มันไม่ให้เหตุผลเพื่อให้การควบคุมสามารถแพร่กระจายไปยังมุมมองเหล่านั้นตาม
หากค่าที่ไม่ถูกต้องถูกส่งผ่านไปยังตัวแบบโมเดลนั้นควรตอบสนองโดยเพิ่มข้อยกเว้น

ฉันไม่เห็นด้วยกับ "back2dos" อย่างสมบูรณ์: คำแนะนำของฉันคือใช้เลเยอร์แบบฟอร์ม / การตรวจสอบความถูกต้องแยกต่างหากเสมอซึ่งคอนโทรลเลอร์สามารถใช้เพื่อตรวจสอบความถูกต้องของข้อมูลอินพุตก่อนที่จะส่งไปยังแบบจำลอง

จากมุมมองเชิงทฤษฎีการตรวจสอบความถูกต้องของโมเดลทำงานกับข้อมูลที่เชื่อถือได้ (สถานะระบบภายใน) และควรทำซ้ำได้ทุกเวลาในขณะที่การตรวจสอบความถูกต้องของอินพุตดำเนินการอย่างชัดเจนเพียงครั้งเดียวกับข้อมูลที่มาจากแหล่งที่ไม่น่าเชื่อถือ

การแยกนี้ทำให้สามารถสร้างโมเดลตัวควบคุมและแบบฟอร์มที่สามารถนำมาใช้ซ้ำได้โดยการฉีดแบบพึ่งพา คิดว่าการตรวจสอบความถูกต้องของอินพุตเป็นการตรวจสอบรายการที่อนุญาต (“ ยอมรับว่าดี”) และการตรวจสอบรูปแบบเป็นการตรวจสอบบัญชีดำ (“ ปฏิเสธรู้จักไม่ดี”) การตรวจสอบบัญชีปลอดภัยมีความปลอดภัยมากขึ้นในขณะที่การตรวจสอบบัญชีดำป้องกันเลเยอร์โมเดลของคุณจากการถูก จำกัด มากเกินไปจนถึงกรณีการใช้งานที่เฉพาะเจาะจง

ข้อมูลโมเดลที่ไม่ถูกต้องควรทำให้เกิดข้อยกเว้นเสมอ (มิฉะนั้นแอปพลิเคชันสามารถทำงานต่อไปได้โดยไม่สังเกตเห็นความผิดพลาด) ในขณะที่ค่าอินพุตที่ไม่ถูกต้องที่มาจากแหล่งภายนอกนั้นไม่ได้คาดไม่ถึง

ดูเพิ่มเติมที่: https://lastzero.net/2015/11/why-im-using-a-separate-layer-for-input-data-validation/

ใช่โมเดลควรทำการตรวจสอบความถูกต้อง UI ควรตรวจสอบอินพุตเช่นกัน

มันชัดเจนว่าความรับผิดชอบของแบบจำลองในการกำหนดค่าและสถานะที่ถูกต้อง บางครั้งกฎดังกล่าวเปลี่ยนแปลงบ่อย ในกรณีนี้ฉันต้องการป้อนโมเดลจากข้อมูลเมตาและ / หรือตกแต่ง

เป็นคำถามที่ดีมาก!

ในแง่ของการพัฒนาเว็บทั่วโลกจะเกิดอะไรขึ้นถ้าคุณถามสิ่งต่อไปนี้เช่นกัน

"ถ้ามีการป้อนข้อมูลผู้ใช้ที่ไม่ดีไปยังตัวควบคุมจากอินเทอร์เฟซผู้ใช้ตัวควบคุมควรอัปเดตมุมมองในรูปแบบวนวนวนวนวงจรบังคับให้คำสั่งและข้อมูลอินพุตถูกต้องก่อนประมวลผลมุมมองได้รับการปรับปรุงอย่างไร เงื่อนไขหรือไม่มุมมองที่จับคู่กับโมเดลแน่นหนาหรือไม่ตรรกะทางธุรกิจหลักของผู้ใช้สำหรับการตรวจสอบความถูกต้องของการป้อนข้อมูลหรือเป็นแบบเบื้องต้นและควรเกิดขึ้นภายในคอนโทรลเลอร์ (เนื่องจากข้อมูลอินพุตของผู้ใช้เป็นส่วนหนึ่งของคำขอ)

(ในความเป็นจริงสามารถและควรหนึ่งความล่าช้าในการสร้างอินสแตนซ์โมเดลจนกว่าจะได้รับอินพุตที่ดี?)

ความคิดเห็นของฉันคือโมเดลควรจัดการกับสถานการณ์ที่บริสุทธิ์และบริสุทธิ์ (มากที่สุดเท่าที่จะเป็นไปได้) โดยไม่มีการกำหนดค่าโดยการตรวจสอบอินพุต HTTPพื้นฐานที่ควรเกิดขึ้นก่อนการสร้างโมเดล (และแน่นอนก่อนที่โมเดลจะรับข้อมูลอินพุต) เนื่องจากการจัดการข้อมูลสถานะ (แบบถาวรหรืออย่างอื่น) และความสัมพันธ์ของ API คือโลกของแบบจำลองให้การตรวจสอบความถูกต้องอินพุต HTTP คำร้องขอพื้นฐานเกิดขึ้นในคอนโทรลเลอร์

สรุป

1) ตรวจสอบเส้นทางของคุณ (แยกวิเคราะห์จาก URL) เนื่องจากต้องมีตัวควบคุมและวิธีการก่อนจึงจะสามารถดำเนินการต่อได้ สิ่งนี้น่าจะเกิดขึ้นใน real-controller frontm (คลาสเราเตอร์) ก่อนที่จะไปยังคอนโทรลเลอร์ที่แท้จริง ดุจ :-)

2) ตัวแบบอาจมีหลายแหล่งข้อมูลอินพุต: คำร้องขอ HTTP, ฐานข้อมูล, ไฟล์, API และใช่เครือข่าย หากคุณกำลังจะวางการตรวจสอบความถูกต้องของคุณทั้งหมดลงในแบบจำลองคุณจะต้องพิจารณาส่วนการตรวจสอบความถูกต้องของคำร้องขอ HTTPของข้อกำหนดทางธุรกิจสำหรับโปรแกรม ปิดคดี.

3) ถึงกระนั้นก็เป็นสายตาสั้นที่ต้องเสียค่าใช้จ่ายในการสร้างอินสแตนซ์ของวัตถุจำนวนมากถ้าอินพุตการร้องขอ HTTPไม่ดี! คุณสามารถทราบได้ว่า ** อินพุตคำขอ HTTP ** นั้นดี ( ที่มาพร้อมกับคำขอ ) โดยการตรวจสอบก่อนที่จะสร้างโมเดลและความซับซ้อนทั้งหมดของอินสแตนซ์ (ใช่อาจจะเป็นตัวตรวจสอบความถูกต้องมากกว่าสำหรับข้อมูลอินพุต / เอาต์พุต API และ DB)

ทดสอบสิ่งต่อไปนี้:

a) วิธีการร้องขอ HTTP (GET, POST, PUT, PATCH, DELETE ... )

b) การควบคุม HTML ขั้นต่ำ (คุณมีเพียงพอหรือไม่)

c) การควบคุม HTML สูงสุด (คุณมีมากเกินไปหรือไม่)

d) แก้ไขการควบคุม HTML (คุณมีสิ่งที่ถูกต้องหรือไม่?)

e) การเข้ารหัสอินพุต (โดยทั่วไปคือการเข้ารหัส UTF-8 หรือไม่)

f) ขนาดอินพุตสูงสุด (อินพุตใด ๆ ออกนอกขอบเขตอย่างดุร้ายหรือไม่)

โปรดจำไว้ว่าคุณอาจได้รับสตริงและไฟล์ดังนั้นการรอให้โมเดลสร้างอินสแตนซ์อาจมีราคาแพงมากเมื่อคำขอมาถึงเซิร์ฟเวอร์ของคุณ

สิ่งที่ฉันได้อธิบายที่นี่ฮิตที่เจตนาของคำขอที่เข้ามาผ่านตัวควบคุม การละเว้นการยืนยันเจตนาทำให้ใบสมัครของคุณมีความเสี่ยงมากขึ้น เจตนาจะดี (แสดงโดยกฎพื้นฐานของคุณ) หรือไม่ดี (ออกไปนอกกฎพื้นฐานของคุณ)

เจตนาสำหรับการร้องขอ HTTP เป็นข้อเสนอทั้งหมดหรือไม่มีอะไร ทุกอย่างผ่านไปหรือขอเป็นที่ไม่ถูกต้อง ไม่จำเป็นต้องส่งอะไรไปที่โมเดล

นี้ระดับพื้นฐานของ HTTP คำขอเจตนามีอะไรจะทำอย่างไรกับข้อผิดพลาดการป้อนข้อมูลผู้ใช้งานทั่วไปและการตรวจสอบ ในแอปพลิเคชันของฉันคำขอ HTTP ต้องถูกต้องในห้าวิธีด้านบนเพื่อให้ฉันได้รับเกียรติ ในการป้องกันในเชิงลึกวิธีการพูดที่คุณไม่เคยได้รับที่จะเข้าตรวจสอบผู้ใช้ในฝั่งเซิร์ฟเวอร์ถ้าใด ๆห้าสิ่งเหล่านี้ล้มเหลว

ใช่นี่หมายความว่าแม้การป้อนไฟล์จะต้องสอดคล้องกับความพยายามในการตรวจสอบและบอกขนาดสูงสุดให้กับผู้ใช้ HTML เท่านั้น ไม่มีจาวาสคริปต์? ใช้ได้ แต่ผู้ใช้จะต้องได้รับแจ้งผลที่ตามมาจากการอัปโหลดไฟล์ที่มีขนาดใหญ่เกินไป (ส่วนใหญ่แล้วพวกเขาจะสูญเสียข้อมูลในแบบฟอร์มทั้งหมดและถูกเตะออกจากระบบ)

4) นี่หมายความว่าข้อมูลการร้องขอ HTTPไม่ได้เป็นส่วนหนึ่งของตรรกะทางธุรกิจของแอปพลิเคชันหรือไม่ ไม่มันหมายถึงคอมพิวเตอร์เป็นอุปกรณ์ที่ จำกัด และต้องใช้ทรัพยากรอย่างฉลาด มันสมเหตุสมผลที่จะหยุดกิจกรรมที่เป็นอันตรายในไม่ช้าไม่ช้า คุณจ่ายเงินมากขึ้นในการคำนวณทรัพยากรเพื่อรอให้หยุดในภายหลัง

5) หากมีการป้อนข้อมูลการร้องขอ HTTPไม่ดีคำขอทั้งหมดจะไม่ดี นั่นคือวิธีที่ฉันดู นิยามของคำขออินพุต HTTP ที่ดีนั้นมาจากความต้องการทางธุรกิจของโมเดล แต่ต้องมีจุดแบ่งเขตทรัพยากร นานแค่ไหนที่คุณจะปล่อยให้คำขอที่ไม่ดีอยู่ก่อนที่จะฆ่ามันและพูดว่า "โอ้เฮ้ไม่เป็นไรขอไม่ดี"

การตัดสินไม่ได้เป็นเพียงแค่ผู้ใช้ที่ทำผิดพลาดในการป้อนข้อมูลที่สมเหตุสมผล แต่คำขอ HTTP นั้นไม่อยู่ในขอบเขตที่จะต้องมีการประกาศที่เป็นอันตรายและหยุดทันที

6) ดังนั้นสำหรับเงินของฉันการร้องขอ HTTP (วิธีการ, URL / เส้นทางและข้อมูล) เป็นสิ่งที่ดีหรือไม่สามารถดำเนินการต่อได้ แบบจำลองที่แข็งแกร่งมีงานการตรวจสอบที่เกี่ยวข้องกับตัวเองอยู่แล้ว แต่ผู้เลี้ยงที่ดีพูดว่า "ทางของฉันหรือทางที่สูงมาถูกต้องหรือไม่มาเลย"

มันเป็นโปรแกรมของคุณ "มีมากกว่าหนึ่งวิธีในการทำ" บางวิธีเสียเวลาและเงินมากกว่าวิธีอื่น การตรวจสอบความถูกต้องของข้อมูลคำขอ HTTP ในภายหลัง (ในรุ่น) ควรมีราคาสูงกว่าตลอดอายุการใช้งานของแอปพลิเคชัน

หากเครื่องมือตรวจสอบของคุณเป็นแบบแยกส่วนการตรวจสอบอินพุตคำขอ HTTP พื้นฐานในตัวควบคุมไม่น่าจะมีปัญหา เพียงแค่ใช้คลาส Validator ที่ผ่านการตรวจสอบแล้วซึ่งบางครั้งผู้ตรวจสอบจะประกอบด้วยผู้ตรวจสอบเฉพาะทางเช่นอีเมลโทรศัพท์ฟอร์มโทเค็นแคปช่า ...

บางคนเห็นว่านี่เป็นสิ่งที่ผิด แต่ HTTP อยู่ในช่วงเริ่มต้นเมื่อ Gang of Four เขียนรูปแบบการออกแบบ: องค์ประกอบของซอฟต์แวร์เชิงวัตถุที่ใช้ซ้ำได้

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

ตอนนี้เนื่องจากเกี่ยวข้องกับการตรวจสอบความถูกต้องของการป้อนข้อมูลผู้ใช้ปกติ (หลังจากที่คำขอ HTTP ได้รับการพิจารณาแล้วว่าถูกต้อง) ก็จะทำการอัปเดตมุมมองเมื่อผู้ใช้เกิดความยุ่งเหยิงที่คุณต้องพิจารณา! การตรวจสอบอินพุตของผู้ใช้ชนิดนี้ควรเกิดขึ้นในโมเดล

คุณไม่มีการรับประกันของ JavaScript ในส่วนหน้า ซึ่งหมายความว่าคุณไม่มีวิธีรับประกันการอัปเดตแบบอะซิงโครนัสของ UI แอปพลิเคชันของคุณด้วยสถานะข้อผิดพลาด การเพิ่มประสิทธิภาพแบบก้าวหน้าที่แท้จริงจะครอบคลุมกรณีการใช้แบบซิงโครนัสด้วย

การบัญชีสำหรับกรณีการใช้งานแบบซิงโครนัสนั้นเป็นศิลปะที่สูญหายไปมากขึ้นเรื่อย ๆ เพราะบางคนไม่ต้องการผ่านช่วงเวลาและความยุ่งยากในการติดตามสถานะของกลอุบาย UI ทั้งหมดของพวกเขา (แสดง / ซ่อนตัวควบคุมปิดใช้งาน / เปิดใช้งานการควบคุม ข้อบ่งชี้ข้อผิดพลาดข้อความผิดพลาด) ในส่วนท้าย (โดยปกติแล้วจะติดตามสถานะในอาร์เรย์)

ปรับปรุง : ในแผนภาพที่ผมบอกว่าควรอ้างอิงView Modelไม่ได้คุณควรส่งข้อมูลไปยังViewจากModelเพื่อรักษาคัปปลิ้งหลวม