ASP.NET Core 2.0 Razor เทียบกับ Angular / React / etc


103

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

ฉันได้รับมอบหมายให้เป็นหัวหน้าสถาปนิกในโครงการดังนั้นฉันกำลังทำการวิจัยเกี่ยวกับกรอบงานเว็บล่าสุด สำหรับแบ็คเอนด์เราได้ทำการทดสอบและตัดสินใจที่จะใช้แพลตฟอร์ม Azure SQL จนถึงตอนนี้ฉันชอบการปรับปรุงที่เกิดขึ้นและกำลังทำกับ ASP.NET ด้วย Core 2.0 โดยเฉพาะ Razor engine มากกว่า ASP.NET MVC เวอร์ชันก่อนหน้า

ฉันต้องการรับความคิดเห็นจากผู้เชี่ยวชาญเกี่ยวกับมีดโกน "ใหม่" เทียบกับ Angular / React และอื่น ๆ ฉันกังวลกับประสิทธิภาพมากขึ้นเป็นพิเศษ Core 2.0 Razor รองรับเฟรมเวิร์กการเรนเดอร์ฝั่งไคลเอ็นต์ได้อย่างไร ความแตกต่างเล็กน้อยหรือไม่? แอปของเราตั้งเป้าไปที่ผู้ใช้ 1,000,000 คน (พร้อมกันประมาณ 100,000 คน)

ขอบคุณล่วงหน้า!


4
ด้วย " มีดโกนใหม่ " คุณหมายถึงหน้า Razor หรือไม่?
Werner

37
สุดท้ายแล้วคุณเลือกอันไหนและมันจะเป็นยังไง?
stt106

5
คุณเริ่มต้น (หรือกำลังทำอะไร) กับโครงการนี้ได้อย่างไร? ตอนนี้ฉันอยู่ในสถานการณ์ที่เกือบจะเหมือนกันกับคุณและอยากจะอัพเดท!
JLo

10
สวัสดี JLo และ stt106 ขออภัยใช้เวลาตอบกลับนานมาก เราลงเอยด้วย Angular front-end และแบ็กเอนด์ ASP.NET Core API โดยใช้ Azure SQL มันได้ผลดีสำหรับเราจนถึงตอนนี้! ฉันคิดว่า React จะแทนที่ Angular ได้หากคุณพอใจกับมันมากขึ้น ฉันต้องเรียนรู้ Angular ซึ่งเป็นการเปลี่ยนแปลงที่ง่ายมากและตอนนี้ฉันก็ชอบมันแล้ว!
TchPowDog

การเปรียบเทียบความเร็วของ ASP.Net Core กับ Angular / React ไม่ตรงประเด็น? อาจมีคำตอบที่เป็นที่ยอมรับได้ สำหรับวันนี้เรามี Core 2.2 และเร็ว ๆ นี้ 3.0
MikroDel

คำตอบ:


75

เราลงเอยด้วยการใช้ Angular front-end และแบ็กเอนด์ ASP.NET Core API โดยใช้ Azure SQL เราทดสอบ Core Razor และแม้ว่าจะดีกว่า Razor รุ่นเก่า แต่ Angular ก็เร็วกว่าสำหรับเรามาก เท่าที่ประสบการณ์ของผู้ใช้ไป Angular (หรือ React) นั้นเหนือกว่ามากในแง่ของประสิทธิภาพ ลักษณะการผูกโมเดลของ Angular ที่เราพบว่าเป็นข้อได้เปรียบที่ยิ่งใหญ่ของการแสดงผลฝั่งเซิร์ฟเวอร์ อย่างไรก็ตามการใช้ Razor (หรือการเรนเดอร์ฝั่งเซิร์ฟเวอร์โดยทั่วไป) จะช่วยเพิ่มความสมบูรณ์โดยรวมที่ดีขึ้นเท่าที่ข้อมูลไปและทำให้การเปลี่ยนแปลงข้อมูลจากส่วนหน้าไปยังส่วนหลังดีขึ้น มีการตัดการเชื่อมต่อระหว่างเฟรมเวิร์กส่วนหน้าและ API อย่างแท้จริง ข้อมูลทั้งหมดที่ส่งผ่านไปยังเซิร์ฟเวอร์จะต้องถูกส่งไปยังอ็อบเจ็กต์ที่พิมพ์ซึ่งหมายความว่าคุณต้องจัดการชุดโมเดล POCO สองชุดแยกกัน สิ่งนี้อาจทำให้เกิดปัญหาหากอ็อบเจ็กต์เซิร์ฟเวอร์และอ็อบเจ็กต์ส่วนหน้าไม่จัดแนว ในขณะนี้ Entity Framework Core ยังไม่สุกมากดังนั้นเราจึงมีปัญหาในการอัปเดตวัตถุการสืบค้นวัตถุรวมถึงวัตถุลูก ฯลฯ

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


