เมื่อเร็วๆ นี้ ฉันพบกับสถานการณ์การใช้งานดังกล่าว องค์กรบางแห่งใช้ระบบที่พัฒนาโดย PowerBuilder มาหลายปีแล้ว ในขณะที่บริษัทพัฒนาขึ้น ก็ตัดสินใจแปลงระบบข้อมูลเก่าจาก C/S ไปเป็นสถาปัตยกรรม B/S ที่ได้รับความนิยม ปัญหาเกิดขึ้น: ระบบเดิมบางระบบมีการป้อนข้อมูลจำนวนมาก การพิมพ์รายงานที่แม่นยำ และฟังก์ชันอื่น ๆ และผู้ใช้คุ้นเคยกับการทำงานประเภทนี้มาก หวังว่าระบบใหม่จะสามารถคงคุณสมบัติที่ใช้งานง่ายนี้ไว้ได้ ของระบบเดิม
ฉันปวดหัวทันทีที่ได้ยินคำถามนี้ PB มีการควบคุมที่ทรงพลังมากมาย มันยากเกินไปที่จะย้ายพวกมันไปยังเบราว์เซอร์และใช้หน้าเว็บเพื่อจำลองพวกมัน
1. เหตุใดจึงเป็นเรื่องยากสำหรับ B/S ที่จะมอบประสบการณ์การโต้ตอบที่ดีแก่ผู้ใช้
มีปัญหาที่ใหญ่ที่สุดหลายประการที่นี่:
(1) โปรโตคอล HTTP ไร้สัญชาติ
สามารถแลกเปลี่ยนข้อมูลโดยตรงระหว่างแบบฟอร์ม Windows ผ่านหน่วยความจำ แต่เป็นพื้นฐานของ B/S การสื่อสารทางสถาปัตยกรรม โปรโตคอล HTTP ไม่มีสถานะ
หากเบราว์เซอร์ถือเป็นแขกและเว็บเซิร์ฟเวอร์ถือเป็นโรงแรม ภายใต้การจัดการของโปรโตคอล HTTP สถานการณ์นี้จะเกิดขึ้น: ไม่ว่าแขกจะเข้าชมกี่ครั้งก็ตาม เว็บเซิร์ฟเวอร์จะถือว่าเขาเป็นคนแรก- ผู้เยี่ยมชมเวลา ด้วยวิธีนี้ ผู้เข้าพักจะต้องนำเอกสารประจำตัวติดตัวไปด้วยทุกครั้งเพื่อให้พนักงานโรงแรม "ยืนยันตัวตน"
การไร้สัญชาติของโปรโตคอล HTTP นำไปสู่การ "เพิกเฉย" ของเว็บเซิร์ฟเวอร์ แม้ว่าการทำเช่นนี้จะช่วยเพิ่มปริมาณงานของเว็บเซิร์ฟเวอร์ แต่ก็นำปัญหามาสู่การพัฒนาระบบแอปพลิเคชัน เนื่องจากมักจะมีกระบวนการประมวลผลทางธุรกิจมากมายในระบบแอปพลิเคชันซึ่งมีการไหลเวียนของข้อมูลโดยเนื้อแท้ กล่าวคือ ข้อมูลต้นฉบับเข้ามาจากปลายด้านหนึ่งและควรได้รับการประมวลผลบางอย่างเมื่อมันออกมาจากปลายอีกด้านหนึ่ง จะจินตนาการได้อย่างไร ข้อมูลในกระบวนการทางธุรกิจทั้งหมดจะสูญหายไป ดังนั้น การแบ่งปันข้อมูลระหว่างคำขอ HTTP จึงกลายเป็นเรื่องยุ่งยาก นี่คือปัญหา "การเก็บรักษาสถานะ" ของคำขอ HTTP ระบบ B/S ทุกระบบจะต้องแก้ไขปัญหานี้ Microsoft คิดถึง "กลอุบายที่คดเคี้ยว" บางอย่าง เช่น การใช้ฟิลด์ที่ซ่อนอยู่ในหน้าเว็บ HTML ให้เกิดประโยชน์สูงสุด จากนั้นจึงใช้เทคนิคบางอย่างบนเว็บเซิร์ฟเวอร์ ดังนั้น ASP.NET จึงมีชุดเทคโนโลยีเพื่อรักษาสถานะระหว่างคำขอ HTTP แต่ละรายการ: เซสชัน, คุกกี้, ViewState, โปรไฟล์, แอปพลิเคชัน
อย่างไรก็ตาม ปัญหายังไม่ได้รับการแก้ไขอย่างสมบูรณ์ ตัวอย่างเช่น ในกล่องโต้ตอบทั่วไปในระบบ C/S ที่รวบรวมข้อมูลการป้อนข้อมูลของผู้ใช้ มีการแลกเปลี่ยนข้อมูลระหว่างแบบฟอร์มหลักและกล่องโต้ตอบ (แบ่งออกเป็นสองประเภท: แบบโมดอล และแบบไม่ใช่โมดัล กล่องโต้ตอบเดิมคือ ไม่ได้ปิด แบบฟอร์มหลักไม่สามารถเปิดใช้งานได้) ภายใต้สถาปัตยกรรม B/S เนื่องจากแต่ละคำขอของเบราว์เซอร์มีความเป็นอิสระ การแลกเปลี่ยนข้อมูลโดยตรงที่คล้ายกับกล่องโต้ตอบโมดอลจะต้องดำเนินการระหว่างสองหน้าต่างเบราว์เซอร์ที่เป็นอิสระ รู้ว่าต้องทำอะไร
AJAX ใช้วิธีการต่อไปนี้เพื่อ "จำลอง" รูปแบบโมดอล: "รวม" รูปแบบหลักและกล่องโต้ตอบให้เป็นหนึ่งเดียว กล่องโต้ตอบเป็นองค์ประกอบ div ใน HTML ซึ่งโดยปกติจะถูกซ่อนและแสดงเมื่อจำเป็น ชุดเครื่องมือควบคุม AJAX ของ Microsoft ยังมีการควบคุมที่ออกแบบมาสำหรับฟังก์ชันนี้อีกด้วย มีเคล็ดลับเช่นนี้มากมายในการพัฒนา B/S
จะเห็นได้ว่าฟังก์ชันต่างๆ มากมายที่สามารถใช้งานได้ง่ายใน C/S นั้นยากมากที่จะนำไปใช้ใน B/S
(2) สภาพแวดล้อมการทำงานพิเศษ -
สภาพแวดล้อมการทำงานส่วนหน้าของระบบ B/S ของเบราว์เซอร์คือเบราว์เซอร์ ซึ่งมีข้อจำกัดมากมาย ไม่สามารถทำสิ่งต่างๆ ได้มากมาย เช่น การเข้าถึงฮาร์ดแวร์โดยตรง (เช่น เครื่องพิมพ์) และไม่สามารถทำให้เต็มรูปแบบได้ การใช้มัน ทรัพยากรฮาร์ดแวร์ ตัวอย่างเช่น คอมพิวเตอร์เครื่องใหม่ในปัจจุบันเป็นแบบดูอัลคอร์ คุณสามารถใช้ JavaScript และ HTML โดยตรงเพื่อเขียนโปรแกรมแบบมัลติเธรดเพื่อใช้งาน "Pentium core" ทั้งสองนี้อย่างเต็มที่ได้หรือไม่
ระบบ C/S ทำงานบนระบบปฏิบัติการโดยตรง (ระบบปฏิบัติการ) system) ข้างต้น คุณสามารถเรียกใช้ฟังก์ชันทั้งหมดที่มีให้โดยระบบปฏิบัติการได้ และไม่มีข้อจำกัดนี้
(3) ภาษาโปรแกรมเว็บไคลเอ็นต์ที่น่าอับอาย - JavaScript ซึ่ง
เป็นโปรแกรม C/S แบบดั้งเดิม สามารถใช้ภาษาการพัฒนาได้หลากหลายภาษา โดยเฉพาะภาษาเชิงวัตถุกระแสหลัก เช่น C++, Java และ C# ซึ่งได้แก่ ทรงพลังและใช้งานง่าย มีเครื่องมือการพัฒนาที่หลากหลายและมีความเป็นผู้ใหญ่มาก
ในทางตรงกันข้าม JavaScript ซึ่งเป็นภาษาการเขียนโปรแกรมที่ใช้กันมากที่สุดในส่วนหน้าของ B/S ไม่เพียงแต่ไม่ชอบเท่านั้น แต่ยัง "เกลียด" โดยโปรแกรมเมอร์หลายคนที่ถือว่า "การเขียนโปรแกรมด้วย JavaScript" เป็นเพียงงานที่น่าเบื่อ
มาดูข้อบกพร่องสำคัญสองประการของ JavaScript กัน
ประการแรก ขาดโมเดลการเขียนโปรแกรมที่ชัดเจนและเป็นหนึ่งเดียว
แม้ว่า JavaScript จะมีชื่อ Java และใช้ไวยากรณ์ที่คล้ายกัน แต่ก็ไม่เกี่ยวข้องกับ Java จริงเลย อนิจจา เธอเป็นลูกเป็ดขี้เหร่ เธออยากเป็นหงส์มาโดยตลอด แต่เธอไม่คาดคิดว่าคนอื่นจะไม่ซื้อความคิดของเธอ
JavaScript ใช้ object จำนวนมาก แต่จริงๆ แล้วมันไม่น่าเชื่อถือเลยที่จะบอกว่า JavaScript เป็นเชิงวัตถุ (หน่วยพื้นฐานของการเขียนโปรแกรมเชิงวัตถุคือคลาส) ตัวอย่างเช่น ไม่มีคลาสคำหลักที่คล้ายกับภาษาเชิงวัตถุกระแสหลัก เช่น C# มันมีฟังก์ชั่นทุกที่ซึ่งทำให้ยากต่อการกำหนดโค้ดทั้งหมดในรูปแบบของคลาสให้ชัดเจน ในเวลาเดียวกันก็ไม่มีโครงสร้าง (หน่วยพื้นฐานของการเขียนโปรแกรมที่มีโครงสร้างเป็นฟังก์ชัน ) เนื่องจากเบราว์เซอร์ใช้สตรีมเมื่อแยกวิเคราะห์เอกสาร HTML ซึ่งส่งผลให้โค้ด JavaScript บางส่วนถูกวางนอกฟังก์ชันและดำเนินการโดยตรงเมื่อแยกวิเคราะห์เอกสาร HTML ในขณะที่ส่วนอื่น ๆ ของโค้ดที่วางในฟังก์ชันส่วนใหญ่จะทำงานในเหตุการณ์ - ลักษณะที่ขับเคลื่อนด้วยซึ่งนำมาซึ่งปัญหาที่ซับซ้อน โฟลว์การดำเนินการของโปรแกรมมีความกระชับน้อยกว่าการใช้การเรียกฟังก์ชันแบบครบวงจรในการเขียนโปรแกรมที่มีโครงสร้างล้วนๆ
จากมุมมองนี้ JavaScript มีลักษณะของวิธีการเขียนโปรแกรมเชิงวัตถุ มีโครงสร้าง และไม่มีโครงสร้าง แต่ไม่ใช่ทั้งปลาและไก่ มันไม่มีรูปแบบการเขียนโปรแกรมที่ชัดเจนและเป็นหนึ่งเดียว เป็นการยากที่จะเขียนโค้ดที่ชัดเจน โครงสร้างและการบำรุงรักษาง่าย เกิดความสับสนมากมาย
ประการที่สอง ข้อบกพร่องอีกประการหนึ่งของ JavaScript คือสภาพแวดล้อมการทำงานของเบราว์เซอร์
เนื่องจากเหตุผลทางประวัติศาสตร์ เบราว์เซอร์ที่แตกต่างกัน และแม้แต่เบราว์เซอร์เดียวกันในเวอร์ชันที่แตกต่างกัน จึงมีโมเดลการเขียนโปรแกรมที่แตกต่างกันไม่มากก็น้อย ดังนั้น เราจึงต้องเขียนโค้ดเพื่อตรวจจับประเภทของเบราว์เซอร์ ตัวอย่างเช่น เราต้องเขียนชุดโค้ดสำหรับ IE และเขียนชุดอื่นสำหรับ FireFox นี่เป็นเรื่องยุ่งยากจริงๆ
ปัญหาข้างต้นเกือบจะเป็น "ข้อบกพร่อง" "โดยธรรมชาติ" ของระบบสถาปัตยกรรม B/S ข้อบกพร่องโดยกำเนิดได้รับการเสริมด้วยการเลี้ยงดู และผู้คนก็มีกลเม็ดมากมายในการแก้ปัญหาเหล่านี้ AJAX คือดาวเด่นแห่งความหวังที่ทุกคนมองโลกในแง่ดี
2. ดาวแห่งความหวัง - AJAX
ในช่วงไม่กี่วันที่ผ่านมา ฉันได้เรียนรู้เกี่ยวกับเฟรมเวิร์ก AJAX ของ Microsoft อย่างเป็นระบบ ฉันพบว่าความซับซ้อนของเฟรมเวิร์กนี้เกินประมาณการเดิมของฉันมาก วิศวกรของ Microsoft ผู้ออกแบบเฟรมเวิร์ก AJAX ได้สำรวจศักยภาพของเทคโนโลยีการพัฒนาเว็บต่างๆ อย่างลึกซึ้ง ซึ่งส่วนใหญ่ชดเชยปัญหาที่เกิดขึ้นก่อนหน้านี้
(1) การขยายภาษา JavaScript:
Microsoft ได้ปรับปรุงคุณสมบัติเชิงวัตถุของ JavaScript โดยจัดให้มีไลบรารี AJAX แบบห่อหุ้ม ซึ่งสามารถใช้ฟังก์ชันต่างๆ เช่น การสืบทอด การกำหนดอินเทอร์เฟซ การทำให้เป็นอนุกรมวัตถุ การทริกเกอร์เหตุการณ์ ประเภทการสะท้อน ฯลฯ ได้อย่างง่ายดาย มีขนาดเล็กกว่าของจริง ยังมีช่องว่างระหว่างภาษาเชิงวัตถุ (เช่น Java/C#) แต่ความสามารถในการแต่ง JavaScript ที่ "น่าเกลียด" เป็นสิ่งที่มองเห็นได้ก็ถือว่าไม่ธรรมดา
(2) ปรับปรุงการทำงานของโค้ดฝั่งเบราว์เซอร์อย่างมีนัยสำคัญ
ด้วยการรองรับ AJAX Library และฟังก์ชันการทำงานที่ได้รับการปรับปรุงของ JavaScript และด้วยการรองรับของเบราว์เซอร์เอง คุณสามารถเขียนสคริปต์ JavaScript ในเบราว์เซอร์เพื่อสร้างคำขอแบบอะซิงโครนัสไปยัง เซิร์ฟเวอร์ รีเฟรชเพจได้บางส่วน และสามารถเรียกบริการเว็บได้โดยตรง
(3) การแนะนำวิธีการพัฒนาแบบใช้คอมโพเนนต์
(CBD) เป็นวิธีการพัฒนาแบบกระแสหลักสำหรับระบบเชิงวัตถุมาช้านานแล้ว ถึงจุดอิ่มตัวของ CBD ก็คงต้องใช้เวลาพอสมควร
สำหรับ JavaScript ไม่ต้องพูดถึง SOA การนำ CBD ไปใช้เป็นเรื่องยากมาก
เพื่อให้ตระหนักถึง CBD นั้น Microsoft ได้ "ทำการปรับปรุงที่สำคัญ" กับ JavaScript และปรับปรุงคุณสมบัติมากมาย ตามไลบรารี Microsoft AJAX โปรแกรมเมอร์สามารถพัฒนาส่วนประกอบที่นำมาใช้ซ้ำได้สามประเภท: None_Visual Component (ส่วนประกอบที่มองไม่เห็น เทียบเท่ากับระบบเชิงวัตถุ บางส่วน ในจำนวนนี้มีฟังก์ชันสาธารณะ) พฤติกรรม (พฤติกรรม การขยายฟังก์ชันของการควบคุมเว็บที่มีอยู่) และการควบคุม (การควบคุมเว็บที่มีองค์ประกอบอินเทอร์เฟซแบบภาพ)
โดยเฉพาะอย่างยิ่ง การควบคุมหลายสิบรายการใน AJAX Control ToolKit โดยพื้นฐานแล้วทำให้การจำลอง B/S ของคุณสมบัติส่วนใหญ่ของอินเทอร์เฟซผู้ใช้ C/S และเป็นแบบจำลองสำหรับการประยุกต์ใช้โมเดลการเขียนโปรแกรมใหม่นี้
การปรับปรุงของ Microsoft ในรูปแบบการเขียนโปรแกรม JavaScript ช่วยให้วิศวกรซอฟต์แวร์สามารถพัฒนาโค้ดเว็บไคลเอ็นต์โดยใช้วิธีการพัฒนา CBD ได้ในที่สุด ฉันคิดว่านี่คือความก้าวหน้า
(4) ความสามารถฝั่งเซิร์ฟเวอร์ที่ได้รับการปรับปรุง
เพื่อเพิ่มประสิทธิภาพความสามารถของโค้ดฝั่งเบราว์เซอร์ จะต้องประสานงานผ่านฝั่งเซิร์ฟเวอร์ AJAX นั้นขึ้นอยู่กับรูปแบบการเขียนโปรแกรมที่ Browser และ Web Server รองรับซึ่งกันและกัน (เว็บเซิร์ฟเวอร์ให้บริการข้อมูลและ Browser ให้ออบเจ็กต์ XMLHttpRequest เพื่อออกคำขอแบบอะซิงโครนัสไปยังเว็บเซิร์ฟเวอร์ เมื่อข้อมูลกลับมาโปรแกรมเมอร์สามารถเขียนโค้ดใน JavaScript ไปที่ ใช้การประมวลผลหน้าเว็บบางส่วนแบบไดนามิก)
Microsoft ได้ปรับปรุงการทำงานของเฟรมเวิร์ก ASP.NET ฝั่งเซิร์ฟเวอร์ผ่านส่วนขยาย AJAX และแปลงฟังก์ชันที่ใช้กันทั่วไปให้เป็นตัวควบคุมเว็บแบบง่าย เช่น ScriptManager ตัวควบคุมหลักของ AJAX, UpdatePanel สำหรับกำหนดพื้นที่ที่สามารถอัปเดตได้ของเพจ และชุดเครื่องมือควบคุม AJAX จำนวนมากสำหรับปรับปรุงตัวควบคุม ASP.NET ที่มีอยู่ (นั่นคือ ตัวควบคุมที่แนบมากับ การควบคุมที่มีอยู่ ซึ่งมีวัตถุประสงค์เพื่อขยายฟังก์ชันใหม่ไปยังการควบคุมที่มีอยู่)
ด้วยการควบคุมเหล่านี้ การพัฒนาโปรแกรมส่วนหน้าของเว็บจะคล้ายกับการออกแบบฟอร์มใน VB ตอนนี้ไม่เพียงแต่เป็นไปได้ที่จะวาดอินเทอร์เฟซที่คล้ายกับ Windows Forms เท่านั้น แต่ยังใช้คำขอแบบอะซิงโครนัสของ AJAX และเทคโนโลยีการรีเฟรชบางส่วนของเพจ และด้วยความร่วมมือของเว็บเซิร์ฟเวอร์ ประสบการณ์ผู้ใช้จึงสามารถบังคับเข้าสู่ Windows Forms ได้
ไม่ว่าผู้คนจะดูถูก VB มากเพียงใด คลื่นความนิยมของการเขียนโปรแกรมแบบเห็นภาพที่ VB นำมานั้นมีผลกระทบในวงกว้างอย่างแน่นอน เพื่อปรับปรุงประสิทธิภาพของการพัฒนาเว็บ จะต้องดำเนินการขั้นตอนนี้
อย่างไรก็ตาม จำเป็นต้องชี้ให้เห็นว่า ไม่ว่าจะ "เติมเต็ม" มากแค่ไหนก็ตาม มันก็ "บกพร่องแต่กำเนิด" และยังเป็นเรื่องยากมากสำหรับสถาปัตยกรรม B/S ที่จะเหนือกว่า C/S ในแง่ของประสบการณ์ผู้ใช้ .
3. อนาคต: B/S หรือ C/S ใครเป็นผู้รับผิดชอบ
เนื่องจากความเรียบง่ายของการจัดการและการปรับใช้ สถาปัตยกรรม B/S จึงกลายเป็นตัวเลือกแรกสำหรับระบบข้อมูลจำนวนมากในปัจจุบัน โดยสรุป มีข้อกำหนดดังต่อไปนี้:
(1) อินเทอร์เฟซที่สวยงาม B/S มีข้อได้เปรียบในเรื่องนี้
(2) อินพุตที่สะดวก ตัวอย่างเช่น ผู้ใช้จำนวนมากหวังว่าจะป้อนข้อมูลโดยไม่ต้องใช้เมาส์ หรือกรอกข้อมูลโดยอัตโนมัติด้วยการคลิกง่ายๆ ซึ่งเป็นเรื่องยากที่จะนำไปใช้ภายใต้สถาปัตยกรรม B/S ซึ่งสามารถแก้ปัญหานี้ได้ในระดับหนึ่ง
(3) ความเร็วดุจสายฟ้า สำหรับ C/S มีหลายวิธีในการบรรลุความเร็วการตอบสนองที่รวดเร็ว แต่ไม่ใช่เรื่องง่ายสำหรับ B/S เนื่องจากข้อจำกัดของเบราว์เซอร์ ทรัพยากรฮาร์ดแวร์อันทรงพลังของไคลเอ็นต์จึงแทบไม่ได้ใช้งาน นอกจากนี้ ความเร็วเครือข่ายยังเป็นคอขวดของสถาปัตยกรรม B/S เว้นแต่ว่าแบนด์วิธจะเพิ่มขึ้นอย่างรวดเร็ว WWW จะเป็น World Wide Wait
แม้ว่า C/S จะมีประสบการณ์การใช้งานที่ดี แต่ปัญหาก็คือ เป็นการยากที่จะพัฒนาระบบแบบกระจายที่ครอบคลุมอินเทอร์เน็ตทั้งหมด นอกจากนี้ เนื่องจากจำเป็นต้องติดตั้งไคลเอนต์ การอัปเดตระบบและการจัดการเวอร์ชันส่วนประกอบจึงกลายเป็นปัญหาใหญ่ใน นอกจากนี้ ไม่เหมือนกับ B ในสถาปัตยกรรม /S จำเป็นต้องพิจารณาเฉพาะปัญหาฝั่งเซิร์ฟเวอร์ ในสถาปัตยกรรม C/S เนื่องจากมีผู้ใช้หลายรายเข้าถึงเซิร์ฟเวอร์พร้อมกัน การเรียกและการขึ้นต่อกันระหว่างส่วนประกอบจึงซับซ้อน ต้องพิจารณาด้วยเมื่อจัดการกับการเข้าถึงทรัพยากรที่ใช้ร่วมกันแบบมัลติเธรด การประมวลผลธุรกรรม ฯลฯ สำหรับฝั่งเซิร์ฟเวอร์ ปริมาณงานจะถูกจำกัดอย่างมาก ดังนั้น C/S จึงถูกสร้างขึ้นในเครือข่ายท้องถิ่นเป็นส่วนใหญ่เพื่อใช้ภายในองค์กร
ปัจจุบัน B/S และ C/S อยู่ร่วมกันโดยพื้นฐานแล้ว ด้วยการใช้เทคโนโลยี B/S อย่างแพร่หลาย เช่น AJAX ทำให้ B/S ยังคงมีความได้เปรียบ แต่ก็เป็นไปไม่ได้ที่จะ "เอาชนะ C/S" ได้อย่างสมบูรณ์ .
สิ่งที่น่าสนใจกว่านั้นคือ บริษัทใหญ่ๆ อย่าง Microsoft มีมุมมองต่อการพัฒนาของ B/S และ C/S อย่างไร
นักพัฒนาทั่วไปอย่างผมไม่มีโอกาสได้พูดคุยกับผู้บริหารของ Microsoft โดยตรง แต่เราสามารถเห็นได้จากบริษัท เส้นทางการพัฒนาผลิตภัณฑ์ ต่อไปนี้เป็นเบาะแสบางประการ:
Microsoft ดูเหมือนจะไม่เชื่อว่า B/S แสดงถึงทิศทางการพัฒนาเทคโนโลยีในอนาคต ในทางกลับกัน การกระทำหลายอย่างกำลังดำเนินไปในทิศทางของการละทิ้งเบราว์เซอร์
ประการแรก Microsoft ได้ทำให้การพัฒนาและการปรับใช้ C/S ง่ายขึ้น และเปิดตัวเทคโนโลยี Smart Client เพื่อให้สามารถดำเนินการอัปเดตโปรแกรมไคลเอนต์ C/S ได้โดยอัตโนมัติโดยไม่ต้องมีการแทรกแซงด้วยตนเอง
ประการที่สอง Microsoft ทำงานอย่างหนักเพื่อลดช่องว่างระหว่าง B/S และ C/S เมื่อออกแบบ ASP.NET Microsoft ได้ละทิ้ง ASP ซึ่งได้รับผลลัพธ์ที่ดีและนำวิธีการเขียนโปรแกรม "การควบคุมด้วยภาพ + ขับเคลื่อนด้วยเหตุการณ์" มาใช้โดยตรง ถึง VB แม้แต่เว็บเพจก็เรียกว่า "ฟอร์ม" - เว็บฟอร์ม
ประการที่สาม Microsoft อาจถือว่า AJAX เป็นเทคโนโลยีการเปลี่ยนผ่าน
Microsoft ดำเนินการกับ AJAX อย่างช้าๆ จนกระทั่งเห็นความนิยมอย่างรวดเร็วของ AJAX เนื่องจากการประยุกต์ใช้เทคโนโลยี AJAX ที่ประสบความสำเร็จโดย Google และบริษัทอื่นๆ เพื่อปรับปรุงประสบการณ์ผู้ใช้เว็บ จากนั้นจึงดำเนินการและเพิ่มส่วนขยาย AJAX ให้กับ ASP.NET เห็นได้ชัดว่ากระบวนการทั้งหมดไม่รุนแรงและมีการลงทุนทรัพยากรไม่มากซึ่งแตกต่างอย่างสิ้นเชิงจากตอนที่ Microsoft และ Netscape เปิดตัวสงครามเบราว์เซอร์ อย่างไรก็ตาม ความจริงที่ว่ามีส่วนขยาย AJAX ในตัวเป็นการกำหนดค่ามาตรฐานใน VS2008 และรวมฟังก์ชันการดีบัก JavaScript เข้ากับ IDE โดยตรง แสดงให้เห็นว่า Microsoft ยังคงเผชิญกับความเป็นจริง และตระหนักดีว่า AJAX มีตำแหน่งที่สำคัญและมีศักยภาพในการพัฒนาที่ยอดเยี่ยม
ในความเป็นจริง ฉันวิเคราะห์ว่าความทะเยอทะยานของ Microsoft คือการ "รวมโลกเป็นหนึ่งเดียว" ละทิ้งเบราว์เซอร์ และรวม B/S และ C/S เข้าด้วยกันอย่างสมบูรณ์
เห็นได้ชัดเจนใน .NET 3.0/3.5
ก่อนอื่น Microsoft ใช้ WCF เพื่อรวม DCOM, .NET Remoting และเทคโนโลยีอื่นๆ ที่ส่วนใหญ่ใช้สำหรับ C/S โดยผสานรวมคุณลักษณะการพัฒนาองค์กรจำนวนมากที่เดิมอยู่ใน COM+ ร่วมกับเทคโนโลยีบริการเว็บที่ใช้เป็นหลักสำหรับสถาปัตยกรรม B/S เพื่อรวมบทคัดย่อ และรวมเข้าเป็นบริการ WCF ที่นำมาใช้ซ้ำได้ เห็นได้ชัดว่า Microsoft ต้องการเปลี่ยนรูปแบบการพัฒนาระบบสารสนเทศจาก CBD เป็น SOA (นั่นคือระบบในอนาคตจะประกอบบริการแทนส่วนประกอบ)
ประการที่สอง Microsoft ละทิ้งโมเดลการเขียนโปรแกรม Window desktop ที่เป็นผู้ใหญ่มาก (Win32 API + ไดรเวอร์ข้อความ/เหตุการณ์) และแนะนำเฟรมเวิร์กการเขียนโปรแกรม WPF ใหม่ หนึ่งในนวัตกรรมที่สำคัญคือการเกิดขึ้นของ XAML (Application Markup Language) ที่สอดคล้องกับข้อกำหนด XML . XAML ใช้ไฟล์ข้อความธรรมดารูปแบบ XML เพื่ออธิบายอินเทอร์เฟซของแอปพลิเคชัน
เราสามารถเปรียบเทียบ XAML กับ XHTML ได้อย่างง่ายดาย เบราว์เซอร์แยกวิเคราะห์โค้ด XHTML และสร้างอินเทอร์เฟซเว็บแบบภาพ ในขณะที่ XAML ถูกแยกวิเคราะห์โดยเครื่องเสมือน .NET Framework ใน Vista เนื่องจาก Vista รวม .NET Framework 3.0 โดยตรง Vista จึงถือเป็นเบราว์เซอร์ขั้นสูง XAML เพื่อสร้างอินเทอร์เฟซผู้ใช้และใช้งานฟังก์ชันแอปพลิเคชันทั้งหมด
เป็นผลให้เกิดรูปแบบการเขียนโปรแกรมใหม่ ไม่ว่าจะเป็นระบบ B/S หรือ C/S วิธีการก็รวมเป็นหนึ่งเดียว: อ่านโค้ด XAML à parse à ปัจจุบัน à รับอินพุตของผู้ใช้ à กระบวนการข้อมูล à แสดงผลลัพธ์
ในรูปแบบการเขียนโปรแกรมนี้ เบราว์เซอร์จะกลายเป็นผู้ยืนดูและไม่ใช่แกนหลักของแอปพลิเคชันไคลเอนต์อีกต่อไป
โมเดลการเขียนโปรแกรมใหม่ทำงานบนระบบปฏิบัติการที่มีคุณสมบัติครบถ้วน แทนที่จะเป็นเบราว์เซอร์ที่มีฟังก์ชันการทำงานจำกัด ความแตกต่างนั้นใหญ่มาก จะเปรียบเทียบฟังก์ชั่นของเบราว์เซอร์ที่ทำงานบน OS กับ OS ได้อย่างไร!
ตอนนี้ระบบปฏิบัติการสามารถเรียกได้อย่างง่ายดายผ่านระบบปฏิบัติการ API (Application Programming Interface) ที่จัดในลักษณะเชิงวัตถุต่างๆ ฟังก์ชั่นเพื่อใช้ทรัพยากรฮาร์ดแวร์ของลูกค้าอย่างเต็มที่ (เช่น คุณสามารถพัฒนาโปรแกรมแบบมัลติเธรดที่อยู่ด้านบนของ .NET Framework ได้อย่างง่ายดาย เพื่อ "บีบ" ความสามารถในการทำงานของ CPU แบบดูอัลคอร์) ส่วนต่อประสานผู้ใช้ทั้งหมดได้รับการอธิบายโดยใช้ XAML ซึ่งรวมเทคโนโลยีชั้นส่วนต่อประสานของ B/S และ C/S เข้าด้วยกัน
สภาพแวดล้อมการทำงานที่เหมาะสมที่สุดสำหรับ WPF คือระบบปฏิบัติการ Vista ชุดย่อยของฟังก์ชันซึ่งปัจจุบันเรียกว่า Silverlight ได้รับการปรับใช้เป็นปลั๊กอินของเบราว์เซอร์ ทำให้โปรแกรม WPF สามารถทำงานในเบราว์เซอร์แบบดั้งเดิมได้ เนื่องจากทั้ง Silverlight และ Vista สามารถแยกวิเคราะห์ XAML ได้ด้วยตนเอง ขณะนี้คุณสามารถใช้ XAML เพื่อเขียนโค้ดอินเทอร์เฟซชุดเดียวเท่านั้น ซึ่งใช้ได้กับทั้ง B/S และ C/S และได้รับประสบการณ์ผู้ใช้แบบเดียวกัน
เนื่องจากข้อบกพร่องโดยธรรมชาติบางประการของ B/S และ AJAX หากระบบ B/S ที่ได้รับการปรับปรุงโดย AJAX เปรียบเทียบกับนักเต้น จริงๆ แล้วมันเป็นนักเต้นที่เต้นด้วยห่วง และแนวคิดของ Microsoft ก็คือ แทนที่จะพยายามลดน้ำหนักอยู่ตลอดเวลา ของกุญแจมือนี้ ทำไมไม่ละทิ้งกุญแจมือนี้ไปล่ะ
การเปิดตัว WPF และ WCF ของ Microsoft ถือเป็นความพยายามเช่นนี้
ควรกล่าวว่ากลยุทธ์การพัฒนาของ Microsoft ขึ้นอยู่กับการวิเคราะห์ข้อดีและข้อเสียของ B/S และ C/S ที่มีอยู่ โดยมีลักษณะทางวิทยาศาสตร์และคำนึงถึงผลประโยชน์ทางธุรกิจของตนเองด้วย อย่างไรก็ตาม ยังมีความยากลำบากมากมายในการเข้าใจกลยุทธ์นี้ เนื่องจากแม้จะทรงพลังเท่ากับ Microsoft แต่ก็ไม่สามารถครองโลกได้ คู่แข่งของ Microsoft ก็ฉลาดพอๆ กับ Microsoft และเทคโนโลยีของพวกเขาก็ก้าวหน้าอย่างรวดเร็วเช่นกัน
สรุปได้ว่าเนื่องจากความต่อเนื่องของการใช้งานระบบสารสนเทศ B/S และ C/S จะอยู่ร่วมกันเป็นระยะเวลานาน (อาจจะสามถึงห้าปี หรืออาจจะห้าถึงสิบปี) เนื่องจากมี B/S คุณสมบัติที่โดดเด่นมากมายจะเหนือกว่าในการแข่งขันกับ C/S และสถานการณ์นี้จะไม่เปลี่ยนแปลงอย่างมีนัยสำคัญ สำหรับ AJAX ในฐานะอาวุธหนักในระบบ B/S แม้ว่าจะมีประสิทธิภาพมาก แต่ก็มีข้อบกพร่องมากมาย ฉันมองโลกในแง่ดีด้วยความระมัดระวังเกี่ยวกับการพัฒนาในอนาคต อย่างไรก็ตาม ในฐานะนักพัฒนาเว็บ คุณควรเข้าใจและประยุกต์ใช้เทคโนโลยีนี้
ภูมิทัศน์ในอนาคตจะเป็นอย่างไร และเทคโนโลยีบางอย่างจะมีอนาคตหรือไม่นั้น ไม่ได้ขึ้นอยู่กับการตัดสินใจของแต่ละบุคคล ฉันคิดว่ารูปแบบสุดท้ายของการต่อสู้ระหว่าง B/S และ C/S จะเป็นผลมาจากเกมร่วมกันระหว่างหลายปัจจัย สำหรับบุคคลทั่วไป พวกเขาจะต้องก้าวให้ทันเวลาและปรับการกระทำและกลยุทธ์ให้ทันเวลา นี่คือชะตากรรมของนักพัฒนาซอฟต์แวร์ร่วมสมัย