Pure Front End JavaScript พร้อม Web API กับ MVC views ด้วย ajax

นี่เป็นการถกเถียงกันมากขึ้นว่าวันนี้ประชาชนคิดอย่างไรกับการแยกเว็บแอพพลิเคชั่น

ฉันคุ้นเคยกับการสร้างแอปพลิเคชัน MVC ด้วยมุมมองและตัวควบคุมทั้งหมด ปกติแล้วฉันจะสร้างมุมมองแบบเต็มและส่งผ่านสิ่งนี้กลับไปยังเบราว์เซอร์บนคำขอเต็มหน้าเว้นแต่จะมีพื้นที่เฉพาะที่ฉันไม่ต้องการให้ปรากฏทันทีและจะใช้กิจกรรมโหลดหน้า DOM เพื่อเรียกเซิร์ฟเวอร์เพื่อโหลดพื้นที่อื่น ใช้ AJAX

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

คำถามของฉันคือ ความคิดของฉันเกี่ยวกับโบราณนี้เพราะฉันมาจากพื้นหลัง. net มากกว่าพื้นหลังส่วนหน้าบริสุทธิ์หรือไม่

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

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

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

เว็บไซต์ที่เป็นปัญหาจะมีหลาย ๆ ด้านตั้งแต่การบริหารแบบฟอร์มการค้นหาผลิตภัณฑ์ ฯลฯ เว็บไซต์ที่ฉันไม่คิดว่าจะต้องทำการออกแบบให้ใช้งานได้ในแอปพลิเคชันหน้าเดียว

ทุกคนมีความคิดอย่างไรกับเรื่องนี้?

ฉันสนใจที่จะได้ยินจาก devs ส่วนหน้าและส่วนท้าย devs

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

เหตุผลนี้เป็นสิ่งที่ดีกว่าสำหรับ dev ของฝั่งไคลเอ็นต์เหมือนกับเหตุผลที่ไม่มีใครต้องการ HTML ในฐานข้อมูล ไคลเอ็นต์ฝั่งไคลเอ็นต์ควรทำอะไรเมื่อพวกเขาต้องการใช้ตารางเช่นเมื่อพวกเขาส่ง HTML? ต้นทุนประสิทธิภาพในการจัดการทั้งหมดที่อยู่บนไคลเอนต์นั้นเล็กน้อยเมื่อเทียบกับการขอเซิร์ฟเวอร์อื่นให้ทำเพื่อคุณ นอกจากนี้การสร้าง HTML นั้นค่อนข้างครอบคลุมใน JS-land การเรียงลำดับข้อมูลและสร้างแถวตาราง HTML ใหม่นั้นเป็นงานที่ไม่สำคัญสำหรับนักพัฒนาไคลเอนต์ที่มีประสบการณ์

และสิ่งที่ใช้เป็นสถาปัตยกรรมส่วนหลังไปยังส่วนหน้าสำหรับอุปกรณ์อื่นที่อาจต้องทำสิ่งที่แปลกใหม่เช่นใช้เครื่องมือที่มีผ้าใบ 100% หรือโครงสร้าง HTML ที่แตกต่างกันโดยสิ้นเชิง? ทำไมลูกค้าฝั่งควรโหลดสตูดิโอภาพหรือเคาะประตูด้านหลัง devs เพื่อทำการปรับแต่งการนำเสนออย่างเคร่งครัด?

สำหรับความกังวลของคุณเกี่ยวกับการสูญเสียการตรวจสอบเทมเพลตที่พิมพ์ออกมาอย่างหนักใจฉันเมื่อฉันบอกว่าถ้าคุณจัดการกับ dev ฝั่งไคลเอ็นต์ที่มีความสามารถคุณจะพบว่าไม่มี. NET Framework หรือเครื่องมือสตูดิโอภาพ การวิเคราะห์แบบเพชรต่อฝุ่นที่เกี่ยวข้องกับ HTML ที่ถูกต้องและเหมาะสมกว่าที่เป็นอยู่

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

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

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

• คุณมีประสบการณ์ที่เกี่ยวข้องในบ้านหรือไม่? การสร้างแอปที่ขับเคลื่อนโดยฝั่งไคลเอ็นต์นั้นต่างจากเซิร์ฟเวอร์ที่ขับเคลื่อนด้วยแอพส่วนใหญ่ที่มีชุดทักษะที่แตกต่างอย่างสิ้นเชิง
• คุณต้องการใช้เวลานานเท่าใดและเบราว์เซอร์ใดที่คุณต้องการสนับสนุน - ยิ่งลูกค้าทำเรื่องเบราว์เซอร์มากเท่าไหร่ IE8 นั้นเจ็บปวดและประสิทธิภาพของ JavaScript ค่อนข้างแย่ แต่มีธุรกิจจำนวนมากที่ใช้ XP / IE ในการเซ็ตอัพ
• ผู้ใช้ของคุณกำลังจะดูเว็บไซต์บนอุปกรณ์ใด การแยกวิเคราะห์และการเรียกใช้ JavaScript อาจทำงานอย่างรวดเร็วบน Chrome รุ่นล่าสุด - แต่ไม่ได้อยู่ในอุปกรณ์มือถือรุ่นเก่าโดยเฉพาะ JavaScript ที่มีจำนวนไม่มากและมีตรรกะทางธุรกิจมากมาย
• การโหลดเริ่มต้นสำคัญอย่างไร เซิร์ฟเวอร์เทมเพลตเร็วกว่าไคลเอ็นต์เทมเพลต

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