6
เท่าที่การรักษาการซิงค์ชุดโมเดล POCO ทั้งสองชุดยังมีส่วนขยายที่มีประโยชน์มากสำหรับ VS ที่สร้างอินเทอร์เฟซเชิงมุมจากรุ่น MVC โปรดดูเครื่องพิมพ์ดีด
Andy Braham

โดยส่วนตัวถ้าฉันต้องใช้ Angular ฉันจะใช้ NoSql สำหรับส่วน DB
Venzentx

2
ฉันนึกภาพไม่ออกว่าเลือกมีดโกน ASP.NET เหนือ Angular ในอดีต ASP.NET ให้รหัสที่คุ้นเคยสำหรับนักพัฒนา. NET แต่ด้วย RAZOR เส้นโค้งการเรียนรู้จะสูงกว่าเมื่อใช้ Angular MVC แยกตรรกะออกจาก HTML
มาร์ค

1
@ มาร์คฉันไม่เชื่ออย่างนั้น Razor Pages นั้นสมบูรณ์แบบโดยเฉพาะอย่างยิ่งวิธีจัดการกับการผูกข้อมูล พวกเขาดีเกินไป แต่แหล่งที่มาสำหรับสถานการณ์เชิงมุมของเขานั้นเหมาะสมอย่างยิ่ง
Mosia Thabo

2
@MosiaThabo มาร์คไม่ได้พูดถึง Razor Pages เขากำลังพูดถึง Razor ซึ่งเป็นสิ่งที่ OP ของฉันอ้างถึง ในโพสต์เดิมของฉันฉันไม่ได้อ้างถึง Razor Pages (หรือตอนนี้เรียกว่า Blazor ฉันคิดว่า) ฉันพูดถึงเฉพาะเกี่ยวกับการแสดงผลฝั่งไคลเอ็นต์เทียบกับการแสดงผลฝั่งเซิร์ฟเวอร์ Razor Pages เป็นรสชาติของ Angular / React ของ Microsoft ซึ่งฉันคิดว่าพวกเขาเห็นว่าจำเป็นเนื่องจากข้อดีที่คุณมีกับ Angular และ React
TchPowDog

50

โดยใช้ Angular / React กับ API ทางฝั่งเซิร์ฟเวอร์:

  • คุณกำจัดกระบวนการสร้าง HTML ในฝั่งเซิร์ฟเวอร์และคุณประหยัด cpu
  • api สร้าง payload ขนาดเล็ก (json) และ Razor (html) ของหลักสูตรจะมีขนาดใหญ่กว่ามากการโหลดซ้ำเต็มหน้าคงที่และการเดินทางกลับหลัง ดังนั้น api และสปาจึงประหยัดแบนด์วิธ
  • api และ spa อาจมีสถานการณ์การกำหนดเวอร์ชันการปรับขนาดและการปรับใช้ที่แตกต่างกัน
  • ด้วยการใช้ api คุณสามารถรองรับแอพมือถือได้เช่นกันและหากคุณเริ่มโดย Razor คุณอาจต้องใช้ api ในอนาคต

