การจัดการการตรวจสอบฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์ในที่เดียว

17

ฉัน 100% ในคณะกรรมการที่มีกรณีที่หนึ่งควร แน่นอนใช้ทั้งฝั่งไคลเอ็นต์และเซิร์ฟเวอร์ด้านการตรวจสอบข้อมูล

อย่างไรก็ตามในกรอบงานและสภาพแวดล้อมที่ฉันได้ทำงานวิธีที่ฉันเห็นไม่เคยแห้ง เวลาส่วนใหญ่ไม่มีแผนหรือรูปแบบ - การตรวจสอบความถูกต้องถูกเขียนในสเป็คโมเดลและการตรวจสอบความถูกต้องจะถูกเขียนในแบบฟอร์มในมุมมอง (หมายเหตุ: ประสบการณ์มือแรกของฉันส่วนใหญ่คือ Rails, Sinatra และ PHP w / jQuery)

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

เห็นได้ชัดว่าข้างต้นเป็นเพียง "เฮ้ฉันมีความคิดนี้" รำพึงและไม่ใช่ข้อเสนออย่างเป็นทางการ สิ่งนี้เป็นเรื่องยากกว่าที่คิดเมื่อฉันคิด

นั่นนำมาสู่คำถาม: คุณจะออกแบบเทคนิค "การเขียนครั้งเดียวทำงานบนเซิร์ฟเวอร์และไคลเอนต์" ได้อย่างไรเพื่อการตรวจสอบข้อมูล

หัวข้อย่อยที่เกี่ยวข้อง: เครื่องมือเช่นนี้มีอยู่สำหรับเฟรมเวิร์กเฉพาะหรือเทคโนโลยีไคลเอ็นต์เซิร์ฟเวอร์หรือไม่? gotchas หรือความท้าทายที่สำคัญด้วยการพยายามรักษาชุดตรวจสอบเพียงชุดเดียวคืออะไร

— asfallows
แหล่งที่มา

6

จากประสบการณ์ที่ จำกัด ของฉันจุดที่ต้องมีการตรวจสอบความถูกต้องคือ

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

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

แนวคิดที่เกี่ยวข้องคือการแสดงข้อมูลแตกต่างกันไปในแต่ละระดับ ตัวอย่างง่ายๆคือเว็บเบราว์เซอร์แทนข้อความบางส่วนเช่น CP1290 ในขณะที่ฐานข้อมูลแสดงใน UTF-8 ความยาวของทั้งสองสายแตกต่างกันดังนั้นการบังคับใช้ข้อ จำกัด ด้านความยาวจึงเกิดขึ้นอย่างไม่แน่นอน

— BobDalgleish
แหล่งที่มา

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

— Michael Durrant

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

— ด่าน

5

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

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

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

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

{field: 'username', type: 'required'}
{field: 'username', type: 'unique'} //requires a network roundtrip
{field: 'password', type: 'length', min: 10, max: 50}
{field: 'password', type: 'contains', characters: ['upper', 'special', 'letter', 'number']}

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

— Mario T. Lanza
แหล่งที่มา

คุณอธิบายฟิลด์อย่างไรเมื่อมีการแสดงฟิลด์ต่างกันในเว็บเบราว์เซอร์การขนส่งภาษาที่ใช้งานและฐานข้อมูล ตัวอย่างเช่นจำนวนไบต์ที่ต้องใช้ในการแสดงเขตข้อมูลสตริงจะแตกต่างกันเมื่อใช้ CP1290 (IE), UTF-8 (JSON), UTF-8 (C #) หรือ UCS-16 (Oracle) ข้อจำกัดความยาวหมายถึงอะไร สำคัญกว่าสำหรับเบราว์เซอร์เมื่อการแสดงอักขระขึ้นอยู่กับเบราว์เซอร์และระบบปฏิบัติการหรือไม่

— BobDalgleish

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

— Mario T. Lanza

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

— BobDalgleish

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

— Mario T. Lanza

1

ภาษาการตรวจสอบดังกล่าวจะมีประโยชน์มาก มันอาจแทนที่หนึ่งในสามของรหัสที่เกี่ยวข้องกับเว็บแอปพลิเคชันที่ใช้งาน UI ได้

— BobDalgleish

2

วิธีหนึ่งคือการใช้ภาษา / กรอบงานเดียวกันทั้งบนเซิร์ฟเวอร์และฝั่งไคลเอ็นต์

เช่น

Node.js :: ไคลเอ็นต์ / เซิร์ฟเวอร์ใน JavaScript GET :: ไคลเอ็นต์ / เซิร์ฟเวอร์ใน Java

ในกรณีนี้รหัส "วัตถุโดเมน" ส่วนใหญ่จะเป็นเรื่องปกติซึ่งจะรวมถึงการตรวจสอบความถูกต้อง Framework จะเรียกใช้โค้ดตามต้องการ เช่นรหัสเดียวกันจะถูกเรียกใช้ในเบราว์เซอร์ก่อน "ส่ง" และบนบริการเว็บฝั่งเซิร์ฟเวอร์

แก้ไข (มิถุนายน / 2014): ด้วย Java 8 ตอนนี้ง่ายต่อการรวมรหัสตรวจสอบ JS ใน Java Applications เช่นกัน Java 8 มีเอ็นจินการเรียกใช้งาน JS ใหม่ที่ถาวรมากขึ้น (เช่น: ใช้ประโยชน์จาก invokeDynamic)

— Shamit Verma
แหล่งที่มา

เมื่อมันมาถึงฐานข้อมูล SQL ไม่แน่ใจว่ามันจะทำงานอย่างไร

— Michael Durrant

นอกจากนี้ยังไม่ได้แก้ปัญหาที่เบราว์เซอร์และระบบปฏิบัติการส่งผลกระทบต่อโดเมนอินพุต

— BobDalgleish

@Micheal Durrant สำหรับการตรวจสอบความถูกต้องของฐานข้อมูลนั้นถูกนำมาใช้เป็นข้อ จำกัด ของฐานข้อมูล (เช่น foreign key, unique ฯลฯ ) BobDalgleish, 1. ปัญหาความเข้ากันได้ของเบราว์เซอร์ / ระบบปฏิบัติการสามารถลดลงได้โดยใช้ Library ที่ปรับแต่ง runtime ตาม Browser (เช่น Sencha) 2. comatibility ของเบราว์เซอร์ตามปกติจะไม่ส่งผลกระทบต่อส่วน "ตรรกะ" ของรหัสเช่นการตรวจสอบ รอบการแสดงผล DOM / UI

— Shamit Verma

0

ฉันแค่คิดเกี่ยวกับปัญหาเดียวกัน ฉันกำลังคิดที่จะใช้ ANTLR เพื่อให้ได้โครงสร้างต้นไม้นามธรรมทั้ง C # และ javascript จากนั้นคุณใช้ tree walkers เพื่อใช้การกระทำที่ระบุในภาษากับวัตถุที่จะตรวจสอบความถูกต้อง

ดังนั้นคุณสามารถเก็บคำอธิบายของการตรวจสอบความถูกต้องที่คุณต้องการ - อาจอยู่ในฐานข้อมูล

นี่คือวิธีที่ฉันจะแก้ไขปัญหา

— มาร์คัส
แหล่งที่มา