ไวยากรณ์ของ Razor มีข้อได้เปรียบที่น่าสนใจในมาร์กอัป UI หรือไม่


88

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

เป็นรูปแบบที่ค่อนข้างไม่คุ้นเคยสำหรับคนที่คุ้นเคยกับมาร์กอัป ASP.Net ประเภท "มาตรฐาน" (ตัวยึดตำแหน่งเนื้อหาและโค้ดอินไลน์) แต่รู้สึกเหมือนมีหน้าเพิ่มเติมจำนวนมากในการจัดการและมาร์กอัปที่ชัดเจนสำหรับฉัน

ความรู้สึกของคนอื่น ๆ เกี่ยวกับเรื่องนี้คืออะไร? เป็นสิ่งที่คุณเชื่อว่าควรได้รับการพิจารณาอย่างจริงจังเมื่อทำการนั่งร้านหน้า MVC ใหม่หรือเพียงแค่พยายามแก้ปัญหาที่ไม่มีอยู่จริง?


3
ที่จริงฉันคิดว่าไวยากรณ์เป็นเรื่องง่ายสำหรับคนที่คุ้นเคยกับเอนจินมุมมองปกติ คุณแค่ใช้ @ แทน <% และอย่าปิดนักเก็ตโค้ดของคุณ ...
Jaco Pretorius

คุณสามารถลองใช้ตัวแปลงนี้ สำหรับข้อมูลเพิ่มเติมตรวจสอบโพสต์บล็อกนี้
George K

คำตอบ:


153

[Disclaimer: ฉันเป็นหนึ่งในนักพัฒนาของ Microsoft ใน MVC และ Razor ดังนั้นฉันอาจจะเอนเอียงไปบ้าง :)]

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

ตัวอย่างเช่นข้อมูลโค้ดต่อไปนี้ในไวยากรณ์ ASPX:

<% if(someCondition) { %>
  <ol>
  <% foreach(var item in Model) { %>
     <li><%: item.ToString() %></li>
  <% } %>
  </ol>
<% } %>

สามารถแสดงได้ดังนี้ใน Razor:

@if(someCondition) {
   <ol>
   @foreach(var item in Model) {
      <li>@item.ToString()</li>
   }
   </ol>
}

ในขณะที่เวอร์ชัน ASPX มีอักขระการเปลี่ยนแปลง 21 ตัว ( <%และ%>) เวอร์ชัน Razor มีเพียงสามตัว (@ )

ฉันจะบอกว่าข้อดีของ Razor มีดังนี้:

  1. ไวยากรณ์ที่กระชับซึ่งคล้ายกับวิธีที่คุณเขียนโค้ด C # ปกติมาก (ดูบล็อกโพสต์ล่าสุดโดย Phil Haack เปรียบเทียบ Asxp กับไวยากรณ์ Razor: http://haacked.com/archive/2011/01/06/razor- ไวยากรณ์ด่วน reference.aspx )
  2. การเข้ารหัส HTML อัตโนมัติของเอาต์พุต (ซึ่งช่วยปกป้องคุณจากการโจมตีด้วยการฉีด html)
  3. การตรวจสอบมาร์กอัปของคุณในตัว (แม้ว่าจะไม่ใช่ 100%) ซึ่งช่วยให้คุณหลีกเลี่ยงแท็กที่ไม่สมดุล

แนวคิดที่เกี่ยวข้องกับเพจยังสามารถจับคู่สิ่งที่คุณมีใน ASPX ได้อย่างง่ายดาย

  • อย่างที่คุณเห็นรหัสแบบอินไลน์ยังคงได้รับอนุญาต
  • ส่วน (ซึ่งสามารถเลือกได้) เทียบเท่ากับตัวยึดเนื้อหา
  • หน้าเค้าโครงแทนหน้าต้นแบบ
  • แนวคิดของมุมมองแบบเต็มและบางส่วนเหมือนกัน
  • @functions { ... } บล็อกแทน <script runat="server"> ... </script>

