หลักการเจ็ดประการในการสร้างเว็บแอปพลิเคชันสมัยใหม่ มาเริ่มศึกษาเทคโนโลยีเว็บกันดีกว่า การจัดแคมเปญโฆษณา
บทความนี้กล่าวถึงผู้ใช้อินเทอร์เน็ตเป็นหลัก เป้าหมายคือการเน้นเทคโนโลยีอินเทอร์เน็ตสมัยใหม่บางอย่างจากมุมมองของผู้บริโภค อย่างไรก็ตาม ตามที่แสดงให้เห็นในทางปฏิบัติ ความรู้เกี่ยวกับปัญหาดังกล่าวก็เป็นสิ่งจำเป็นสำหรับนักพัฒนามือใหม่บางคนเช่นกัน
10-15 ปีที่แล้ว เว็บไซต์ส่วนใหญ่เป็นชุดของหน้า HTML แบบคงที่ ปัจจุบันนี้ยังคงพบไซต์ดังกล่าว - บ่อยครั้งเว็บไซต์ส่วนตัวขนาดเล็กได้รับการออกแบบในลักษณะนี้ เช่นเดียวกับไซต์ของบริษัทขนาดเล็กที่ไม่แสร้งทำเป็นอย่างอื่นนอกจากการโพสต์ข้อมูลที่ไม่ค่อยเปลี่ยนแปลงจำนวนค่อนข้างน้อย อย่างไรก็ตาม โปรดทราบว่าในกระบวนการเปลี่ยนอินเทอร์เน็ตจากชุดแหล่งข้อมูลเป็นเครื่องมือในการทำธุรกิจ เทคโนโลยีการสร้างเว็บไซต์มีการเปลี่ยนแปลงอย่างมาก - เว็บไซต์ส่วนใหญ่ของบริษัทขนาดใหญ่เป็นชุดแอปพลิเคชันที่มีการโต้ตอบ เครื่องมือปรับแต่งส่วนบุคคล และวิธีการโต้ตอบกับลูกค้า (ขึ้นอยู่กับการรับคำสั่งซื้อและการชำระเงิน) และคู่ค้า และบ่อยครั้ง - วิธีการรวมเข้ากับแอปพลิเคชันองค์กร "ภายใน" ของบริษัท เครื่องมือสำหรับการสร้างเว็บไซต์ดังกล่าวจะกล่าวถึงรายละเอียดเพิ่มเติมอีกเล็กน้อยในบทความ “ผลิตภัณฑ์สำหรับการสร้างโซลูชันอินเทอร์เน็ตขององค์กร” ในนิตยสารฉบับนี้ ในบทความนี้เราจะเน้นสั้นๆ ถึงเทคโนโลยีที่เป็นพื้นฐานของเว็บแอปพลิเคชันสมัยใหม่เท่านั้น ผู้ใช้ที่เกี่ยวข้องกับแอปพลิเคชันบนเว็บ (และล่าสุดคือบริการบนเว็บ) สื่อสารกับแอปพลิเคชันเหล่านั้นผ่านไคลเอนต์อินเทอร์เน็ต (ส่วนใหญ่มักเป็นเบราว์เซอร์ แต่ไม่เพียงเท่านั้น ยังมีแอปพลิเคชันไคลเอนต์ประเภทอื่น ๆ เช่น ไคลเอนต์แชท) ดังนั้นจึงเหมาะสมที่จะพูดคุยแยกกันเกี่ยวกับสิ่งที่สามารถใช้ได้ในแอปพลิเคชันไคลเอนต์และสิ่งที่สามารถใช้บนเว็บเซิร์ฟเวอร์ได้
เทคโนโลยีที่ใช้ในเว็บไคลเอ็นต์หนึ่งในแนวโน้มล่าสุดในการพัฒนาเว็บแอปพลิเคชันคือการวางตำแหน่งบางส่วนของตรรกะของแอปพลิเคชัน (เช่น การตรวจสอบความถูกต้องของข้อมูลอินพุต) ในตัวเว็บไคลเอ็นต์ ตัวอย่างเช่น ในเว็บเบราว์เซอร์ โดยเฉพาะอย่างยิ่ง เว็บเบราว์เซอร์สมัยใหม่มีความสามารถในการตีความโค้ดในภาษาสคริปต์ เรียกใช้แอปเพล็ต Java และตัวควบคุม ActiveX และใช้โปรแกรมเสริมอื่นๆ เช่น Macromedia Flash Player มาดูความสามารถทั้งหมดของเบราว์เซอร์เหล่านี้กันดีกว่า
เว็บเบราว์เซอร์สมัยใหม่ส่วนใหญ่สามารถตีความโค้ดในภาษาสคริปต์ เช่น VBScript และ JavaScript รหัสในภาษาเหล่านี้ถูกฝังอยู่ในเว็บเพจและตีความโดยเบราว์เซอร์ ตัวอย่างทั่วไปของการใช้ภาษาสคริปต์คือการตรวจสอบความถูกต้องของข้อมูลที่ผู้ใช้ป้อนลงในฟิลด์ที่เกี่ยวข้องของรูปแบบ HTML โดยตรงในระหว่างกระบวนการป้อนข้อมูลหรือหลังจากนั้นโดยไม่ต้องติดต่อกับเว็บเซิร์ฟเวอร์ ตัวอย่างที่คล้ายกันของการใช้ภาษาสคริปต์สามารถพบได้เมื่อกรอกแบบสอบถามและรับข้อความที่ไม่ได้กรอกข้อมูลในช่องที่จำเป็น (ตามความเป็นจริงเราทราบว่าแบบสอบถามบางรายการไม่ได้ถูกนำมาใช้ในลักษณะนี้)
อย่างไรก็ตาม มีตัวอย่างอื่น ๆ ของการใช้ภาษาสคริปต์ที่ใช้ทั้งแนวคิดการออกแบบเพียงอย่างเดียว เช่น ปุ่มที่เปลี่ยนรูปลักษณ์เมื่อคุณวางเมาส์เหนือปุ่ม "ไม้เลื้อย" และฟังก์ชันอื่น ๆ เช่น วิธีการเข้าถึงการค้นหา กลไกที่ฝังอยู่ในเว็บเพจ การแสดงแผงข้อความ การจัดการอ็อบเจ็กต์อื่นๆ ที่ฝังอยู่ในเว็บเพจ (เช่น Java Applet หรือตัวควบคุม ActiveX ซึ่งจะกล่าวถึงด้านล่าง)
โปรดทราบว่าโค้ดที่สร้างโดยใช้ภาษาสคริปต์ไม่สามารถทำงานได้ด้วยตัวเอง แต่จะทำงานในพื้นที่ที่อยู่ของเบราว์เซอร์ นอกจากนี้ ภาษาสคริปต์ยังมีชุดสิ่งอำนวยความสะดวกที่จำกัด (เช่น ไม่มีเครื่องมือสำหรับการเข้าถึงระบบไฟล์)
เบราว์เซอร์สมัยใหม่เกือบทั้งหมดสามารถแสดงและเรียกใช้แอปเพล็ต Java ซึ่งเป็นแอปพลิเคชัน Java พิเศษที่ผู้ใช้ได้รับโดยเป็นส่วนหนึ่งของเว็บเพจ แอปพลิเคชันเหล่านี้มักจะรวมอยู่ในเว็บเพจเพื่อเพิ่มฟังก์ชันการทำงานที่ยากหรือเป็นไปไม่ได้ที่จะนำไปใช้โดยใช้ภาษาสคริปต์ Applets สามารถทำงานได้บนทุกแพลตฟอร์มที่มี Java Virtual Machine ให้บริการ
โดยทั่วไปแล้วแอพเพล็ตจะถูกสร้างขึ้นตามกฎที่ระบุว่าจะมีชีวิตอยู่นานแค่ไหนและจะโต้ตอบกับสภาพแวดล้อมอย่างไร ส่วนใหญ่แล้ว วิธีการเหล่านี้มีข้อจำกัดมาก (เช่น การดำเนินการต่างๆ เช่น การอ่านและการเขียนไฟล์เป็นสิ่งต้องห้ามสำหรับแอปเพล็ตตามค่าเริ่มต้น หากจำเป็นต้องมีการดำเนินการดังกล่าว การอนุญาตในการดำเนินการสำหรับแอปเพล็ตเฉพาะและไฟล์เฉพาะจะมีการอธิบายไว้ในคอมพิวเตอร์ไคลเอนต์ เครือข่าย การเข้าถึงจากแอปเพล็ตสามารถทำได้เฉพาะกับคอมพิวเตอร์ที่ดาวน์โหลดเท่านั้น ไม่สามารถเปิดแอปพลิเคชันอื่นบนคอมพิวเตอร์ของผู้ใช้จากแอปเพล็ตได้) อย่างไรก็ตาม แอปเพล็ตสามารถอ่านค่าของพารามิเตอร์ (เช่น สี แบบอักษร ไฟล์กราฟิกที่ใช้ในการเรียกใช้งานแอปเพล็ต) จากเว็บเพจที่มีอยู่และเปลี่ยนลักษณะการทำงานตามพารามิเตอร์เหล่านี้ นอกจากนี้พารามิเตอร์แอปเพล็ตยังสามารถเปลี่ยนแปลงได้แบบไดนามิกจากโค้ดในภาษาสคริปต์ที่มีอยู่ในหน้าเดียวกัน
โปรดทราบว่าเนื่องจากแอปเพล็ตใช้การเรียกใช้โค้ดบนคอมพิวเตอร์ไคลเอนต์ จึงมีเนื้อหาที่อาจเป็นอันตรายได้ในระดับหนึ่ง นั่นคือเหตุผลที่เบราว์เซอร์สมัยใหม่ทั้งหมดมีวิธีให้ผู้ใช้จำกัดความสามารถในการดำเนินการของแอปเพล็ต
เบราว์เซอร์สมัยใหม่บางตัว (โดยเฉพาะ Microsoft Internet Explorer) สามารถทำหน้าที่เป็นคอนเทนเนอร์สำหรับตัวควบคุม ActiveX - เซิร์ฟเวอร์ COM พิเศษที่ทำงานในพื้นที่ที่อยู่ของเบราว์เซอร์ และยังได้รับเป็นส่วนหนึ่งของเว็บเพจด้วย
ด้วยความช่วยเหลือของตัวควบคุม ActiveX เช่นเดียวกับแอปเพล็ต Java คุณสามารถใช้งานฟังก์ชันต่างๆ รวมถึงฟังก์ชันที่ไม่เอื้ออำนวยต่อคอมพิวเตอร์ของผู้ใช้ได้ ในขณะที่เมื่อเรียกใช้ตัวควบคุม ActiveX โดยทั่วไปจะไม่มีข้อจำกัดในการเข้าถึงไฟล์และต่างจากแอปเพล็ต Java ทรัพยากรอื่นๆ ของระบบปฏิบัติการและเครือข่าย และโค้ดที่มีอยู่ในนั้นจะถูกดำเนินการในนามของผู้ใช้ที่ดาวน์โหลดทรัพยากรเหล่านั้น เช่นเดียวกับแอปเพล็ต Java ตัวควบคุม ActiveX สามารถอ่านคุณสมบัติได้จากเพจที่มีคุณสมบัติเหล่านั้น นอกจากนี้คุณสมบัติของตัวควบคุม ActiveX ยังสามารถเปลี่ยนแปลงได้แบบไดนามิกจากโค้ดในภาษาสคริปต์ที่มีอยู่ในหน้าเดียวกัน ในโค้ดเดียวกัน คุณสามารถจัดการเหตุการณ์ที่เกิดขึ้นในการควบคุมดังกล่าวได้
ต่อไป เราควรระลึกถึงความจริงอันซ้ำซากซึ่งตามการปฏิบัติแสดงให้เห็นว่าผู้อ่านทุกคนของเราไม่ชัดเจน เมื่อทำงานกับตัวควบคุม ActiveX และแอปเพล็ต Java การพึ่งพาซอฟต์แวร์ป้องกันไวรัสนั้นไม่มีประโยชน์อย่างยิ่ง (ไม่ว่าจะเป็นไคลเอนต์หรือเซิร์ฟเวอร์ก็ตาม): ตามกฎแล้วแอปพลิเคชันดังกล่าวไม่แสดงสัญญาณลักษณะของไวรัส (เช่นความสามารถ เพื่อฝังตัวเองไว้ในไฟล์ปฏิบัติการและเอกสาร) คุณสามารถป้องกันการดาวน์โหลดหรือเรียกใช้โค้ดที่เกี่ยวข้องได้เฉพาะที่ระดับการตั้งค่าเบราว์เซอร์หรือที่ระดับไฟร์วอลล์ขององค์กรหรือส่วนบุคคลเท่านั้น
แอปพลิเคชัน Macromedia Flash เป็นส่วนขยายที่ได้รับความนิยมมากที่สุดสำหรับเว็บเบราว์เซอร์ในปัจจุบัน และนักออกแบบเว็บไซต์จำนวนมากใช้แอปพลิเคชันเหล่านี้เพื่อเพิ่มการโต้ตอบและความคิดริเริ่มให้กับไซต์ของตน
รูปแบบการรักษาความปลอดภัยสำหรับแอปพลิเคชัน Flash ขึ้นอยู่กับข้อเท็จจริงที่ว่า Macromedia Flash Player เช่นเดียวกับเครื่องเสมือน Java เรียกใช้แอปพลิเคชันในพื้นที่ที่อยู่จำกัด และแอปพลิเคชันที่ทำงานอยู่ไม่สามารถเข้าถึงระบบไฟล์ได้ (ยกเว้นไดเรกทอรีเฉพาะหนึ่งรายการที่ใช้โดย Macromedia Flash Player สำหรับวัตถุประสงค์ภายใน ) และทรัพยากรอื่น ๆ ของคอมพิวเตอร์ของผู้ใช้ มีข้อยกเว้นสำหรับไมโครโฟนและกล้องวิดีโอ แต่ผู้ใช้จะต้องให้สิทธิ์ในการส่งข้อมูลที่ได้รับจากอุปกรณ์เหล่านี้ การเข้าถึงทรัพยากรเครือข่ายถูกจำกัดไว้ที่โดเมนที่ได้รับแอปพลิเคชัน โปรดทราบว่าแอปพลิเคชัน Flash สามารถควบคุมได้โดยใช้โค้ด JavaScript ที่อยู่ในหน้าเดียวกัน Macromedia Flash Player สำหรับ Microsoft Internet Explorer นั้นเป็นตัวควบคุม ActiveX และใช้ความสามารถของตัวควบคุม ActiveX เพื่อเข้าถึงคุณสมบัติแอปพลิเคชัน Flash จากภาษาสคริปต์
โปรดทราบว่านอกเหนือจากวิธีที่ได้รับความนิยมสูงสุดในการขยายฟังก์ชันการทำงานของเบราว์เซอร์ที่ระบุไว้ข้างต้นแล้ว ยังมีเครื่องมืออื่นๆ อีกจำนวนหนึ่ง ซึ่งมักจะใช้งานในรูปแบบของสิ่งที่เรียกว่าปลั๊กอิน เนื่องจากโมดูลส่วนขยายเป็นโค้ดที่เรียกใช้งานได้ เบราว์เซอร์สมัยใหม่จึงมีวิธีการบางอย่างในการจำกัดความสามารถที่เกี่ยวข้องกับการโหลดและเรียกใช้งาน
โดยสรุป เราทราบว่าเครื่องมือที่ระบุไว้สำหรับการขยายการทำงานของหน้า HTML สามารถใช้ในหน้าไดนามิกที่สร้างโดยแอปพลิเคชันเว็บฝั่งเซิร์ฟเวอร์ได้เช่นกัน ดังนั้นเมื่อเร็ว ๆ นี้เครื่องมือสำหรับการสร้างแอปพลิเคชันเว็บที่ทำงานภายใต้การควบคุมของเว็บเซิร์ฟเวอร์และสร้างหน้า HTML แบบไดนามิกพร้อมโค้ดฝังตัวในภาษาสคริปต์ซึ่งมีจุดประสงค์เพื่อการตีความโดยเบราว์เซอร์จึงแพร่หลายมากขึ้น
ดังที่เราได้เห็นไปแล้ว ความสามารถที่เกี่ยวข้องกับการรันโค้ดในเว็บไคลเอ็นต์อาจถูกจำกัดอย่างมากทั้งในด้านเทคโนโลยีและผ่านการตั้งค่าการดูแลระบบและผู้ใช้ โดยทั่วไปแล้วสิ่งนี้จะเป็นไปตามข้อกำหนดด้านความปลอดภัยที่ค่อนข้างสมเหตุสมผล นั่นคือเหตุผลว่าทำไมพร้อมกับการพัฒนาเครื่องมือสำหรับขยายฟังก์ชันการทำงานของเบราว์เซอร์ เทคโนโลยีที่เกี่ยวข้องกับการประมวลผลโค้ดแอปพลิเคชันที่ไม่ได้อยู่ในเบราว์เซอร์ แต่บนเว็บเซิร์ฟเวอร์เองก็ได้รับการพัฒนาเช่นกัน ด้านล่างนี้เราจะดูรายการที่พบบ่อยที่สุดโดยย่อ
Common Gateway Interface (CGI) เป็นอินเทอร์เฟซมาตรฐานที่ช่วยให้แอปพลิเคชันฝั่งเซิร์ฟเวอร์สามารถดำเนินการผ่าน URL ได้ ข้อมูลอินพุตสำหรับแอปพลิเคชันดังกล่าวคือเนื้อหาของส่วนหัว HTTP หรือเนื้อหาของคำขอ ขึ้นอยู่กับโปรโตคอลที่ใช้ แอปพลิเคชัน CGI สร้างโค้ด HTML ที่ส่งคืนไปยังเบราว์เซอร์ โปรดทราบว่าในครั้งเดียวคำว่า "สคริปต์ CGI" ก็ถูกใช้อย่างกว้างขวางเช่นกัน ต้นกำเนิดของสิ่งนี้อธิบายได้จากข้อเท็จจริงที่ว่าแอปพลิเคชันดังกล่าวเขียนด้วยภาษาสคริปต์เช่น Perl ซึ่งอย่างไรก็ตามไม่ได้ดำเนินการในเบราว์เซอร์ แต่บนเซิร์ฟเวอร์ แอปพลิเคชัน CGI สามารถสร้างได้โดยใช้เครื่องมือพัฒนาเกือบทุกชนิดที่สร้างแอปพลิเคชันคอนโซลสำหรับระบบปฏิบัติการที่รันเว็บเซิร์ฟเวอร์
ปัญหาหลักของแอปพลิเคชัน CGI ทั้งหมดก็คือ ในแต่ละคำขอของลูกค้า เซิร์ฟเวอร์จะโหลดแอปพลิเคชันลงในพื้นที่ที่อยู่แยกต่างหาก จากนั้นจึงเริ่มดำเนินการและยกเลิกการโหลด คุณลักษณะนี้จำกัดประสิทธิภาพของแอปพลิเคชันและความสามารถในการประมวลผลคำขอของลูกค้าจำนวนมากพร้อมกัน
ปัญหาประสิทธิภาพที่จำกัดของเว็บแอปพลิเคชันที่ทำงานในพื้นที่ที่อยู่แยกต่างหากสามารถแก้ไขได้โดยการสร้างแอปพลิเคชันเป็นไลบรารีที่โหลดลงในพื้นที่ที่อยู่ของเว็บเซิร์ฟเวอร์ และหากจำเป็น จะยังคงอยู่ที่นั่นเพื่อจัดการกับคำขอที่ตามมาจากไคลเอนต์อื่น โดยปกติแล้ว ในกรณีนี้ เว็บเซิร์ฟเวอร์จะต้องรองรับการโหลดไลบรารีดังกล่าว แอปพลิเคชันที่คล้ายกันสำหรับ Microsoft Internet Information Service เรียกว่า ISAPI (Internet Server Application Program Interface) และสำหรับเว็บเซิร์ฟเวอร์ Apache ที่ได้รับความนิยมมาก ไลบรารีดังกล่าวเรียกว่า Apache DSO (Dynamic Shared Objects) อย่างไรก็ตาม โปรดทราบว่าเมื่อสร้างทั้งแอปพลิเคชัน CGI และ ISAPI เป็นการยากที่จะแยกงานการออกแบบเว็บออกจากงานที่เกี่ยวข้องกับการใช้งานฟังก์ชันและตรรกะของแอปพลิเคชัน - แอปพลิเคชันดังกล่าวสร้างเว็บเพจทั้งหมด ดังนั้นข้อมูลทั้งหมดที่เกี่ยวข้องกับ โดยทั่วไปการออกแบบหน้าเหล่านี้ควรอยู่ในไฟล์ปฏิบัติการ
ขั้นตอนต่อไปในการพัฒนาเทคโนโลยีสำหรับการสร้างแอปพลิเคชันอินเทอร์เน็ตคือการเกิดขึ้นของเครื่องมือที่ทำให้สามารถแยกงานออกแบบเว็บไซต์ออกจากงานที่เกี่ยวข้องกับการใช้ฟังก์ชันการทำงานของแอปพลิเคชัน เทคโนโลยีแรกคือ Active Server Pages (ASP) ซึ่งสร้างขึ้นบนพื้นฐานของตัวกรอง ISAPI แนวคิดหลักของ ASP คือการสร้างเว็บเพจที่มีส่วนของโค้ดฝังอยู่ในภาษาสคริปต์ อย่างไรก็ตาม ตรงกันข้ามกับวิธีการใช้ภาษาสคริปต์ที่กล่าวถึงข้างต้นเพื่อขยายการทำงานของเบราว์เซอร์ ส่วนของโค้ดเหล่านี้ไม่ได้ถูกตีความโดยเบราว์เซอร์ แต่โดยเซิร์ฟเวอร์ (แม่นยำยิ่งขึ้นโดยไลบรารี ISAPI ที่มีวัตถุประสงค์เพื่อจุดประสงค์นี้) และผลลัพธ์ของการดำเนินการส่วนของโค้ดเหล่านี้จะแทนที่ส่วนของโค้ดในเวอร์ชันของเพจนั้น ซึ่งถูกส่งไปยังเบราว์เซอร์ของผู้ใช้ ไม่นานหลังจาก ASP เทคโนโลยีอื่น ๆ ก็ปรากฏขึ้นซึ่งใช้แนวคิดในการวางโค้ดที่ดำเนินการโดยเว็บเซิร์ฟเวอร์ภายในเว็บเพจ สิ่งที่มีชื่อเสียงที่สุดในปัจจุบันคือเทคโนโลยี JSP (Java Server Pages) ซึ่งมีแนวคิดหลักคือการคอมไพล์โค้ด Java (servlet) เพียงครั้งเดียวในการเข้าถึงครั้งแรก การดำเนินการตามวิธีการของเซิร์ฟเล็ตนี้และ วางผลลัพธ์ของการดำเนินการวิธีการเหล่านี้ในชุดข้อมูลที่ส่งไปยังเบราว์เซอร์ เทคโนโลยียอดนิยมอีกประเภทหนึ่งคือ PHP (Personal Home Pages) ซึ่งใช้แอปพลิเคชัน CGI ที่ตีความโค้ดที่ฝังอยู่ในหน้า HTML ในภาษาสคริปต์
เทคโนโลยี Active Server Pages เวอร์ชันใหม่ล่าสุดคือ ASP .NET ซึ่งเป็นแกนหลักของสถาปัตยกรรม Microsoft .NET Framework ความแตกต่างที่สำคัญระหว่างเทคโนโลยีนี้กับ ASP จากมุมมองของสถาปัตยกรรมแอปพลิเคชันคือ โค้ดที่ปรากฏบนเว็บเพจไม่ได้ถูกตีความ แต่จะถูกคอมไพล์และแคช ซึ่งจะช่วยปรับปรุงประสิทธิภาพของแอปพลิเคชันตามธรรมชาติ
การใช้ ASP .NET คุณสามารถสร้างแอปพลิเคชันเว็บและบริการบนเว็บที่ไม่เพียงแต่ช่วยให้คุณสามารถใช้การสร้างเพจ HTML แบบไดนามิกเท่านั้น แต่ยังรวมเข้ากับส่วนประกอบเซิร์ฟเวอร์และสามารถใช้เพื่อแก้ไขปัญหาทางธุรกิจที่หลากหลายที่เกิดขึ้นก่อนนักพัฒนาซอฟต์แวร์สมัยใหม่ แอปพลิเคชันบนเว็บ
โดยทั่วไป ไคลเอ็นต์ของเว็บเซิร์ฟเวอร์ไม่เพียงแต่เป็นคอมพิวเตอร์ส่วนบุคคลที่ติดตั้งเว็บไคลเอ็นต์ทั่วไป (เช่น เว็บเบราว์เซอร์) เท่านั้น แต่ยังรวมถึงอุปกรณ์เคลื่อนที่ที่มีขนาดหน้าจอที่จำกัด หน่วยความจำจำนวนเล็กน้อย และมักจะไม่สามารถ แสดงกราฟิก อุปกรณ์เหล่านี้มีโปรโตคอลการถ่ายโอนข้อมูลของตัวเอง (Wireless Access Protocol, WAP) และภาษามาร์กอัปที่เกี่ยวข้อง (WML, Wireless MarkupLanguage, СHTML, Compact HTML ฯลฯ ) ในกรณีนี้ จำเป็นต้องถ่ายโอนข้อมูลไปยังอุปกรณ์มือถือในรูปแบบที่เหมาะสม ซึ่งมักจะสร้างไซต์พิเศษ (เช่น รองรับ WAP และ WML) ดูเหมือนว่าสะดวกกว่าในการสร้างแอปพลิเคชันที่สามารถสร้างรหัสหนึ่งหรือรหัสอื่นได้ขึ้นอยู่กับประเภทของไคลเอนต์ นี่เป็นแนวทางที่นำมาใช้ใน Microsoft ASP .NET
เมื่อปริมาณข้อมูลที่ใช้และจำนวนผู้เยี่ยมชมเว็บไซต์เพิ่มขึ้น ข้อกำหนดสำหรับความน่าเชื่อถือ ประสิทธิภาพ และความสามารถในการปรับขนาดของเว็บแอปพลิเคชันก็เพิ่มขึ้น เพื่อให้เป็นไปตามข้อกำหนดเหล่านี้ ตรรกะทางธุรกิจที่ใช้ในเว็บแอปพลิเคชัน เช่นเดียวกับการประมวลผลข้อมูลและบริการธุรกรรม จะถูกแยกออกจากอินเทอร์เฟซของแอปพลิเคชัน และถ่ายโอนไปยังเซิร์ฟเวอร์แอปพลิเคชันในรูปแบบของออบเจ็กต์ทางธุรกิจ แอปพลิเคชันเซิร์ฟเวอร์และออบเจ็กต์ทางธุรกิจที่เกี่ยวข้องสามารถมีได้หลายประเภท (โดยทั่วไปในปัจจุบันคือเซิร์ฟเวอร์ที่รองรับข้อกำหนด Java2 Enterprise Edition และเซิร์ฟเวอร์ที่ใช้เทคโนโลยี COM และ Microsoft .NET) อย่างไรก็ตาม การพิจารณาแอพพลิเคชั่นเซิร์ฟเวอร์อยู่นอกเหนือขอบเขตของบทความนี้...
โปรดทราบว่าออบเจ็กต์ทางธุรกิจมักจะให้การเข้าถึงข้อมูลจากระบบข้อมูลขององค์กรหรือใช้ฟังก์ชันการทำงานบางส่วน โดยทำหน้าที่รวมแอปพลิเคชันเว็บเข้ากับแอปพลิเคชันอื่นที่ใช้ในองค์กร
เมื่อพูดถึงเทคโนโลยีเว็บฝั่งเซิร์ฟเวอร์ เราไม่สามารถละเลยบางสิ่งที่สำคัญเท่ากับบริการเว็บ XML ได้ ปัจจุบันบริการเว็บ XML มักได้รับมอบหมายให้แก้ไขปัญหาต่างๆ ที่เกี่ยวข้องกับการรวมแอปพลิเคชัน รวมถึงปัญหาที่สร้างขึ้นบนแพลตฟอร์มที่แตกต่างกัน คุณสามารถสร้างบริการทางเว็บในรูปแบบของไฟล์ปฏิบัติการ ในรูปแบบของไลบรารี และในรูปแบบของโค้ดที่ตีความ นอกจากนี้ยังมีวิธีการแสดงวัตถุทางธุรกิจในรูปแบบของบริการบนเว็บ วิธีการบริการเว็บสามารถเรียกได้จากแอปพลิเคชันทั่วไป แอปพลิเคชันบนเว็บ และบริการบนเว็บอื่นๆ และมีข้อยกเว้นที่ไม่ค่อยเกิดขึ้น ผู้ใช้ปลายทางจะไม่โต้ตอบกับบริการบนเว็บโดยตรง อย่างไรก็ตาม เมื่อเร็ว ๆ นี้ มีแอปพลิเคชันที่ใช้บริการบนเว็บเกิดขึ้นมากมาย รวมถึงแอปพลิเคชันสำหรับผู้ใช้ปลายทางด้วย
ในบทความนี้ เราได้กล่าวถึงเทคโนโลยียอดนิยมที่ใช้ในการสร้างเว็บแอปพลิเคชัน ได้แก่ เครื่องมือสำหรับขยายฟังก์ชันการทำงานของเบราว์เซอร์ เช่น ภาษาสคริปต์ ตัวควบคุม ActiveX แอปเพล็ต Java และแอปพลิเคชัน Macromedia Flash ตลอดจนเทคโนโลยีสำหรับการสร้างฝั่งเซิร์ฟเวอร์ เว็บแอปพลิเคชัน เช่น CGI, ISAPI, ASP, JSP, PHP, ASP .NET
ล่าสุดเนื่องมาจาก UX และประสิทธิภาพการทำงานเป็นหลัก
ฉันต้องการนำเสนอหลักการที่สามารถนำไปปฏิบัติได้ 7 ข้อสำหรับเว็บไซต์ที่ต้องการใช้ JavaScript เพื่อควบคุม UI หลักการเหล่านี้เป็นผลมาจากการทำงานของฉันในฐานะนักออกแบบเว็บไซต์ แต่ยังเป็นผู้ใช้ WWW มาเป็นเวลานานด้วย
ไม่ต้องสงสัยเลยว่า JavaScript ได้กลายเป็นเครื่องมือที่ขาดไม่ได้สำหรับนักพัฒนาส่วนหน้า ขณะนี้ขอบเขตกำลังขยายไปยังพื้นที่อื่นๆ เช่น เซิร์ฟเวอร์และไมโครคอนโทรลเลอร์ ภาษาการเขียนโปรแกรมนี้ได้รับเลือกจากมหาวิทยาลัยที่มีชื่อเสียงเพื่อสอนนักศึกษาเกี่ยวกับพื้นฐานของวิทยาการคอมพิวเตอร์
ในขณะเดียวกัน มีคำถามมากมายเกี่ยวกับบทบาทและการใช้งานเฉพาะ ซึ่งหลายคนพบว่าเป็นการยากที่จะตอบ รวมถึงผู้เขียนเฟรมเวิร์กและไลบรารีด้วย
- ควรใช้ JavaScript แทนฟังก์ชั่นเบราว์เซอร์: ประวัติ, การนำทาง, การเรนเดอร์หรือไม่
- แบ็คเอนด์กำลังจะตายเหรอ? จำเป็นต้องเรนเดอร์ HTML เลยหรือไม่?
- จริงหรือไม่ที่ Single Page Applications (SPAs) คืออนาคต?
- JS ควรสร้างเพจบนเว็บไซต์และเรนเดอร์เพจในเว็บแอปพลิเคชันหรือไม่
- ฉันควรใช้เทคนิคเช่น PJAX หรือ TurboLinks หรือไม่
- อะไรคือความแตกต่างที่แท้จริงระหว่างเว็บไซต์และเว็บแอปพลิเคชัน? ควรจะมีสิ่งหนึ่งเหลืออยู่หรือไม่?
ก่อนอื่น ฉันต้องชี้ให้เห็นข้อผิดพลาดทั่วไปของการแยก “แอปพลิเคชันที่แสดงผลบนเซิร์ฟเวอร์” ออกจาก “แอปพลิเคชันหน้าเดียว” หากเราต้องการบรรลุประสบการณ์ที่ดีที่สุดจากมุมมองของผู้ใช้ เราต้องไม่จำกัดตัวเองอยู่แค่ขีดจำกัดดังกล่าว และละทิ้งทางเลือกหนึ่งเพื่อประโยชน์ของอีกทางเลือกหนึ่ง
เหตุผลค่อนข้างชัดเจน หน้าต่างๆ ถูกส่งผ่านอินเทอร์เน็ต ซึ่งมีข้อจำกัดทางกายภาพ ดังที่ Stuart Cheshire แสดงให้เห็นอย่างน่าจดจำในบทความชื่อดังเรื่อง "It's Latency, Fool":
ระยะทางระหว่าง สแตนฟอร์ด และ บอสตัน คือ 4320 กม.ความเร็วแสงในสุญญากาศคือ 300 x 10^6 m/s
ความเร็วแสงในใยแก้วนำแสงอยู่ที่ประมาณ 66% ของความเร็วแสงในสุญญากาศ
ความเร็วแสงในใยแก้วนำแสงคือ 300 x 10^6 เมตร/วินาที * 0.66 = 200 x 10^6 เมตร/วินาที
ความล่าช้าทางเดียวเมื่อส่งสัญญาณไปยังบอสตัน 4320 กม. / 200 x 10^6 เมตร/วินาที = 21.6 มิลลิวินาที
เวลาแฝงไปกลับ 43.2 ms
Ping จาก Stanford ถึง Boston บนอินเทอร์เน็ตสมัยใหม่ใช้เวลาประมาณ 85 ms (...)
ดังนั้นอุปกรณ์อินเทอร์เน็ตสมัยใหม่จึงส่งสัญญาณด้วยความเร็ว 0.5 เท่าของความเร็วแสง
สามารถปรับปรุงผลลัพธ์ที่ระบุของ 85 ms ได้ (และดีขึ้นเล็กน้อยแล้ว) แต่สิ่งสำคัญคือต้องเข้าใจว่ามีขีดจำกัดทางกายภาพเกี่ยวกับความล่าช้าในการส่งข้อมูลผ่านอินเทอร์เน็ตไม่ว่าแบนด์วิดท์บนคอมพิวเตอร์ของผู้ใช้จะเพิ่มขึ้นเท่าใด .
นี่เป็นสิ่งสำคัญอย่างยิ่งกับความนิยมที่เพิ่มขึ้นของแอปพลิเคชัน JavaScript ซึ่งโดยทั่วไปจะมีเพียงมาร์กอัปและช่องว่างถัดจากนั้น แอปพลิเคชันหน้าเดียว (SPA) ที่เรียกว่า - เซิร์ฟเวอร์ส่งคืนหนึ่งหน้าและทุกอย่างถูกเรียกด้วยโค้ดในฝั่งไคลเอ็นต์
ลองนึกภาพสถานการณ์ที่ผู้ใช้เข้าถึง app.com/orders โดยตรง เมื่อใบสมัครของคุณได้รับและดำเนินการตามคำขอนี้ ก็ถือว่ามีความสำคัญอยู่แล้ว ข้อมูลเกี่ยวกับสิ่งที่ต้องแสดงบนหน้า ตัวอย่างเช่น สามารถโหลดคำสั่งซื้อจากฐานข้อมูลและเพิ่มลงในการตอบกลับได้ แต่สปาส่วนใหญ่ในสถานการณ์นี้ส่งคืนหน้าว่างและแท็ก จากนั้นคุณจะต้องแลกเปลี่ยนคำขออีกครั้งเพื่อรับเนื้อหาของสคริปต์ และอีกครั้งเพื่อรับเนื้อหา
แยกวิเคราะห์ HTML ที่ส่งโดยเซิร์ฟเวอร์สำหรับแต่ละหน้า SPA
นักพัฒนาหลายคนจงใจเสียสละสิ่งนี้ พวกเขาพยายามให้แน่ใจว่าเครือข่ายเพิ่มเติมนั้น กระโดดจะเกิดขึ้นเพียงครั้งเดียวสำหรับผู้ใช้ โดยส่งส่วนหัวที่ถูกต้องเพื่อแคชในการตอบกลับด้วยสคริปต์และ CSS ภูมิปัญญาดั้งเดิมก็คือ นี่เป็นข้อเสนอที่ดี เพราะเมื่อดาวน์โหลดไฟล์ทั้งหมดลงคอมพิวเตอร์แล้ว การกระทำส่วนใหญ่ของผู้ใช้ (เช่น การนำทางไปยังส่วนอื่นๆ) จะเกิดขึ้นโดยไม่ต้องใช้หน้าหรือสคริปต์เพิ่มเติม
อย่างไรก็ตามแม้จะคำนึงถึงแคชแล้ว แต่ก็ยังมีการสูญเสียประสิทธิภาพอยู่บ้างหากเราคำนึงถึงเวลาในการแยกวิเคราะห์และการดำเนินการสคริปต์ ในบทความ “jQuery ใหญ่เกินไปสำหรับมือถือหรือเปล่า” ระบุว่า jQuery เพียงอย่างเดียวสามารถทำให้เบราว์เซอร์มือถือบางตัวช้าลงหลายร้อยมิลลิวินาทีได้อย่างไร
ที่แย่กว่านั้นคือผู้ใช้มักจะไม่ได้รับข้อเสนอแนะใด ๆ ในขณะที่สคริปต์กำลังโหลด ผลลัพธ์คือหน้าว่างบนหน้าจอ ซึ่งจู่ๆ ก็กลายเป็นหน้าที่โหลดเต็ม
สิ่งสำคัญที่สุดคือ เรามักจะลืมไปว่าการขนส่งข้อมูลทางอินเทอร์เน็ต (TCP) ที่พบบ่อยที่สุดเริ่มต้นได้ช้า สิ่งนี้เกือบจะรับประกันได้ว่าชุดสคริปต์ส่วนใหญ่จะไม่ถูกถ่ายโอนในครั้งเดียว ทำให้สถานการณ์ข้างต้นแย่ลงไปอีก
การเชื่อมต่อ TCP เริ่มต้นด้วยการแลกเปลี่ยนแพ็คเก็ตการจับมือกัน หากคุณใช้ SSL ซึ่งเป็นสิ่งสำคัญสำหรับการถ่ายโอนสคริปต์ที่ปลอดภัย จะมีการแลกเปลี่ยนแพ็กเก็ตเพิ่มเติมสองรายการ (หนึ่งรายการหากไคลเอ็นต์กู้คืนเซสชัน) หลังจากนี้เซิร์ฟเวอร์จะสามารถเริ่มส่งข้อมูลได้ แต่ในทางปฏิบัติแสดงให้เห็นว่าเซิร์ฟเวอร์ดำเนินการช้าและเป็นชุด
กลไกการควบคุมความแออัดที่เรียกว่า Slow Start ถูกสร้างขึ้นในโปรโตคอล TCP เพื่อส่งข้อมูลเพิ่มขึ้น เซ็กเมนต์- สิ่งนี้มีผลกระทบร้ายแรงสองประการสำหรับ SPA:
1. สคริปต์ขนาดใหญ่ใช้เวลาโหลดนานกว่าที่เห็นมาก ตามที่อธิบายไว้ในหนังสือ "High Performance Browser Networking" โดย Ilya Grigorik ต้องใช้ "การแลกเปลี่ยนแพ็กเก็ตสี่ครั้ง (...) และเวลาในการตอบสนองหลายร้อยมิลลิวินาทีเพื่อเข้าถึงการแลกเปลี่ยนข้อมูล 64 KB ระหว่างไคลเอนต์และเซิร์ฟเวอร์" ตัวอย่างเช่น ในกรณีของการเชื่อมต่ออินเทอร์เน็ตที่รวดเร็วระหว่างลอนดอนและนิวยอร์ก จะใช้เวลา 225 มิลลิวินาที ก่อนที่ TCP จะเข้าถึงขนาดแพ็กเก็ตสูงสุดได้
2. เนื่องจากกฎนี้ยังใช้กับการโหลดหน้าเริ่มต้นด้วย จึงเป็นสิ่งสำคัญมากว่าเนื้อหาใดจะถูกโหลดมาแสดงผลบนหน้าก่อน ตามที่ Paul Irish สรุปในการนำเสนอของเขาเรื่อง Delivering Goods 14 KB แรกถือเป็นเรื่องสำคัญ สิ่งนี้ชัดเจนหากคุณดูกราฟที่ระบุปริมาณการถ่ายโอนระหว่างไคลเอนต์และเซิร์ฟเวอร์ในระหว่างขั้นตอนแรกของการสร้างการเชื่อมต่อ
เซิร์ฟเวอร์สามารถส่งได้กี่ KB ในแต่ละขั้นตอนการเชื่อมต่อ ตามเซ็กเมนต์
เว็บไซต์ที่จัดการเพื่อส่งเนื้อหา (แม้แต่มาร์กอัปพื้นฐานที่ไม่มีข้อมูล) ในหน้าต่างนี้จะปรากฏตอบสนองเป็นพิเศษ ในความเป็นจริง ผู้เขียนแอปพลิเคชันฝั่งเซิร์ฟเวอร์ที่รวดเร็วหลายคนมองว่า JavaScript เป็นสิ่งที่ไม่จำเป็นหรือเป็นสิ่งที่ควรใช้ด้วยความระมัดระวังอย่างยิ่ง ทัศนคตินี้จะแข็งแกร่งยิ่งขึ้นหากแอปพลิเคชันมีแบ็กเอนด์และฐานข้อมูลที่รวดเร็ว และเซิร์ฟเวอร์ตั้งอยู่ใกล้กับผู้ใช้ (CDN)
บทบาทของเซิร์ฟเวอร์ในการเร่งการนำเสนอเนื้อหาขึ้นอยู่กับเว็บแอปพลิเคชันโดยตรง วิธีแก้ปัญหาไม่ได้จำกัดอยู่ที่ "แสดงผลทั้งหน้าบนเซิร์ฟเวอร์" เสมอไป
ในบางกรณี เป็นการดีกว่าที่จะแยกส่วนของเพจที่ไม่เกี่ยวข้องกับผู้ใช้ในปัจจุบันออกจากการตอบกลับครั้งแรกและทิ้งไว้ในภายหลัง ตัวอย่างเช่น แอปพลิเคชันบางตัวต้องการแสดงผลเฉพาะ "แกนกลาง" ของเพจเพื่อให้แน่ใจว่าจะตอบสนองได้ในทันที จากนั้นพวกเขาจะขอส่วนต่างๆ ของหน้าพร้อมกัน สิ่งนี้ให้การตอบสนองที่ดีกว่าแม้ในสถานการณ์ที่แบ็กเอนด์แบบเดิมช้า สำหรับบางเพจ การแสดงเฉพาะส่วนที่มองเห็นได้ของเพจอาจเป็นตัวเลือกที่ดี
สำคัญมาก ๆ การประเมินเชิงคุณภาพสคริปต์และสไตล์ โดยคำนึงถึงข้อมูลที่เซิร์ฟเวอร์มีเกี่ยวกับเซสชัน ไคลเอนต์ และ URL สคริปต์ที่เรียงลำดับจะมีความสำคัญต่อ /orders มากกว่าตรรกะของหน้าการตั้งค่าอย่างเห็นได้ชัด อาจไม่ชัดเจนนัก แต่มีความแตกต่างในการโหลด “โครงสร้าง CSS” และ “สไตล์ CSS” อันแรกอาจจำเป็นสำหรับโค้ด JavaScript ดังนั้นจึงจำเป็น การปิดกั้นและอันที่สองถูกโหลดแบบอะซิงโครนัส
ตัวอย่างที่ดีของ SPA ที่ไม่ส่งผลให้เกิดการแลกเปลี่ยนแพ็กเก็ตที่ไม่จำเป็นคือโคลนแนวคิด StackOverflow ขนาด 4096 ไบต์ ซึ่งในทางทฤษฎีสามารถโหลดด้วยแพ็กเก็ตแรกหลังจากการจับมือกันในการเชื่อมต่อ TCP! ผู้เขียนจัดการเพื่อให้บรรลุเป้าหมายนี้โดยการปฏิเสธการแคช โดยใช้อินไลน์สำหรับทรัพยากรทั้งหมดในการตอบสนองจากเซิร์ฟเวอร์ โดยการใช้การพุชเซิร์ฟเวอร์ SPDY หรือ HTTP/2 เป็นไปได้ในทางทฤษฎีในการถ่ายโอนรหัสไคลเอ็นต์ที่แคชไว้ทั้งหมดในการกระโดดครั้งเดียว ในปัจจุบัน การเรนเดอร์บางส่วนหรือทั้งหน้าบนฝั่งเซิร์ฟเวอร์ยังคงเป็นวิธีที่ได้รับความนิยมมากที่สุดในการกำจัดการแลกเปลี่ยนแพ็กเก็ตที่ไม่จำเป็น
SPA แบบพิสูจน์แนวคิดโดยใช้อินไลน์สำหรับ CSS และ JS เพื่อกำจัดการไปกลับที่ไม่จำเป็น
ระบบที่ค่อนข้างยืดหยุ่นซึ่งแยกการเรนเดอร์ระหว่างเบราว์เซอร์และเซิร์ฟเวอร์ และจัดเตรียมเครื่องมือสำหรับการโหลดสคริปต์และสไตล์แบบค่อยเป็นค่อยไปอาจทำให้เส้นแบ่งระหว่าง เว็บไซต์และ แอปพลิเคชันเว็บ- ทั้งใช้ URL การนำทาง และแสดงข้อมูลแก่ผู้ใช้ แม้แต่แอปพลิเคชันสเปรดชีตที่แต่เดิมต้องใช้ฟังก์ชันฝั่งไคลเอ็นต์ก็ต้องแสดงข้อมูลที่จำเป็นต้องแก้ไขแก่ลูกค้าก่อน และการทำเช่นนี้ในจำนวนเที่ยวไปกลับน้อยที่สุดก็มีความสำคัญอย่างยิ่ง
ในความคิดของฉัน ข้อเสียด้านประสิทธิภาพที่ใหญ่ที่สุดในระบบยอดนิยมหลายๆ ระบบในปัจจุบันมาจากการสะสมความซับซ้อนในสแต็กที่ก้าวหน้า เมื่อเวลาผ่านไป เทคโนโลยีอย่าง JavaScript และ CSS ได้ถูกเพิ่มเข้ามา ความนิยมของพวกเขาก็ค่อยๆเพิ่มขึ้นเช่นกัน ตอนนี้เท่านั้นที่เราจะซาบซึ้งว่าสามารถใช้แตกต่างกันได้อย่างไร เรากำลังพูดถึงการปรับปรุงโปรโตคอลด้วย (ซึ่งแสดงโดยความคืบหน้าในปัจจุบันของ SPDY และ QUIC) แต่ประโยชน์สูงสุดมาจากการเพิ่มประสิทธิภาพแอปพลิเคชัน
อาจเป็นประโยชน์ในการระลึกถึงการอภิปรายทางประวัติศาสตร์บางส่วนเกี่ยวกับการออกแบบ HTML ยุคแรกและ WWW ตัวอย่างเช่น รายชื่ออีเมลนี้ตั้งแต่ปี 1997 แนะนำให้เพิ่มแท็ก ในรูปแบบ HTML Marc Andreessen ย้ำถึงความสำคัญของการส่งข้อมูลอย่างรวดเร็ว:
เป้าหมายของเราคือเพิ่มความเร็วในการตอบสนองต่อการกระทำของผู้ใช้ให้สูงสุด ไม่ว่าเราจะใช้ความพยายามมากเพียงใดในการลดจำนวนการกระโดดเมื่อทำงานกับเว็บแอปพลิเคชัน ยังมีสิ่งต่าง ๆ ที่อยู่นอกเหนือการควบคุมของเรา นี่เป็นขีดจำกัดทางทฤษฎีของความเร็วแสงและค่า ping ขั้นต่ำระหว่างไคลเอนต์และเซิร์ฟเวอร์
ปัจจัยสำคัญคือคุณภาพการสื่อสารที่ไม่สามารถคาดเดาได้ระหว่างไคลเอนต์และเซิร์ฟเวอร์ หากคุณภาพการเชื่อมต่อไม่ดี แพ็กเก็ตจะถูกส่งอีกครั้ง ในกรณีที่ต้องโหลดเนื้อหาแบบไปกลับ 2-3 ครั้ง คุณอาจต้องโหลดมากกว่านี้มาก
นี่คือประโยชน์หลักของ JavaScript สำหรับการปรับปรุง UX หากอินเทอร์เฟซถูกเขียนสคริปต์บนฝั่งไคลเอ็นต์ เราสามารถซ่อนเวลาแฝงของเครือข่ายได้ เราสามารถสร้างความประทับใจในความเร็วสูงได้ เราสามารถบรรลุเวลาแฝงเป็นศูนย์ได้โดยไม่ได้ตั้งใจ
สมมติว่านี่เป็น HTML ธรรมดา เอกสารเชื่อมต่อกันด้วยไฮเปอร์ลิงก์หรือแท็ก - หากคุณคลิกที่รายการใดรายการหนึ่ง เบราว์เซอร์จะส่งคำขอเครือข่ายซึ่งใช้เวลานานอย่างไม่อาจคาดเดาได้ จากนั้นรับและประมวลผลข้อมูลที่ได้รับและเข้าสู่สถานะใหม่ในที่สุด
JavaScript ช่วยให้คุณตอบสนองต่อการกระทำของผู้ใช้ได้ทันทีและในแง่ดี การคลิกลิงก์หรือปุ่มจะทำให้ได้รับการตอบสนองทันทีโดยไม่ต้องต่ออินเทอร์เน็ต ตัวอย่างที่รู้จักกันดีคืออินเทอร์เฟซ Gmail (หรือ Google Inbox) ซึ่งการเก็บถาวรข้อความอีเมลจะเกิดขึ้นทันที ในขณะที่คำขอที่เกี่ยวข้องไปยังเซิร์ฟเวอร์จะถูกส่งและประมวลผลแบบอะซิงโครนัส
ในกรณีของแบบฟอร์ม แทนที่จะรอโค้ด HTML เพื่อตอบกลับการกรอก เราสามารถตอบกลับได้ทันทีที่ผู้ใช้กด “Enter” หรือดียิ่งขึ้น เช่นเดียวกับการค้นหาของ Google เราสามารถตอบสนองได้เร็วยิ่งขึ้นด้วยการเตรียมมาร์กอัปสำหรับหน้าใหม่ล่วงหน้า
พฤติกรรมนี้เป็นตัวอย่างของสิ่งที่ฉันเรียกว่า การปรับมาร์กอัป- แนวคิดพื้นฐานคือหน้าเว็บ "รู้" มาร์กอัปในอนาคต ดังนั้นจึงสามารถเปลี่ยนไปใช้หน้าดังกล่าวได้เมื่อยังไม่มีข้อมูลที่จะระบุ นี่เป็นพฤติกรรม "ในแง่ดี" เนื่องจากยังคงมีความเสี่ยงที่ข้อมูลจะไม่มาถึงและจะต้องรายงานข้อความแสดงข้อผิดพลาด แต่สิ่งนี้เกิดขึ้นได้ยากอย่างเห็นได้ชัด
หน้าแรกของ Google เป็นตัวอย่างที่ดีเพราะแสดงให้เห็นหลักการสองข้อแรกจากบทความของเราอย่างชัดเจน
ในช่วงปลายปี พ.ศ. 2547 Google เป็นผู้บุกเบิกการใช้ JavaScript เพื่อให้คำแนะนำแบบเรียลไทม์ขณะพิมพ์คำค้นหา (ที่น่าสนใจคือ คุณลักษณะนี้ได้รับการพัฒนาโดยพนักงานในเวลาว่าง 20% เช่นเดียวกับ Gmail) สิ่งนี้กลายเป็นพื้นฐานสำหรับการเกิดขึ้นของ Ajax:
ดูที่ Google แนะนำ ดูข้อความค้นหาอัปเดตขณะที่คุณพิมพ์เกือบจะในทันที... โดยไม่ทำให้การโหลดหน้าซ้ำล่าช้า Google Suggest และ Google Maps เป็นสองตัวอย่างของแนวทางใหม่ในการสร้างเว็บแอปพลิเคชันที่เรา Adaptive Path เรียกว่า "Ajax"และในปี 2010 พวกเขาได้เปิดตัวการค้นหาทันใจ ซึ่ง JS มีบทบาทสำคัญ โดยยกเลิกการรีเฟรชหน้าด้วยตนเองโดยสิ้นเชิง และสลับไปใช้มาร์กอัป "ผลการค้นหา" ในการกดแป้นพิมพ์ครั้งแรก ดังที่เห็นในภาพประกอบด้านบน
อีกตัวอย่างที่โดดเด่นของการปรับมาร์กอัปอาจอยู่ในกระเป๋าของคุณ ตั้งแต่วันแรกๆ iPhone OS กำหนดให้ผู้เขียนแอปพลิเคชันต้องจัดเตรียมรูปภาพ ค่าเริ่มต้น.pngซึ่งสามารถแสดงบนหน้าจอได้ทันทีขณะที่แอปพลิเคชันกำลังโหลดอยู่
iPhone OS บังคับให้โหลด default.png ก่อนเปิดแอป
การดำเนินการอีกประเภทหนึ่งนอกเหนือจากการคลิกและการส่งแบบฟอร์มที่ได้รับการปรับปรุงอย่างมากด้วย JavaScript คือการแสดงการอัปโหลดไฟล์
เราสามารถบันทึกความพยายามของผู้ใช้ในการดาวน์โหลดไฟล์ได้หลายวิธี: ลากและวาง วางจากบัฟเฟอร์ การเลือกไฟล์ จากนั้น ต้องขอบคุณ HTML5 API ใหม่ที่ทำให้เราสามารถแสดงเนื้อหาราวกับว่ามันถูกดาวน์โหลดไปแล้ว ตัวอย่างของอินเทอร์เฟซประเภทนี้คืองานของเรากับการดาวน์โหลดใน Cloudup สังเกตว่าภาพขนาดย่อของรูปภาพถูกสร้างขึ้นและแสดงผลอย่างไรในทันที:
รูปภาพจะถูกเรนเดอร์และแสดงจนกว่าการโหลดจะเสร็จสิ้น
ในทุกกรณีเหล่านี้เราปรับปรุง การรับรู้ความเร็ว- โชคดีที่มีหลักฐานมากมายที่แสดงถึงประโยชน์ของแนวทางนี้ อย่างน้อยก็ยกตัวอย่างวิธีการ เพิ่มขึ้นระยะทางถึงสายพานลำเลียงสัมภาระที่สนามบินฮูสตัน ลดลงจำนวนข้อร้องเรียนเกี่ยวกับกระเป๋าเดินทางสูญหายโดยไม่จำเป็นต้องเร่งดำเนินการเกี่ยวกับสัมภาระ
แนวคิดนี้ควรส่งผลกระทบอย่างจริงจังต่อ UI ของแอปพลิเคชันของเรา ฉันเชื่อว่าตัวบ่งชี้การโหลดควรกลายเป็นสิ่งหายาก โดยเฉพาะอย่างยิ่งเมื่อเราเปลี่ยนไปใช้แอปพลิเคชันข้อมูลแบบเรียลไทม์ ซึ่งจะอธิบายไว้ในส่วนถัดไป
มีบางสถานการณ์ที่ภาพลวงตาของการกระทำในทันทีส่งผลเสียต่อ UX นี่อาจเป็นรูปแบบการชำระเงินหรือสิ้นสุดเซสชันบนเว็บไซต์ ด้วยการใช้แนวทางในแง่ดีที่นี่ ซึ่งหลอกลวงผู้ใช้โดยพฤตินัย เราอาจเสี่ยงต่อการทำให้เขาหงุดหงิด
แต่ถึงแม้ในกรณีเหล่านี้ การแสดงตัวหมุนหรือตัวแสดงการโหลดบนหน้าจอก็ควรหยุดลง ควรแสดงเฉพาะหลังจากที่ผู้ใช้พิจารณาว่าการตอบกลับไม่ได้เกิดขึ้นทันที จากการศึกษาของ Nielsen ที่อ้างถึงบ่อยครั้ง:
คำแนะนำเวลาตอบสนองขั้นพื้นฐานยังคงเหมือนเดิมเป็นเวลาสามสิบปี มิลเลอร์ 2511; การ์ดและคณะ 1991:*0.1 วินาทีคือขีดจำกัดสำหรับผู้ใช้ในการรับรู้การตอบสนองทันที ไม่จำเป็นต้องแสดงข้อมูลเพิ่มเติมใดๆ นอกเหนือจากผลลัพธ์ของการดำเนินการ
* 1.0 วินาทีคือขีดจำกัดความต่อเนื่องของความคิดของผู้ใช้ แม้ว่าเขาจะสังเกตเห็นความล่าช้าก็ตาม โดยทั่วไปแล้ว ไม่จำเป็นต้องมีตัวบ่งชี้เพิ่มเติมสำหรับความล่าช้าที่มากกว่า 0.1 วินาที แต่น้อยกว่า 1.0 วินาที แต่ผู้ใช้จะสูญเสียความรู้สึกในการทำงานกับข้อมูลโดยตรง
* 10 วินาทีคือขีดจำกัดในการรักษาความสนใจของผู้ใช้ต่อบทสนทนา ด้วยเวลาแฝงที่สูงขึ้น ผู้ใช้จะต้องการทำงานอื่นในขณะที่รอการตอบกลับจากคอมพิวเตอร์
น่าเสียดายที่เทคนิคเช่น PJAX หรือ TurboLinks พลาดคุณสมบัติส่วนใหญ่ที่อธิบายไว้ในส่วนนี้ รหัสฝั่งไคลเอ็นต์ไม่ "รู้" เกี่ยวกับสถานะในอนาคตของเพจจนกว่าการแลกเปลี่ยนข้อมูลกับเซิร์ฟเวอร์จะเกิดขึ้น3. การตอบสนองต่อการเปลี่ยนแปลงข้อมูล DR: เมื่อมีการอัพเดตข้อมูลบนเซิร์ฟเวอร์ ลูกค้าควรได้รับแจ้งโดยไม่ชักช้า นี่เป็นรูปแบบหนึ่งของการปรับปรุงประสิทธิภาพการทำงานเมื่อผู้ใช้ไม่ต้องดำเนินการเพิ่มเติม (กด F5 รีเฟรชหน้า) ปัญหาใหม่: การจัดการการเชื่อมต่อ (อีกครั้ง) การกู้คืนสถานะ
หลักการที่สามเกี่ยวข้องกับการตอบสนองของ UI ต่อการเปลี่ยนแปลงข้อมูลที่ต้นทาง ซึ่งโดยทั่วไปคือเซิร์ฟเวอร์ฐานข้อมูลตั้งแต่หนึ่งเครื่องขึ้นไป
ไปแล้วคือรูปแบบการส่งข้อมูล HTML ที่คงที่จนกว่าผู้ใช้จะรีเฟรชหน้า (เว็บไซต์แบบเดิม) หรือโต้ตอบกับมัน (Ajax)
UI ของคุณควรอัปเดตโดยอัตโนมัติ
นี่เป็นสิ่งสำคัญในโลกที่มีข้อมูลไหลเข้ามามากขึ้นจากแหล่งต่างๆ รวมถึงนาฬิกา โทรศัพท์ แท็บเล็ต และอุปกรณ์สวมใส่ที่จะปรากฏในอนาคต
ลองนึกภาพฟีดข่าวของ Facebook ทันทีหลังจากเปิดตัว ซึ่งข้อมูลส่วนใหญ่เผยแพร่จากคอมพิวเตอร์ส่วนบุคคลของผู้ใช้ การเรนเดอร์แบบคงที่นั้นไม่เหมาะสมที่สุด แต่ก็เหมาะสมสำหรับผู้ที่รีเฟรชฟีดของตน เช่น วันละครั้ง
ตอนนี้เราอยู่ในโลกที่คุณอัปโหลดรูปภาพและได้รับไลค์และความคิดเห็นจากเพื่อนและคนรู้จักเกือบจะในทันที ความจำเป็นในการตอบสนองทันทีกลายเป็นสิ่งจำเป็นตามธรรมชาติในสภาพแวดล้อมการแข่งขันของแอปพลิเคชันอื่นๆ
อย่างไรก็ตาม การสันนิษฐานว่าประโยชน์ของการอัปเดต UI แบบทันทีนั้นจำกัดอยู่เพียงแอปพลิเคชันที่มีผู้ใช้หลายรายอาจถือเป็นเรื่องผิด นั่นเป็นเหตุผลที่ฉันชอบพูดถึง จุดข้อมูลที่ตกลงกัน, แทน ผู้ใช้- ลองใช้สถานการณ์ทั่วไปในการซิงโครไนซ์รูปภาพระหว่างโทรศัพท์กับแล็ปท็อปของคุณเอง:
แอปพลิเคชันแบบผู้ใช้คนเดียวยังสามารถได้รับประโยชน์จากปฏิกิริยาอีกด้วย
มีประโยชน์ในการจินตนาการ ทั้งหมดข้อมูลที่ส่งถึงผู้ใช้ในรูปแบบ "โต้ตอบ" การซิงโครไนซ์เซสชันและสถานะการอนุญาตเป็นตัวอย่างหนึ่งของแนวทางสากล หากผู้ใช้แอปพลิเคชันของคุณเปิดหลายแท็บพร้อมกัน การสิ้นสุดเซสชันการทำงานในแท็บใดแท็บหนึ่งควรปิดใช้งานการให้สิทธิ์ในแท็บอื่นๆ ทั้งหมดทันที สิ่งนี้นำไปสู่การรักษาความปลอดภัยที่ดีขึ้นและการปกป้องข้อมูลที่เป็นความลับที่ดีขึ้นอย่างหลีกเลี่ยงไม่ได้ โดยเฉพาะอย่างยิ่งในสถานการณ์ที่มีคนหลายคนสามารถเข้าถึงอุปกรณ์เดียวกัน
แต่ละหน้าตอบสนองต่อสถานะเซสชันและสถานะการอนุญาต
เมื่อคุณกำหนดกฎว่าข้อมูลบนหน้าจอจะได้รับการอัปเดตโดยอัตโนมัติ สิ่งสำคัญคือต้องทำงานใหม่: การกู้คืนสถานะ
เมื่อส่งคำขอและรับการอัปเดตปรมาณู เป็นเรื่องง่ายที่จะลืมว่าแอปพลิเคชันของคุณควรอัปเดตตามปกติแม้ว่าจะไม่มีการใช้งานเป็นเวลานานก็ตาม ลองนึกภาพการปิดฝาแล็ปท็อปของคุณแล้วเปิดขึ้นมาในอีกไม่กี่วันต่อมา แอปพลิเคชันจะทำงานอย่างไร
ตัวอย่างสิ่งที่เกิดขึ้นหากการเชื่อมต่อไม่ได้รับการอัพเดตอย่างถูกต้อง
ความสามารถของแอปพลิเคชันในการเชื่อมต่อใหม่ตามปกติจะโต้ตอบกับหลักการ #1 หากคุณเลือกที่จะส่งข้อมูลในการโหลดหน้าแรก คุณต้องคำนึงถึงเวลาที่ผ่านไปก่อนที่จะโหลดสคริปต์ด้วย เวลานี้เทียบเท่ากับเวลาตัดการเชื่อมต่อ ดังนั้นการเชื่อมต่อเริ่มต้นของสคริปต์ของคุณจึงเป็นการเริ่มต้นเซสชันใหม่
4. การควบคุมการแลกเปลี่ยนข้อมูลกับเซิร์ฟเวอร์ tl;DR: ตอนนี้เราสามารถปรับแต่งการแลกเปลี่ยนข้อมูลกับเซิร์ฟเวอร์ได้แล้ว ตรวจสอบให้แน่ใจว่าได้จัดการกับข้อผิดพลาด ลองส่งคำขอไปยังไคลเอ็นต์อีกครั้ง ซิงค์ข้อมูลในเบื้องหลัง และเก็บแคชไว้แบบออฟไลน์เมื่อเว็บเกิดขึ้น การสื่อสารระหว่างไคลเอนต์และเซิร์ฟเวอร์ถูกจำกัดด้วยหลายวิธี:
ข้อจำกัดหลักเกี่ยวข้องกับประเด็นที่สอง การไม่สามารถส่งข้อมูลโดยไม่จำเป็นต้องโหลดหน้าใหม่ถือเป็นข้อเสียจากมุมมองของประสิทธิภาพ แต่สิ่งที่สำคัญที่สุดคือทำให้ปุ่ม "ย้อนกลับ" พังโดยสิ้นเชิง:
อาจเป็นสิ่งประดิษฐ์ที่น่ารำคาญที่สุดของเว็บเก่า
นี่คือสาเหตุที่เว็บในฐานะแพลตฟอร์มแอปพลิเคชันยังคงไม่สมบูรณ์หากไม่มี JavaScript Ajax เป็นการก้าวกระโดดครั้งใหญ่ในแง่ของความง่ายในการเผยแพร่โดยผู้ใช้
ขณะนี้เรามี API จำนวนมาก (XMLHttpRequest, WebSocket, EventSource และอื่นๆ อีกมากมาย) ที่ให้การควบคุมการไหลของข้อมูลอย่างสมบูรณ์และแม่นยำ นอกจากความสามารถในการเผยแพร่ข้อมูลผู้ใช้ผ่านแบบฟอร์มแล้ว เรายังมีโอกาสใหม่ในการปรับปรุง UX
ที่เกี่ยวข้องโดยตรงกับหลักการก่อนหน้านี้คือการแสดงผล สถานะการเชื่อมต่อ- หากเราคาดหวังว่าข้อมูลจะได้รับการอัปเดตโดยอัตโนมัติ เราต้องแจ้งให้ผู้ใช้ทราบข้อเท็จจริง สูญเสียการเชื่อมต่อและ พยายามที่จะคืนค่ามัน.
เมื่อตรวจพบการตัดการเชื่อมต่อ จะมีประโยชน์ในการจัดเก็บข้อมูลในหน่วยความจำ (หรือดีกว่านั้นใน localStorage) เพื่อให้สามารถส่งได้ในภายหลัง นี่เป็นสิ่งสำคัญอย่างยิ่งในแง่ของการใช้งาน ServiceWorker ในอนาคต ซึ่งช่วยให้แอปพลิเคชัน JavaScript ทำงานได้ ในพื้นหลัง- หากแอปพลิเคชันของคุณไม่เปิด คุณยังคงสามารถลองซิงค์ข้อมูลกับเซิร์ฟเวอร์ในเบื้องหลังต่อไปได้
พิจารณาความเป็นไปได้ของการหมดเวลาและข้อผิดพลาดเมื่อส่งข้อมูล สถานการณ์ดังกล่าวควรได้รับการแก้ไขเพื่อประโยชน์ของลูกค้า หากการเชื่อมต่อกลับคืนมา ให้ลองส่งข้อมูลอีกครั้ง ในกรณีที่มีข้อผิดพลาดถาวร โปรดแจ้งให้ผู้ใช้ทราบ
ข้อผิดพลาดบางอย่างจำเป็นต้องได้รับการจัดการอย่างระมัดระวังเป็นพิเศษ ตัวอย่างเช่น 403 ที่ไม่คาดคิดอาจหมายความว่าเซสชันของผู้ใช้ไม่ถูกต้อง ในกรณีเช่นนี้ คุณสามารถกู้คืนเซสชันได้โดยแสดงหน้าต่างให้ผู้ใช้เข้าสู่ระบบและรหัสผ่าน
สิ่งสำคัญคือต้องแน่ใจว่าผู้ใช้จะไม่ขัดจังหวะการไหลของข้อมูลโดยไม่ได้ตั้งใจ สิ่งนี้สามารถเกิดขึ้นได้ในสองสถานการณ์ กรณีแรกและชัดเจนที่สุดคือการปิดเบราว์เซอร์หรือแท็บ ซึ่งเป็นสิ่งที่เราพยายามป้องกันด้วยตัวจัดการก่อนยกเลิกการโหลด
คำเตือนก่อนยกเลิกการโหลด
อีกกรณีหนึ่ง (และชัดเจนน้อยกว่า) คือเมื่อคุณพยายามนำทางไปยังหน้าอื่น เช่น การคลิกลิงก์ ในกรณีนี้ แอปพลิเคชันสามารถหยุดผู้ใช้โดยใช้วิธีอื่นได้ ขึ้นอยู่กับดุลยพินิจของผู้พัฒนา
5. อย่าทำลายประวัติศาสตร์ ปรับปรุงมัน tl; DR: หากเบราว์เซอร์ไม่จัดการ URL และประวัติ เราจะประสบปัญหาใหม่ ตรวจสอบให้แน่ใจว่าคุณมีคุณสมบัติตรงตามลักษณะการเลื่อนที่คาดไว้ บันทึกแคชของคุณเองเพื่อรับข้อเสนอแนะอย่างรวดเร็วไม่ต้องส่งแบบฟอร์ม การใช้เพียงไฮเปอร์ลิงก์ในเว็บแอปพลิเคชันจะทำให้เรานำทางไปข้างหน้า/ย้อนกลับได้อย่างสมบูรณ์ในเบราว์เซอร์
ตัวอย่างเช่น เพจ "ไม่มีที่สิ้นสุด" ทั่วไปมักจะสร้างด้วยปุ่ม JavaScript ที่ขอข้อมูลเพิ่มเติม/HTML แล้วแทรกเข้าไป น่าเสียดายที่มีเพียงไม่กี่คนที่จำการโทร history.pushState หรือ replacementState เป็นขั้นตอนที่จำเป็น
เพราะเหตุนี้ผมจึงใช้คำว่า "แตก" ด้วยรูปแบบที่เรียบง่ายของเว็บดั้งเดิม สถานการณ์นี้จึงเป็นไปไม่ได้ การเปลี่ยนแปลงแต่ละสถานะขึ้นอยู่กับการเปลี่ยนแปลง URL
แต่ยังมีอีกด้านหนึ่งของเหรียญ นั่นก็คือโอกาส ทำให้ดีขึ้นประวัติการท่องเว็บ ซึ่งตอนนี้เราควบคุมโดยใช้ JavaScript
ความเป็นไปได้อย่างหนึ่งที่เรียกว่า Fast Back โดย Daniel Pipius:
ปุ่มย้อนกลับควรทำงานได้อย่างรวดเร็ว ผู้ใช้ไม่คาดหวังการเปลี่ยนแปลงข้อมูลมากเกินไปมันเหมือนกับการใช้ปุ่มย้อนกลับเหมือนปุ่มจากเว็บแอปพลิเคชันและใช้หลักการ #2 กับมัน: ตอบสนองต่อการกระทำของผู้ใช้ทันที- สิ่งสำคัญคือคุณมีโอกาสที่จะตัดสินใจว่าจะแคชหน้าก่อนหน้าอย่างไรและแสดงบนหน้าจอทันที จากนั้นคุณสามารถใช้หลักการ #3 แล้วแจ้งให้ผู้ใช้ทราบเมื่อมีข้อมูลใหม่มาถึงหน้านั้น
ยังคงมีบางสถานการณ์ที่คุณไม่สามารถควบคุมการทำงานของแคชได้ ตัวอย่างเช่น หากคุณแสดงผลเพจ จากนั้นไปที่ไซต์บุคคลที่สาม จากนั้นผู้ใช้คลิก "ย้อนกลับ" แอปพลิเคชันที่แสดง HTML บนฝั่งเซิร์ฟเวอร์แล้วแก้ไขบนฝั่งไคลเอ็นต์จะไวต่อจุดบกพร่องเล็กๆ น้อยๆ นี้เป็นพิเศษ:
การทำงานของปุ่ม "ย้อนกลับ" ไม่ถูกต้อง
อีกวิธีหนึ่งในการทำลายการนำทางคือการละเว้นหน่วยความจำสถานะการเลื่อน เป็นอีกครั้งที่เพจที่ไม่ใช้ JS และการจัดการประวัติด้วยตนเองน่าจะไม่มีปัญหาที่นี่ แต่จะมีเพจแบบไดนามิก ฉันทดสอบฟีดข่าวที่ใช้ JavaScript ที่ได้รับความนิยมมากที่สุดสองรายการบนอินเทอร์เน็ต: Twitter และ Facebook ทั้งสองมีความจำเสื่อมแบบเลื่อน
การเปลี่ยนหน้าอย่างไม่สิ้นสุดมักเป็นสัญญาณของความจำเสื่อมในการเลื่อน
ท้ายที่สุด ควรระวังการเปลี่ยนแปลงสถานะที่เกี่ยวข้องเมื่อดูประวัติเท่านั้น ตัวอย่างเช่น กรณีนี้ด้วยการเปลี่ยนสถานะของแผนผังย่อยพร้อมความคิดเห็น
การเปลี่ยนประเภทความคิดเห็นจะต้องบันทึกไว้ในประวัติ
หากเพจถูกแสดงผลอีกครั้งหลังจากคลิกลิงก์ภายในแอปพลิเคชัน ผู้ใช้อาจคาดหวังให้ขยายความคิดเห็นทั้งหมด เมื่อสถานะเปลี่ยนแปลงก็ต้องบันทึกไว้ในประวัติ
6. การอัปเดตโค้ดผ่านข้อความพุช DR: การส่งข้อมูลผ่านข้อความพุชเพียงอย่างเดียวนั้นไม่เพียงพอ คุณต้องใช้รหัสด้วย หลีกเลี่ยงข้อผิดพลาด API และปรับปรุงประสิทธิภาพ ใช้ DOM ไร้สถานะเพื่อออกแบบแอปพลิเคชันของคุณใหม่โดยไม่ลำบากเป็นสิ่งสำคัญอย่างยิ่งที่แอปพลิเคชันของคุณตอบสนองต่อการเปลี่ยนแปลงในโค้ด
ประการแรก จะช่วยลดจำนวนข้อผิดพลาดที่อาจเกิดขึ้นและเพิ่มความน่าเชื่อถือ หากคุณได้ทำการเปลี่ยนแปลงที่สำคัญกับ API แบ็กเอนด์ ต้องอัพเดตโค้ดของโปรแกรมไคลเอนต์ มิฉะนั้นลูกค้าอาจไม่ยอมรับข้อมูลใหม่หรืออาจส่งข้อมูลในรูปแบบที่เข้ากันไม่ได้
เหตุผลที่สำคัญไม่แพ้กันคือการปฏิบัติตามหลักการข้อที่ 3 หากอินเทอร์เฟซของคุณอัปเดตตัวเอง ก็ไม่มีเหตุผลเพียงเล็กน้อยที่ผู้ใช้จะต้องโหลดหน้าเว็บซ้ำด้วยตนเอง
โปรดทราบว่าสำหรับไซต์ทั่วไป การรีเฟรชหน้าเว็บจะทริกเกอร์สองสิ่ง: การโหลดข้อมูลซ้ำและการโหลดโค้ดซ้ำ การจัดการระบบด้วยการอัปเดตข้อมูลแบบพุชโดยไม่ต้องอัปเดตรหัสแบบพุชนั้นไม่สมบูรณ์ โดยเฉพาะอย่างยิ่งในโลกที่แท็บเดียว (เซสชัน) สามารถเปิดอยู่ได้เป็นเวลานานมาก
หากช่องทางการพุชของเซิร์ฟเวอร์ใช้งานได้ ผู้ใช้จะได้รับแจ้งเกี่ยวกับความพร้อมใช้งานของรหัสใหม่ ถ้าไม่เช่นนั้น คุณสามารถเพิ่มหมายเลขเวอร์ชันลงในส่วนหัวของคำขอ HTTP ขาออกได้ เซิร์ฟเวอร์สามารถเปรียบเทียบกับเวอร์ชันล่าสุดที่รู้จัก ตกลงที่จะประมวลผลคำขอหรือไม่ และออกงานให้กับลูกค้า
หลังจากนี้ เว็บแอปพลิเคชันบางตัวจะบังคับให้โหลดเพจซ้ำในนามของผู้ใช้ เช่น หากหน้านั้นไม่อยู่ในบริเวณที่มองเห็นได้ของหน้าจอและไม่มีแบบฟอร์มให้กรอกข้อมูลครบถ้วน
วิธีที่ดียิ่งขึ้นคือการสลับโค้ดทันที ซึ่งหมายความว่าคุณไม่จำเป็นต้องโหลดหน้าใหม่ทั้งหมด แทนแน่นอน โมดูลจะถูกแทนที่ทันที และส่งรหัสอีกครั้งเพื่อดำเนินการ
ในแอปพลิเคชันที่มีอยู่จำนวนมาก โค้ดแบบ Hot-swap ค่อนข้างยาก เมื่อต้องการทำเช่นนี้ คุณต้องยึดตามสถาปัตยกรรมที่แยกออกจากกันตั้งแต่แรก พฤติกรรม(รหัส) จาก ข้อมูล(สถานะ). แผนกนี้จะทำให้เราสามารถเผยแพร่แพตช์ต่างๆ มากมายได้อย่างรวดเร็ว
ตัวอย่างเช่น ในเว็บแอปพลิเคชันของเรา มีโมดูลที่ตั้งค่าบัสสำหรับส่งเหตุการณ์ (เช่น socket.io) เมื่อมีเหตุการณ์เกิดขึ้น สถานะขององค์ประกอบเฉพาะจะเปลี่ยนไป และสิ่งนี้จะสะท้อนให้เห็นใน DOM จากนั้นคุณเปลี่ยนลักษณะการทำงานของส่วนประกอบนั้น ตัวอย่างเช่น เพื่อให้สร้างมาร์กอัป DOM ที่แตกต่างกันสำหรับสถานะที่มีอยู่และสถานะใหม่
ตามหลักการแล้ว เราควรจะสามารถเปลี่ยนแปลงโค้ดแบบโมดูลาร์ได้ ไม่จำเป็นต้องสร้างการเชื่อมต่อกับซ็อกเก็ตอีกครั้ง ตัวอย่างเช่น หากเป็นไปได้ที่จะอัปเดตโค้ดของส่วนประกอบที่จำเป็น สถาปัตยกรรมในอุดมคติสำหรับการอัพเดตพุชโค้ดจึงเป็นแบบโมดูลาร์
แต่ปัญหาเกิดขึ้นทันทีในการประเมินโมดูลโดยไม่มีผลข้างเคียงที่ไม่พึงประสงค์ สถาปัตยกรรมแบบที่ React นำเสนอเหมาะที่สุดที่นี่ หากมีการอัปเดตโค้ดของส่วนประกอบ ตรรกะของส่วนประกอบนั้นก็สามารถดำเนินการอีกครั้งและ DOM จะได้รับการอัปเดต อ่านคำอธิบายของ Dan Abramov เกี่ยวกับแนวคิดนี้
โดยพื้นฐานแล้ว แนวคิดก็คือให้คุณอัปเดต DOM (หรือเปลี่ยนสี) ซึ่งช่วยในการแทนที่โค้ดเป็นหลัก หากสถานะถูกเก็บไว้ใน DOM หรือแอปพลิเคชันติดตั้งตัวจัดการเหตุการณ์ การอัปเดตโค้ดอาจกลายเป็นงานที่ยากขึ้นมาก
7. การทำนายพฤติกรรม tl; DR: ความล่าช้าเชิงลบแอปพลิเคชัน JavaScript สมัยใหม่อาจมีกลไกในการทำนายการกระทำของผู้ใช้
การใช้งานแนวคิดนี้ที่ชัดเจนที่สุดคือการดาวน์โหลดข้อมูลจากเซิร์ฟเวอร์ล่วงหน้าก่อนที่ผู้ใช้จะร้องขอ การโหลดหน้าเว็บโดยวางเคอร์เซอร์ของเมาส์ไว้เหนือหน้าเว็บเพื่อให้การคลิกลิงก์ปรากฏขึ้นทันทีเป็นตัวอย่างง่ายๆ
วิธีการตรวจสอบการติดตามเมาส์ขั้นสูงกว่าเล็กน้อยจะวิเคราะห์วิถีการเคลื่อนที่ของเมาส์สำหรับ "การชน" ในอนาคตด้วยองค์ประกอบแบบโต้ตอบเช่นปุ่ม -
ปลั๊กอิน jQuery ทำนายเส้นทางของเมาส์
เพจที่มีไฮเปอร์ลิงก์เป็นองค์ประกอบที่ดีสำหรับแอปพลิเคชันใดๆ การโหลดโค้ด สไตล์ และมาร์กอัปอย่างต่อเนื่องในขณะที่ผู้ใช้โต้ตอบ ช่วยให้มั่นใจถึงประสิทธิภาพที่ยอดเยี่ยมโดยไม่ต้องเสียสละการโต้ตอบ
JavaScript มีคุณสมบัติพิเศษใหม่ให้ หากเทคโนโลยีเหล่านี้มีการใช้กันอย่างแพร่หลาย พวกเขาจะมอบประสบการณ์ที่ดีที่สุดให้กับผู้ใช้แพลตฟอร์มที่เสรีที่สุดเท่าที่มีอยู่ - WWW
แท็ก:
- เวลาแฝง
- ผลงาน
- พีแจ็กซ์
- เทอร์โบลิงค์
เรียนรู้แนวทางใหม่อันทรงพลังสำหรับสถาปัตยกรรมเว็บและการออกแบบเว็บไซต์ตามประสบการณ์ หนังสือเล่มนี้นำเสนอแนวทางเชิงปฏิบัติ การแก้ปัญหา และคำนึงถึงผู้ใช้เป็นศูนย์กลางในการวางแผน ออกแบบ และพัฒนาเว็บแอปพลิเคชันแบบไดนามิก คุณจะได้เรียนรู้วิธีใช้ประโยชน์สูงสุดจากการออกแบบที่ขับเคลื่อนด้วยโดเมน เรียนรู้วิธีกำหนดสถาปัตยกรรมการสนับสนุนที่เหมาะสมที่สุด และเชี่ยวชาญแนวทางการออกแบบที่เน้นประสบการณ์สมัยใหม่ ผู้เขียนตรวจสอบการเลือกและการใช้เทคโนโลยีเฉพาะ รวมถึงหัวข้อสำคัญที่เกี่ยวข้องกับประสบการณ์ผู้ใช้ รวมถึงการออกแบบแอปพลิเคชันเว็บบนมือถือและการออกแบบที่ตอบสนอง คุณจะได้เรียนรู้การใช้เทคโนโลยี Microsoft ให้เกิดประโยชน์สูงสุด เช่น ASP.NET MVC และ SignaIR ร่วมกับเทคโนโลยีอื่นๆ เช่น Bootstrap, AJAX, JSON และ JQuery ด้วยการใช้เทคโนโลยีเหล่านี้และการเรียนรู้แพลตฟอร์ม ASP.NET Core 1.0 ใหม่ คุณสามารถ...
อ่านให้ครบถ้วนเรียนรู้แนวทางใหม่อันทรงพลังสำหรับสถาปัตยกรรมเว็บและการออกแบบเว็บไซต์ตามประสบการณ์ หนังสือเล่มนี้นำเสนอแนวทางเชิงปฏิบัติ การแก้ปัญหา และคำนึงถึงผู้ใช้เป็นศูนย์กลางในการวางแผน ออกแบบ และพัฒนาเว็บแอปพลิเคชันแบบไดนามิก คุณจะได้เรียนรู้วิธีใช้ประโยชน์สูงสุดจากการออกแบบที่ขับเคลื่อนด้วยโดเมน เรียนรู้วิธีกำหนดสถาปัตยกรรมการสนับสนุนที่เหมาะสมที่สุด และเชี่ยวชาญแนวทางการออกแบบที่เน้นประสบการณ์สมัยใหม่ ผู้เขียนตรวจสอบการเลือกและการใช้เทคโนโลยีเฉพาะ รวมถึงหัวข้อสำคัญที่เกี่ยวข้องกับประสบการณ์ผู้ใช้ รวมถึงการออกแบบแอปพลิเคชันเว็บบนมือถือและการออกแบบที่ตอบสนอง คุณจะได้เรียนรู้การใช้เทคโนโลยี Microsoft ให้เกิดประโยชน์สูงสุด เช่น ASP.NET MVC และ SignaIR ร่วมกับเทคโนโลยีอื่นๆ เช่น Bootstrap, AJAX, JSON และ JQuery ด้วยการใช้ประโยชน์จากเทคโนโลยีเหล่านี้และการเรียนรู้เฟรมเวิร์ก ASP.NET Core 1.0 ใหม่ คุณสามารถพัฒนาเว็บแอปพลิเคชันที่ซับซ้อนซึ่งแก้ไขปัญหาในชีวิตจริงและมอบประสบการณ์ที่ยอดเยี่ยมได้อย่างรวดเร็ว
Dino Esposito ผู้เชี่ยวชาญที่ทรงคุณค่าที่สุดของ Microsoft หลายคน จะสอนวิธี:
- ออกแบบเว็บไซต์และแอปพลิเคชันเว็บที่สะท้อนถึงกระบวนการทางสังคมและธุรกิจที่แท้จริง
- ใช้วิธีการออกแบบเฉพาะโดเมนเพื่อวิเคราะห์และลดความซับซ้อนของสาขาวิชา
- ใช้การออกแบบที่ขับเคลื่อนด้วยประสบการณ์เพื่อลดต้นทุนและตอบสนองความต้องการของผู้ใช้
- เปรียบเทียบกระบวนทัศน์เว็บเซิร์ฟเวอร์และไคลเอ็นต์ตามความเป็นจริง
- พื้นฐานของแพลตฟอร์ม ASP.NET Core 1.0 ใหม่
- ลดความซับซ้อนของการพัฒนาหน้าเว็บสมัยใหม่โดยใช้กรอบงาน Bootstrap
- เทคนิคที่เป็นประโยชน์และมีประสิทธิภาพสำหรับการดำเนินโครงการ ASP.NET MVC
- คำนึงถึงความเป็นไปได้ใหม่ในการใช้กลไกการจัดเก็บข้อมูลและการทำงานกับแบบจำลองข้อมูล
- เข้าใจข้อดี ข้อเสีย และข้อเสียของการออกแบบเว็บไซต์แบบตอบสนอง
- สร้างเว็บไซต์บนมือถือและมือถืออย่างแท้จริง
เผยเเพร่โดย
ทีมงานผลิตภัณฑ์ Microsoft Developer Division, .NET และ Visual Studio
แผนกหนึ่งของ Microsoft Corporation
วิธีหนึ่งของ Microsoft วิธีหนึ่งของ Microsoft
เรดมันด์ วอชิงตัน 98052-6399
© 2019 Microsoft Corporation ลิขสิทธิ์ © 2019 โดย Microsoft Corporation
สงวนลิขสิทธิ์. สงวนลิขสิทธิ์.
ห้ามทำซ้ำหรือส่งต่อหนังสือเล่มนี้ทั้งหมดหรือบางส่วน ในรูปแบบใดๆ หรือโดยวิธีการใดๆ โดยไม่ได้รับอนุญาตเป็นลายลักษณ์อักษรจากผู้จัดพิมพ์ ห้ามทำซ้ำหรือส่งต่อเนื้อหาส่วนใดส่วนหนึ่งของหนังสือเล่มนี้ในรูปแบบใด ๆ หรือโดยวิธีการใด ๆ โดยไม่ได้รับอนุญาตเป็นลายลักษณ์อักษรจากผู้จัดพิมพ์
หนังสือเล่มนี้จัดทำขึ้น "ตามสภาพ" และเป็นการแสดงความคิดเห็นและความคิดเห็นของผู้เขียน หนังสือเล่มนี้จัดทำขึ้น "ตามสภาพ" และแสดงความคิดเห็นและความคิดเห็นของผู้เขียน มุมมอง ความคิดเห็น และข้อมูลที่มีอยู่ในหนังสือเล่มนี้ รวมถึง URL และลิงก์เว็บไซต์อื่นๆ อาจมีการเปลี่ยนแปลงได้โดยไม่ต้องแจ้งให้ทราบ มุมมอง ความคิดเห็น และข้อมูลที่แสดงในหนังสือเล่มนี้ รวมถึง URL และการอ้างอิงเว็บไซต์อินเทอร์เน็ตอื่นๆ อาจเปลี่ยนแปลงได้โดยไม่ต้องแจ้งให้ทราบ
ตัวอย่างบางส่วนที่ให้ไว้ในหนังสือเล่มนี้มีวัตถุประสงค์เพื่อการอธิบายเท่านั้นและเป็นเพียงเรื่องสมมติ ตัวอย่างบางส่วนที่ปรากฎในที่นี้จัดทำขึ้นเพื่อประกอบการอธิบายเท่านั้นและเป็นเพียงเรื่องสมมติ ความคล้ายคลึงกับชื่อจริง ผู้คน และวัตถุอื่นๆ ทั้งหมดนั้นเกิดขึ้นโดยไม่ได้ตั้งใจและเกิดขึ้นโดยบังเอิญ ไม่มีการเชื่อมโยงหรือความเชื่อมโยงที่แท้จริงที่มีจุดมุ่งหมายหรือไม่ควรอนุมาน
Microsoft และเครื่องหมายการค้าที่แสดงอยู่ในหน้าเครื่องหมายการค้าที่ https://www.microsoft.com เป็นเครื่องหมายการค้าของกลุ่มบริษัท Microsoft Microsoft และเครื่องหมายการค้าที่แสดงอยู่ที่ https://www.microsoft.com บนเว็บเพจ “เครื่องหมายการค้า” เป็นเครื่องหมายการค้าของกลุ่มบริษัท Microsoft
Mac และ macOS เป็นเครื่องหมายการค้าของ Apple Inc. Mac และ macOS เป็นเครื่องหมายการค้าของ Apple Inc.
โลโก้วาฬ Docker เป็นเครื่องหมายการค้าจดทะเบียนของ Docker, Inc. ใช้โดยได้รับอนุญาต โลโก้วาฬ Docker เป็นเครื่องหมายการค้าจดทะเบียนของ Docker, Inc. ใช้โดยได้รับอนุญาต
ชื่อและโลโก้อื่นๆ ทั้งหมดเป็นทรัพย์สินของเจ้าของที่เกี่ยวข้อง เครื่องหมายและโลโก้อื่นๆ ทั้งหมดเป็นทรัพย์สินของเจ้าของที่เกี่ยวข้อง
Steve Smith - สถาปนิกและผู้ฝึกสอนซอฟต์แวร์ - Ardalis.com Steve "ardalis" Smith - สถาปนิกและผู้ฝึกสอนซอฟต์แวร์ - Ardalis.com
บรรณาธิการ: บรรณาธิการ:
ไมร่า เวนเซล ไมร่า เวนเซลNET Core และ ASP.NET Core มีข้อดีหลายประการเหนือการพัฒนา .NET แบบดั้งเดิม .NET Core และ ASP.NET Core มีข้อดีหลายประการเหนือการพัฒนา .NET แบบดั้งเดิม คุณควรใช้ .NET Core สำหรับแอปพลิเคชันเซิร์ฟเวอร์ของคุณ หากบางส่วนหรือทั้งหมดต่อไปนี้มีความสำคัญต่อความสำเร็จของแอปพลิเคชันของคุณ:
รองรับแพลตฟอร์มต่างๆ การสนับสนุนข้ามแพลตฟอร์ม
การใช้ไมโครเซอร์วิส การใช้ไมโครเซอร์วิส
การใช้คอนเทนเนอร์นักเทียบท่า การใช้คอนเทนเนอร์นักเทียบท่า
ข้อกำหนดสำหรับประสิทธิภาพและความสามารถในการปรับขนาดที่สูง ข้อกำหนดด้านประสิทธิภาพและความสามารถในการปรับขนาดสูง
การกำหนดเวอร์ชันขนานของแอปพลิเคชัน .NET บนเซิร์ฟเวอร์เดียว การกำหนดเวอร์ชันแบบเคียงข้างกันของเวอร์ชัน .NET ตามแอปพลิเคชันบนเซิร์ฟเวอร์เดียวกัน
ข้อกำหนดเหล่านี้ได้รับการสนับสนุนโดยแอปพลิเคชัน .NET มาตรฐานจำนวนมาก แต่แพลตฟอร์ม ASP.NET Core และ .NET Core ที่ได้รับการปรับให้เหมาะสมจะให้การสนับสนุนขั้นสูงสำหรับสถานการณ์ข้างต้น แอปพลิเคชัน .NET แบบดั้งเดิมสามารถรองรับข้อกำหนดเหล่านี้ได้หลายอย่าง แต่ ASP.NET Core และ .NET Core ได้รับการปรับให้เหมาะสมเพื่อให้การสนับสนุนที่ได้รับการปรับปรุงสำหรับสถานการณ์ข้างต้น
องค์กรจำนวนมากขึ้นเรื่อยๆ เลือกที่จะโฮสต์เว็บแอปพลิเคชันของตนในระบบคลาวด์โดยใช้บริการต่างๆ เช่น Microsoft Azure องค์กรจำนวนมากขึ้นเรื่อยๆ เลือกที่จะโฮสต์เว็บแอปพลิเคชันของตนในระบบคลาวด์โดยใช้บริการต่างๆ เช่น Microsoft Azure คุณควรพิจารณาโฮสต์แอปพลิเคชันของคุณในระบบคลาวด์หากสิ่งต่อไปนี้มีความสำคัญต่อแอปพลิเคชันหรือองค์กรของคุณ:
ลดการลงทุนในต้นทุนศูนย์ข้อมูล (ฮาร์ดแวร์ ซอฟต์แวร์ พื้นที่ ยูทิลิตี้ การจัดการเซิร์ฟเวอร์ ฯลฯ)
ราคาที่ยืดหยุ่น (การชำระเงินสำหรับทรัพยากรที่ใช้จริง ไม่ใช่ทรัพยากรที่ไม่ได้ใช้งาน) ราคาที่ยืดหยุ่น (จ่ายตามการใช้งาน ไม่ใช่ความจุที่ไม่ได้ใช้งาน)
ความน่าเชื่อถือที่ยอดเยี่ยม ความน่าเชื่อถือสูงสุด
ปรับปรุงความคล่องตัวของแอปพลิเคชัน เปลี่ยนสถานที่และวิธีปรับใช้ได้อย่างง่ายดาย ปรับปรุงความคล่องตัวของแอป เปลี่ยนสถานที่และวิธีปรับใช้แอปของคุณได้อย่างง่ายดาย
ความจุที่ยืดหยุ่น ปรับขนาดได้ตามความต้องการที่แท้จริง ความจุที่ยืดหยุ่น ขยายหรือลดขนาดตามความต้องการที่แท้จริง
การสร้างแอปพลิเคชันเว็บด้วย ASP.NET Core ที่โฮสต์บน Azure มีข้อได้เปรียบทางการแข่งขันมากกว่าทางเลือกแบบเดิมๆ มากมาย การสร้างแอปพลิเคชันเว็บด้วย ASP.NET Core ซึ่งโฮสต์ใน Azure มอบข้อได้เปรียบทางการแข่งขันมากมายเหนือทางเลือกแบบเดิม ASP.NET Core ได้รับการปรับให้เหมาะสมสำหรับแนวทางปฏิบัติในการพัฒนาเว็บไซต์สมัยใหม่และสถานการณ์การโฮสต์บนคลาวด์ ASP.NET Core ได้รับการปรับให้เหมาะสมสำหรับแนวทางปฏิบัติในการพัฒนาเว็บแอปพลิเคชันสมัยใหม่และสถานการณ์การโฮสต์บนคลาวด์ ในบทช่วยสอนนี้ คุณจะได้เรียนรู้วิธีการออกแบบแอปพลิเคชัน ASP.NET Core เพื่อใช้ประโยชน์จากความสามารถเหล่านี้อย่างเต็มที่ ในคู่มือนี้ คุณจะได้เรียนรู้วิธีการออกแบบแอปพลิเคชัน ASP.NET Core ของคุณเพื่อใช้ประโยชน์จากความสามารถเหล่านี้ให้เกิดประโยชน์สูงสุด
วัตถุประสงค์เอกสารนี้เป็นแนวทางที่สมบูรณ์ในการสร้าง เสาหินเว็บแอปพลิเคชันที่ใช้ ASP.NET Core และ Azure คู่มือนี้ให้คำแนะนำตั้งแต่ต้นจนจบเกี่ยวกับการสร้าง เสาหินเว็บแอปพลิเคชันที่ใช้ ASP.NET Core และ Azure ในบริบทนี้ เสาหินหมายความว่าแอปพลิเคชันเหล่านี้ถูกปรับใช้เป็นหน่วยเดียว แทนที่จะเป็นชุดของบริการและแอปพลิเคชันเชิงโต้ตอบ ในบริบทนี้ "เสาหิน" หมายถึงข้อเท็จจริงที่ว่าแอปพลิเคชันเหล่านี้ใช้งานเป็นหน่วยเดียว ไม่ใช่ชุดของบริการและแอปพลิเคชันที่มีการโต้ตอบ
คู่มือนี้เป็นส่วนเสริมของไมโครเซอร์วิส" .สุทธิ. สถาปัตยกรรมสำหรับแอปพลิเคชัน .NET ที่มีคอนเทนเนอร์"โดยมุ่งเน้นไปที่ Docker, ไมโครเซอร์วิส และการปรับใช้คอนเทนเนอร์สำหรับการโฮสต์แอปพลิเคชันระดับองค์กร คู่มือนี้เป็นส่วนเสริมของ " .NET ไมโครเซอร์วิส สถาปัตยกรรมสำหรับแอปพลิเคชัน Containerized .NET" ซึ่งมุ่งเน้นไปที่ Docker, Microservices และการปรับใช้คอนเทนเนอร์เพื่อโฮสต์แอปพลิเคชันระดับองค์กรมากขึ้น
.NET ไมโครเซอร์วิส .NET ไมโครเซอร์วิส สถาปัตยกรรมสำหรับแอปพลิเคชัน Containerized .NET- e-book
https://aka.ms/MicroservicesEbook - แอปพลิเคชันตัวอย่าง
https://aka.ms/microservicesarchitecture
คู่มือนี้มีไว้สำหรับนักพัฒนา ผู้จัดการฝ่ายพัฒนา และสถาปนิกที่สนใจสร้างแอปพลิเคชันเว็บสมัยใหม่โดยใช้เทคโนโลยีและบริการของ Microsoft ในระบบคลาวด์เป็นหลัก ผู้ชมสำหรับคู่มือนี้ส่วนใหญ่เป็นนักพัฒนา หัวหน้าฝ่ายพัฒนา และสถาปนิกที่สนใจสร้างแอปพลิเคชันเว็บสมัยใหม่โดยใช้เทคโนโลยีและบริการของ Microsoft ในระบบคลาวด์
ผู้ชมรองคือผู้มีอำนาจตัดสินใจทางเทคนิคที่คุ้นเคยกับ ASP.NET หรือ Azure อยู่แล้ว และต้องการข้อมูลเกี่ยวกับการอัพเกรดเป็น ASP.NET Core เพื่อพัฒนาโครงการใหม่และสนับสนุนโครงการที่มีอยู่ ผู้ชมรองคือผู้มีอำนาจตัดสินใจทางเทคนิคที่คุ้นเคยกับ ASP.NET หรือ Azure อยู่แล้ว และกำลังมองหาข้อมูลว่าควรอัปเกรดเป็น ASP.NET Core สำหรับโปรเจ็กต์ใหม่หรือโปรเจ็กต์ที่มีอยู่หรือไม่
คุณสามารถใช้คู่มือนี้ได้อย่างไรคู่มือนี้ได้รับการย่อเป็นเอกสารที่ค่อนข้างสั้นซึ่งเน้นไปที่การสร้างแอปพลิเคชันเว็บโดยใช้เทคโนโลยี .NET และ Windows Azure ที่ทันสมัย คู่มือนี้ย่อเป็นเอกสารขนาดค่อนข้างเล็กซึ่งมุ่งเน้นที่การสร้างแอปพลิเคชันเว็บด้วยเทคโนโลยี .NET ที่ทันสมัย และ Windows Azure ดังนั้น เพื่อให้เข้าใจพื้นฐานเกี่ยวกับการใช้งานเหล่านี้และเข้าใจคำแนะนำทางเทคนิคที่เกี่ยวข้อง โปรดอ่านเอกสารทั้งหมด ด้วยเหตุนี้จึงสามารถอ่านได้ทั้งหมดเพื่อเป็นรากฐานในการทำความเข้าใจการใช้งานดังกล่าวและข้อควรพิจารณาทางเทคนิค คู่มือนี้พร้อมกับตัวอย่างการใช้งาน อาจเป็นจุดเริ่มต้นที่ดีหรือเป็นเอกสารอ้างอิงที่เป็นประโยชน์ คู่มือนี้พร้อมทั้งการใช้งานตัวอย่างสามารถใช้เป็นจุดเริ่มต้นหรือข้อมูลอ้างอิงได้ ใช้แอปพลิเคชันตัวอย่างที่ให้มาเป็นเทมเพลตสำหรับแอปพลิเคชันของคุณเอง หรือเพื่อดูว่าคุณสามารถจัดระเบียบส่วนประกอบของแอปพลิเคชันได้อย่างไร ใช้แอปพลิเคชันตัวอย่างที่เกี่ยวข้องเป็นเทมเพลตสำหรับแอปพลิเคชันของคุณเอง หรือเพื่อดูว่าคุณจะจัดระเบียบส่วนประกอบของแอปพลิเคชันของคุณอย่างไร เมื่อตัดสินใจว่าจะใช้ตัวเลือกเหล่านี้กับแอปพลิเคชันของคุณหรือไม่ คุณสามารถดูหลักการและทิศทางทางสถาปัตยกรรมที่อธิบายไว้ในคู่มือได้ตลอดเวลา และความสามารถทางเทคโนโลยี โปรดดูหลักการและความครอบคลุมของตัวเลือกสถาปัตยกรรมและเทคโนโลยี และข้อควรพิจารณาในการตัดสินใจเมื่อคุณชั่งน้ำหนักตัวเลือกเหล่านี้สำหรับการใช้งานของคุณเอง
หากจำเป็น คุณสามารถแนะนำคู่มือนี้ให้กับสมาชิกในทีมของคุณ เพื่อให้พวกเขาตระหนักถึงประเด็นสำคัญทั้งหมดเช่นกัน โปรดส่งต่อคู่มือนี้ให้กับทีมของคุณเพื่อช่วยให้แน่ใจว่ามีความเข้าใจร่วมกันเกี่ยวกับข้อควรพิจารณาและโอกาสเหล่านี้ หากผู้มีส่วนได้ส่วนเสียทั้งหมดใช้ชุดคำศัพท์ร่วมกันและปฏิบัติตามหลักการพื้นฐาน โมเดลและแนวปฏิบัติทางสถาปัตยกรรมจะถูกนำไปใช้อย่างสม่ำเสมอมากขึ้น การให้ทุกคนทำงานโดยใช้ชุดคำศัพท์และหลักการพื้นฐานร่วมกันช่วยให้มั่นใจได้ว่ารูปแบบและแนวทางปฏิบัติทางสถาปัตยกรรมจะถูกนำมาใช้อย่างสม่ำเสมอ
อ้างอิง- การเลือกระหว่าง .NET Core และ .NET Framework สำหรับแอปเซิร์ฟเวอร์
เราต้องการทราบความคิดเห็นของคุณ กรุณาระบุสิ่งที่คุณต้องการแจ้งให้เราทราบ
ระบบคำติชมของเรายึดตามหลักการทำงานกับปัญหาบน GitHub สำหรับข้อมูลเพิ่มเติม โปรดดู