แต่ด้วยการใช้ Angular / React คุณควรกังวลเกี่ยวกับลูกค้า:

  • ไคลเอนต์ต้องเปิดใช้งานจาวาสคริปต์
  • ไคลเอนต์ต้องมีเบราว์เซอร์ที่ทันสมัย
  • ไคลเอนต์ต้องมีฮาร์ดแวร์ที่มีประสิทธิภาพเพียงพอ
  • SEO

1
ฉันเข้าใจความแตกต่างของทั้งสองกรอบฉันกังวลกับประสิทธิภาพมากขึ้น
TchPowDog

มี pipline เดียวกันสำหรับทั้งสอง แต่ฉันไม่รู้ว่ามีเกณฑ์มาตรฐานสำหรับหน้ามีดโกน ลิงค์นี้อาจช่วยได้ - ASP.NET Razor Pages vs MVC: Razor Pages พอดีกับ Toolbox ของคุณได้อย่างไร?
Mohsen Esmailpour

1
Razor รองรับมือถือข้อเสียไม่สำคัญกับที่ระบุไว้ ทั้งสองอย่างรวดเร็วในแบบของตัวเอง ฉันชอบ Angular มากกว่า แต่ทั้งสองได้รับการปรับให้เหมาะสม Razor ปรับโค้ดให้เหมาะสมโดยไม่ใช้ทรีเหมือน MVC Angular เป็นฝั่งไคลเอ็นต์ดังนั้นจึงไม่ได้ใช้ต้นไม้จริงๆ แต่ยังปรับข้อมูลใน HTML ให้เหมาะสมด้วย
Nick Turner

@NickTurner ฉันเข้าใจว่ามันไม่ใช่แค่การดูหน้าเว็บบนสมาร์ทโฟนของคุณ แต่เป็นแอปของตัวเองเต็มรูปแบบ เช่นแอป Android ซึ่งสามารถรับข้อมูลจากเซิร์ฟเวอร์ API ที่ไม่มีการเปลี่ยนแปลงตามที่เป็นอยู่ในขณะที่ใช้ฟังก์ชันการทำงานที่ Android มีให้ - รองรับแอนิเมชั่นการแจ้งเตือนข้อความขนมปัง ฯลฯ ที่ดีขึ้น
Raphael Schmitz

24

ฉันไม่มีเกณฑ์มาตรฐาน แต่ฉันมีหลายโครงการที่ใช้ JQuery, Razor, .NET MVC (C #), AJAX ไม่ถึงขนาดที่คุณกำลังจัดการ

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

ฉันยังใช้ Linq2SQL ฉันทำผิดพลาดในการสร้างแบบจำลองสำหรับทุกสิ่งและจากนั้นก็รู้ว่าฉันสามารถส่งคืนชุดผลลัพธ์จากแบบสอบถามของฉันเป็นแบบจำลองได้ duh.

หากคุณใช้. NET MVC และกังวลเกี่ยวกับประสิทธิภาพนี่คือสิ่งที่ฉันพบ:

อย่าส่งคืนมุมมองบางส่วนที่สร้าง HTML จำนวนมาก! อย่าลืมย่อทุกอย่างให้น้อยที่สุด กำจัดพื้นที่สีขาวทั้งหมด ใช้ชื่อ ID ที่เล็กกว่า ใช้เวลาในการสร้าง html ที่เบาที่สุด ส่งคืน JSON และให้ไคลเอ็นต์ทำงานบางอย่าง

ระมัดระวังในการพัฒนา CSS ของคุณ อย่าใช้สไตล์อินไลน์มากมายใช้เวลาในการรวมเข้ากับไฟล์ CSS ซึ่งคุณสามารถย่อขนาดได้ในภายหลัง

เช่นเดียวกันกับ JS ฝั่งไคลเอ็นต์ของคุณ การใส่ JS ไว้ในมุมมองบางส่วนเป็นเรื่องที่น่าสนใจ จัดระเบียบสิ่งต่างๆ

การแสดงผลบน IE นั้นแย่มาก โดยเฉพาะอย่างยิ่งถ้ามีภาพจำนวนมาก อย่าลืมบีบอัดภาพให้มากที่สุดโดยไม่สูญเสียคุณภาพแน่นอน

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.