นอกจากนี้ Razor ยังมีแนวคิดที่มีประโยชน์มากมายที่ฉันอยากจะบอกว่าดีกว่าสิ่งที่มีอยู่ใน ASPX:

  • @helper ฟังก์ชันสำหรับการสร้างฟังก์ชันที่ปล่อยมาร์กอัปได้อย่างง่ายดาย
  • @modelคีย์เวิร์ดสำหรับระบุประเภทโมเดลมุมมองของคุณโดยไม่ต้องเขียน<%@ Page ...คำสั่งด้วยชื่อคลาสเต็ม

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

แน่นอนว่าไม่ใช่ทุกคนที่จะชอบไวยากรณ์ซึ่งเป็นเหตุผลว่าทำไมเราจึงสนับสนุนเอ็นจิ้นมุมมอง ASPX อย่างเต็มที่ นอกจากนี้คุณสามารถตรวจสอบ Spark และ NHaml ซึ่งเป็นเอ็นจิ้นมุมมองบุคคลที่สามสองตัวที่เพลิดเพลินกับชุมชนสำคัญที่ติดตาม บล็อกโพสต์ต่อไปนี้มีการเปรียบเทียบข้อเสนอต่างๆที่ดี: http://blogs.msdn.com/b/coding4fun/archive/2010/10/04/10070953.aspx


@marcind นอกประเด็นโดยสิ้นเชิง แต่มีแนวคิดในการ relaxedUrlToFileSystemMappingทำงานกับหน้าเว็บใหม่อย่างไร แม้ว่าสิ่งนี้จะทำงานได้ดีใน MVC 2.0 แต่การมี"url ใน MVC 3.0 จะแสดงอักขระที่ผิดกฎหมายในข้อยกเว้นของเส้นทางเสมอ
Darin Dimitrov

7
ขอบคุณสำหรับคำตอบที่ชัดเจนและละเอียดถี่ถ้วน สิ่งนี้เปลี่ยนความคิดเห็นของฉันมากพอที่จะให้ Razor ยิงได้ดี
Phil.Wheeler

2
Aaron คุณสามารถผสมและจับคู่ Razor และ Aspx เข้าด้วยกันได้ดังนั้นหากคุณต้องการที่จะแปลงโปรเจ็กต์ของคุณทีละเพจ (ข้อเสียเพียงอย่างเดียวคือคุณจะต้องทำสำเนาหน้าต้นแบบของคุณในรูปแบบ Razor เนื่องจากการมีมุมมอง Razor ใช้ ไม่รองรับหน้าต้นแบบ aspx)
marcind

1
คุณใส่เครื่องหมาย @ ใน HTML ของคุณได้อย่างไร? เช่น<a href="mailto:john@aol.com">?
Chris S

6
ในการอัปเดตโพสต์นี้ฉันใช้ Razor ในช่วงสามหรือสี่เดือนที่ผ่านมาและตอนนี้เริ่มคุ้นเคยกับมันแล้วอย่าคิดว่าฉันจะกลับไปใช้มาร์กอัป ASP.Net แบบเดิมได้อย่างสบายใจ
Phil.Wheeler

3

โดยส่วนตัวแล้วฉันรู้สึกขอบคุณมากที่ลดจำนวนอักขระหนีที่ใช้ การใช้งาน<% %>จะน่าเบื่อมากเมื่อเทียบกับ@{}และไม่น่าดึงดูดใจเท่าที่ควร

ยิ่งไปกว่านั้นการเขียนคำจำกัดความทั้งหมดสำหรับ codebehind และ page จะง่ายขึ้นเป็น single @model modelหน้าจะง่ายไปเพียงครั้งเดียว

ตามที่ระบุไว้โดย marcind ไม่จำเป็นต้องรวมเสมอไป runat=serverก็ดีเช่นกัน

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

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