สำหรับฉันมันลงมาจากประสบการณ์ของผู้ใช้และการใช้งาน API ได้อีกครั้ง เพื่อกล่าวถึงแต่ละข้อเหล่านี้

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

อาร์กิวเมนต์ที่แข็งแกร่งที่สุดสำหรับโซลูชัน front-end บริสุทธิ์ (ในความคิดของฉัน) คือประสบการณ์การใช้งานของผู้ใช้

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

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

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

ฉันมีความสัมพันธ์ที่เกลียดชังกับการใช้งานที่หนักหน่วง

ในอีกด้านหนึ่งฉันรักการเขียน JavaScript และฉันรักเบราว์เซอร์เป็นสภาพแวดล้อมการดำเนินการ

ในทางกลับกันทั้งคู่รู้สึกเหมือนรถแข่งฟอร์มูล่าวันที่มีรูในเครื่องยนต์ มันช่วยลดความจริงลงได้: คุณสามารถป้องกันการทำซ้ำตรรกะทางธุรกิจระหว่าง C # และ JavaScript ได้หรือไม่? ถ้าเป็นเช่นนั้นใช้วิธีใดก็ได้ในการสร้างมุมมองที่คุณเห็นว่ามีค่า หากคุณกำลังทำซ้ำตรรกะทางธุรกิจในสองภาษาคุณอาจมีนักพัฒนาที่ต้องการเขียน JavaScript และไม่เห็นภาพรวมมากนัก

สำหรับความแตกต่างทางเทคนิค:

การแสดงผลบางส่วนและส่งไปยังลูกค้า:

• ใช้งานง่ายและรวดเร็ว
• ป้องกันไม่ให้ตรรกะทางธุรกิจของแบ็กเอนด์ถูกทำซ้ำที่ส่วนหน้า
• สามารถส่งผลให้เพย์โหลด HTTP ที่ใหญ่กว่ามากไปยังเบราว์เซอร์ ไม่ใช่สิ่งที่เลวร้ายบนเดสก์ท็อปที่มีการเชื่อมต่อแบนด์วิดธ์สูง แย่มากบนโทรศัพท์มือถือที่อ่อนแอในขณะที่คุณนั่งบนรถไฟชั่วโมงเร่งความเร็วที่ลู่วิ่งที่ 60mph และโทรศัพท์มือถืออีก 1,000 เครื่องกำลังตัดการเชื่อมต่อจากหอเซลล์หนึ่งและพยายามเชื่อมต่อกับหอคอยเซลล์ถัดไป

การส่ง JSON และการสร้างเท็มเพลตฝั่งไคลเอ็นต์:

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

บางครั้งฉันคิดว่าเฟรมเวิร์ก JavaScript ที่ใหม่กว่ากำลังโยนลูกน้อยออกไปด้วยน้ำอาบน้ำ --- ชายฉันหวังว่าฉันจะไม่เป็นโปรแกรมเมอร์ curmudgeon ที่ไม่พอใจ ...

ในแอปพลิเคชันสุดท้ายของฉันฉันรวม REST api และ JavaScript front-end

สิ่งที่ฉันทำคือ:

• ฉันสร้าง REST API สำหรับการดำเนินการ CRUD
• ฉันสร้างแอปพลิเคชัน Javascript ที่โหลดเทมเพลต HTML ที่กำหนดไว้ล่วงหน้าและเติมด้วยข้อมูลที่ส่งคืนจาก REST API

โดยทั่วไป JS front-end สื่อสารกับ REST API สำหรับการดำเนินการ CRUD และเติม HTML ด้วยข้อมูลที่ส่งคืนหรือข้อมูลที่สร้างขึ้นหรือลบข้อมูลที่ถูกลบหรืออัปเดตข้อมูลที่เปลี่ยนแปลง

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

ฉันไม่ได้ทำการตรวจสอบความถูกต้องทางธุรกิจที่ส่วนหน้าเพื่อความปลอดภัยและการทำสำเนารหัสเนื่องจากทุกคนสามารถเปลี่ยนข้อมูลก่อนที่จะส่งไปยังเซิร์ฟเวอร์และเราต้องตรวจสอบข้อมูลบนเซิร์ฟเวอร์อีกครั้ง ดังนั้นสิ่งนี้จะถูกแฮ็คได้ง่าย การตรวจสอบทั้งหมดเสร็จสิ้นหลังการตรวจสอบ การตรวจสอบความถูกต้องของฝั่งไคลเอ็นต์นั้นทำเพื่อประเภทอินพุตเท่านั้น

ข้อดี:

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

จุดด้อย:

• 2 แอปพลิเคชั่นที่ต้องดูแล
• ขึ้นอยู่กับการประมวลผลของลูกค้าซึ่งอาจไม่ดีเนื่องจากฮาร์ดแวร์ไม่ดี

หวังว่านี่จะช่วยได้

ความนับถือ,

เกี่ยวกับvalidationมุมมองใน Web Api - เป็นไปได้ที่จะทำ "การตรวจสอบความถูกต้องของโมเดล" และตอบกลับด้วยการตอบสนอง http คำขอที่ไม่ถูกต้อง 400 ครั้ง

อ้างอิง/programming/11686690/handle-modelstate-validation-in-asp-net-web-api/25050285#25050285