เปรียบเทียบ ASP.NET MVC View Engine

339

ฉันได้ค้นหา SO & Google เพื่อดูรายละเอียดของเอ็นจิ้นการดูต่างๆที่มีอยู่สำหรับ ASP.NET MVC แต่ไม่พบคำอธิบายระดับสูงอย่างง่าย ๆ มากกว่าสิ่งที่เอ็นจิ้นการดูเป็น

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

มีใครพบการเปรียบเทียบดังกล่าวหรือไม่?

— McKamey
แหล่งที่มา

43

แดกดันว่ามันเป็น "ไม่สร้างสรรค์" แต่ยังให้คุณค่ากับผู้ที่เกี่ยวข้องที่เคยดูมันเกือบ 45K ครั้ง น่าเสียดายที่ SO กำลัง จำกัด ยูทิลิตี้ของตัวเองแม้จะมีความต้องการของชุมชน ฉันสงสัย @ jeff-atwood จะรู้สึกอย่างนั้น

— mckamey

430

ASP.NET MVC ดูเอนจิ้น (Community Wiki)

เนื่องจากรายการที่ครอบคลุมไม่มีอยู่ให้เริ่มต้นที่นี่บน SO นี่เป็นสิ่งที่มีค่าอย่างยิ่งสำหรับชุมชน ASP.NET MVC ถ้าผู้คนเพิ่มประสบการณ์ของพวกเขา (โดยเฉพาะใครก็ตามที่มีส่วนร่วมในสิ่งเหล่านี้) การดำเนินการใด ๆIViewEngine(เช่นVirtualPathProviderViewEngine) เป็นเกมที่ยุติธรรมที่นี่ เพียงแค่เรียงตามตัวอักษรดูเอ็นจิ้นใหม่ (ทิ้ง WebFormViewEngine และมีดโกนไว้ที่ด้านบน) แล้วลองเปรียบเทียบวัตถุประสงค์

System.Web.Mvc.WebFormViewEngine

เป้าหมายการออกแบบ:

เอ็นจินการดูที่ใช้เพื่อแสดงผลหน้าเว็บฟอร์มเพื่อตอบสนอง

ข้อดี:

แพร่หลายเพราะมาพร้อมกับ ASP.NET MVC
ประสบการณ์ที่คุ้นเคยสำหรับนักพัฒนา ASP.NET
IntelliSense
สามารถเลือกภาษาใด ๆ กับผู้ให้บริการ CodeDom (เช่น C #, VB.NET, F #, Boo, Nemerle)
ตามความต้องการในการรวบรวมหรือการprecompiledมุมมอง

จุดด้อย:

การใช้งานสับสนเนื่องจากการมีอยู่ของรูปแบบ "ASP.NET คลาสสิก" ซึ่งไม่ได้ใช้ใน MVC อีกต่อไป (เช่น ViewState PostBack)
สามารถนำไปสู่การต่อต้านรูปแบบของ "แท็กซุป"
ไวยากรณ์โค้ดบล็อกและการพิมพ์ที่รัดกุมสามารถเข้าถึงได้
IntelliSense บังคับใช้รูปแบบที่ไม่เหมาะสมกับบล็อครหัสแบบอินไลน์เสมอไป
อาจมีเสียงดังเมื่อออกแบบเทมเพลตอย่างง่าย

ตัวอย่าง:

<%@ Control Inherits="System.Web.Mvc.ViewPage<IEnumerable<Product>>" %>
<% if(model.Any()) { %>
<ul>
    <% foreach(var p in model){%>
    <li><%=p.Name%></li>
    <%}%>
</ul>
<%}else{%>
    <p>No products available</p>
<%}%>

System.Web.Razor

เป้าหมายการออกแบบ:

ข้อดี:

Compact, Expressive และ Fluid
ง่ายต่อการเรียนรู้
ไม่ใช่ภาษาใหม่
มี Intellisense ที่ดี
หน่วยทดสอบ
แพร่หลายมาพร้อมกับ ASP.NET MVC

จุดด้อย:

สร้างปัญหาที่แตกต่างจาก "แท็กซุป" ที่อ้างถึงข้างต้น ที่แท็กเซิร์ฟเวอร์จัดเตรียมโครงสร้างรอบ ๆ เซิร์ฟเวอร์และไม่ใช่รหัสเซิร์ฟเวอร์มีดโกนจะสร้างความสับสนให้กับ HTML และรหัสเซิร์ฟเวอร์ทำให้การพัฒนา HTML หรือ JS บริสุทธิ์ท้าทาย (ดูตัวอย่างที่ # 1) ในขณะที่คุณต้อง "หนี" HTML และ / หรือ JavaScript แท็กภายใต้เงื่อนไขทั่วไปบางอย่าง
การห่อหุ้มไม่ดี + การนำกลับมาใช้ซ้ำ: มันไม่สามารถเรียกเทมเพลตมีดโกนราวกับว่าเป็นวิธีปกติ - ในทางปฏิบัติมีดโกนสามารถเรียกรหัสได้ แต่ไม่ใช่ในทางกลับกันซึ่งสามารถกระตุ้นการผสมของรหัสและการนำเสนอ
ไวยากรณ์เป็นเชิง html มาก การสร้างเนื้อหาที่ไม่ใช่ HTML อาจเป็นเรื่องยุ่งยาก อย่างไรก็ตามแบบจำลองข้อมูลของมีดโกนนั้นเป็นเพียงแค่การต่อสตริงดังนั้นข้อผิดพลาดทางไวยากรณ์และการซ้อนจึงไม่ถูกตรวจพบแบบไดนามิกหรือแบบไดนามิกแม้ว่า VS.NET จะช่วยลดเวลาในการออกแบบ การบำรุงรักษาและความสามารถในการนำกลับมาใช้ใหม่สามารถประสบได้เนื่องจากสิ่งนี้
~~ไม่มีเอกสาร API~~ , http://msdn.microsoft.com/en-us/library/system.web.razor.aspx

ตัวอย่างที่ # 1 (สังเกตตำแหน่งของ "string [] ... "):

@{
    <h3>Team Members</h3> string[] teamMembers = {"Matt", "Joanne", "Robert"};
    foreach (var person in teamMembers)
    {
        <p>@person</p>
    }
}

Bellevue

เป้าหมายการออกแบบ:

เคารพ HTML เป็นภาษาชั้นหนึ่งซึ่งตรงข้ามกับการถือเป็น "แค่ข้อความ"

อย่ายุ่งกับ HTML ของฉัน! รหัสการเชื่อมโยงข้อมูล (รหัส Bellevue) ควรแยกจาก HTML

บังคับใช้การแยกโมเดล - มุมมองที่เข้มงวด

Brail

เป้าหมายการออกแบบ:

เอ็นจิ้นการดู Brail ได้รับการพอร์ตจาก MonoRail เพื่อทำงานกับ Microsoft ASP.NET MVC Framework สำหรับการแนะนำให้ Brail โปรดดูเอกสารเกี่ยวกับการที่เว็บไซต์โครงการปราสาท

ข้อดี:

ถ่ายแบบมาจาก "ข้อมือที่เป็นมิตรกับงูหลามซินแท็กซ์"
มุมมองที่คอมไพล์ตามคำขอ (แต่ไม่มีการรวบรวมล่วงหน้า)

จุดด้อย:

ออกแบบมาเพื่อเขียนในภาษาBoo

ตัวอย่าง:

<html>    
<head>        
<title>${title}</title>
</head>    
<body>        
     <p>The following items are in the list:</p>  
     <ul><%for element in list:    output "<li>${element}</li>"%></ul>
     <p>I hope that you would like Brail</p>    
</body>
</html>

Hasic

Hasic ใช้ตัวอักษร XML ของ VB.NET แทนสตริงเช่นเดียวกับเอ็นจิ้นการดูอื่น ๆ

ข้อดี:

การตรวจสอบเวลาแบบคอมไพล์ของ XML ที่ถูกต้อง
ไวยากรณ์สี
Intellisense เต็มรูปแบบ
มุมมองที่รวบรวม
ความสามารถในการขยายโดยใช้คลาส CLR ปกติฟังก์ชั่นและอื่น ๆ
ความต่อเนื่องและการจัดการที่ราบรื่นเนื่องจากเป็นรหัส VB.NET ปกติ
หน่วยทดสอบ

จุดด้อย:

ประสิทธิภาพการทำงาน: สร้าง DOM ทั้งหมดก่อนที่จะส่งไปยังลูกค้า

ตัวอย่าง:

Protected Overrides Function Body() As XElement
    Return _
    <body>
        <h1>Hello, World</h1>
    </body>
End Function

NDjango

เป้าหมายการออกแบบ:

NDjango คือการดำเนินการของ Django แม่แบบภาษาบนแพลตฟอร์ม .NET โดยใช้F # ภาษา

ข้อดี:

NDjango ปล่อย 0.9.1.0 ดูเหมือนว่าจะมีเสถียรภาพมากขึ้นภายใต้ความเครียดมากกว่า WebFormViewEngine
ตัวแก้ไขเทมเพลต Django พร้อมการกำหนดสีไวยากรณ์การทำให้สมบูรณ์ของรหัสและการวินิจฉัยตามประเภท (เฉพาะ VS2010 เท่านั้น)
บูรณาการกับ ASP.NET กรอบ Castle MonoRail และ Bistro MVC

NHaml

เป้าหมายการออกแบบ:

. NET พอร์ตของ Rails Haml view engine จากเว็บไซต์ Haml :

Haml เป็นภาษามาร์กอัปที่ใช้ในการทำความสะอาดและอธิบาย XHTML ของเอกสารเว็บใด ๆ โดยไม่ต้องใช้โค้ดอินไลน์ ... Haml หลีกเลี่ยงความจำเป็นในการเข้ารหัส XHTML ลงในเทมเพลตเพราะจริงๆแล้วมันเป็นคำอธิบายเชิงนามธรรมของ XHTML ด้วยรหัสบางส่วนเพื่อสร้างเนื้อหาแบบไดนามิก

ข้อดี:

โครงสร้างสั้น (เช่น DRY)
เว้าแหว่งดี
โครงสร้างที่ชัดเจน
C # Intellisense (สำหรับ VS2008 ไม่มี ReSharper)

จุดด้อย:

สิ่งที่เป็นนามธรรมจาก XHTML แทนที่จะใช้ประโยชน์จากความคุ้นเคยของมาร์กอัป
ไม่มี Intellisense สำหรับ VS2010

ตัวอย่าง:

@type=IEnumerable<Product>
- if(model.Any())
  %ul
    - foreach (var p in model)
      %li= p.Name
- else
  %p No products available

NVelocityViewEngine (MvcContrib)

เป้าหมายการออกแบบ:

เครื่องยนต์มุมมองขึ้นอยู่กับ NVelocityซึ่งเป็นพอร์ต .NET ที่เป็นที่นิยม Java โครงการ Velocity

ข้อดี:

ง่ายต่อการอ่าน / เขียน
รหัสมุมมองที่กระชับ

จุดด้อย:

วิธีใช้ตัวช่วยมี จำกัด ในมุมมอง
ไม่มีการรวม Visual Studio โดยอัตโนมัติ (IntelliSense การตรวจสอบมุมมองเวลาคอมไพล์หรือการปรับโครงสร้างใหม่)

ตัวอย่าง:

#foreach ($p in $viewdata.Model)
#beforeall
    <ul>
#each
    <li>$p.Name</li>
#afterall
    </ul>
#nodata 
    <p>No products available</p>
#end

SharpTiles

เป้าหมายการออกแบบ:

SharpTiles เป็นพอร์ตบางส่วนของJSTL รวมกับแนวคิดที่อยู่เบื้องหลังเฟรมเวิร์ก Tiles (ตั้งแต่ Mile stone 1)

ข้อดี:

คุ้นเคยกับนักพัฒนา Java
บล็อคโค้ดสไตล์ XML

จุดด้อย:

...

ตัวอย่าง:

<c:if test="${not fn:empty(Page.Tiles)}">
  <p class="note">
    <fmt:message key="page.tilesSupport"/>
  </p>
</c:if>

Spark View Engine

เป้าหมายการออกแบบ:

แนวคิดคือการอนุญาตให้ html ควบคุมการไหลและรหัสให้พอดีได้อย่างลงตัว

ข้อดี:

สร้างเท็มเพลตที่อ่านได้มากขึ้น
C # Intellisense (สำหรับ VS2008 ไม่มี ReSharper)
ปลั๊กอิน SparkSenseสำหรับ VS2010 (ทำงานร่วมกับ ReSharper)
นำเสนอคุณลักษณะการเชื่อมที่มีประสิทธิภาพเพื่อกำจัดรหัสทั้งหมดในมุมมองของคุณและช่วยให้คุณคิดค้นแท็ก HTML ของคุณเองได้อย่างง่ายดาย

จุดด้อย:

ไม่มีการแยกลอจิคัลเทมเพลตที่ชัดเจนจากมาร์กอัปตัวอักษร (สิ่งนี้สามารถลดได้โดยส่วนนำหน้าเนมสเปซ)

ตัวอย่าง:

<viewdata products="IEnumerable[[Product]]"/>
<ul if="products.Any()">
    <li each="var p in products">${p.Name}</li>
</ul>
<else>
    <p>No products available</p>
</else>

<Form style="background-color:olive;">
    <Label For="username" />
    <TextBox For="username" />
    <ValidationMessage For="username" Message="Please type a valid username." />
</Form>

StringTemplate ดู Engine MVC

เป้าหมายการออกแบบ:

มีน้ำหนักเบา ไม่มีการสร้างคลาสหน้า

รวดเร็ว เทมเพลตถูกเขียนไปยังสตรีมเอาต์พุตการตอบกลับ

ที่เก็บไว้ เทมเพลตถูกแคช แต่ใช้ FileSystemWatcher เพื่อตรวจจับการเปลี่ยนแปลงไฟล์

พลวัต แม่แบบสามารถสร้างได้ทันทีในรหัส

คล่องตัว เทมเพลตสามารถซ้อนในระดับใดก็ได้

สอดคล้องกับหลักการ MVC ส่งเสริมการแยก UI และตรรกะทางธุรกิจ ข้อมูลทั้งหมดถูกสร้างล่วงหน้าและส่งผ่านไปยังเทมเพลต

ข้อดี:

คุ้นเคยกับนักพัฒนา StringTemplate Java

จุดด้อย:

ไวยากรณ์เทมเพลตแบบง่ายสามารถรบกวนเอาต์พุตที่ต้องการ (เช่นjQuery ขัดแย้ง )

Wing Beats

Wing Beats เป็น DSL ภายในสำหรับการสร้าง XHTML มันขึ้นอยู่กับ F # และรวมถึงเอ็นจิ้นการดู ASP.NET MVC แต่ยังสามารถใช้สำหรับความสามารถในการสร้าง XHTML เท่านั้น

ข้อดี:

การตรวจสอบเวลาแบบคอมไพล์ของ XML ที่ถูกต้อง
ไวยากรณ์สี
Intellisense เต็มรูปแบบ
มุมมองที่รวบรวม
ความสามารถในการขยายโดยใช้คลาส CLR ปกติฟังก์ชั่นและอื่น ๆ
ความต่อเนื่องและการจัดการที่ราบรื่นเนื่องจากเป็นรหัส F # ปกติ
หน่วยทดสอบ

จุดด้อย:

คุณไม่ได้เขียน HTML จริงๆ แต่เป็นรหัสที่แสดงถึง HTML ใน DSL

XsltViewEngine (MvcContrib)

เป้าหมายการออกแบบ:

สร้างมุมมองจาก XSLT ที่คุ้นเคย

ข้อดี:

แพร่หลายแพร่หลาย
เทมเพลตภาษาที่คุ้นเคยสำหรับนักพัฒนา XML
XML-based
เวลาการทดสอบ
สามารถตรวจพบข้อผิดพลาดทางไวยากรณ์และองค์ประกอบการซ้อน

จุดด้อย:

สไตล์การใช้งานภาษาทำให้การควบคุมการไหลทำได้ยาก
ไม่รองรับ XSLT 2.0 (อาจเป็น?) (XSLT 1.0 เป็นประโยชน์น้อยกว่ามาก)

— mckamey
แหล่งที่มา

9

@ BrianLy: เนื่องจาก F # รวบรวมและใช้งานได้ซึ่งหมายความว่ามันเร็วและทำงานร่วมกันได้มากขึ้นกับส่วนที่เหลือของรันไทม์ (อย่างน้อยจนถึง c # 4) และ idempotent เราลงเส้นทาง ironpython ในตอนแรก แต่ไม่พอใจกับผลลัพธ์ เท่าที่การตั้งชื่อ - เราเปิดให้คำแนะนำ :)

— kolosy

7

ลงคะแนนเนื่องจากส่วนข้อเสียของ Brail การมี Boo เป็นภาษานั้นไม่ใช่การต่อต้าน

— โอเว่น

48

@Owen: ใช่มันเป็น คุณต้องดูสิ่งนี้จากมุมมองของนักพัฒนา C # คุณไม่ต้องการที่จะเรียนรู้ภาษาอื่นเพียงแค่ใช้เครื่องมือสร้างเทมเพลต (โดยธรรมชาติถ้าคุณรู้จัก Boo อยู่แล้วมันยอดเยี่ยม แต่สำหรับนักพัฒนา C # ส่วนใหญ่นี่คืออุปสรรคเพิ่มเติมที่จะเอาชนะ)

— Christian Klauser

5

มีดโกนอยู่ในนั้น ควรอัปเดตเป็นมีดโกนอักษร

— mckamey

3

บูเป็นมืออาชีพไม่ใช่นักสู้ คุณได้ "อยู่นอก" C # แล้วเทมเพลตของเทมเพลตอาจดีขึ้นกว่าเดิม C # ไม่ได้หมายถึงใช้ในบริบท "templating" มันค่อนข้างแสดงออก แต่ไม่ใช่ "มิตรข้อมือ" ในทางกลับกัน BOO ถูกสร้างขึ้นโดยคำนึงถึงสิ่งนี้และทำให้มันยืมตัวเองได้ดีกว่ามากที่จะใช้ในบริบทของการสร้างเทมเพลต

— Loudenvier

17

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

เพื่อให้ตัวอย่างง่าย ๆ :

@Model namespace.model
<!Doctype html>
<html>
<head>
<title>Test Razor</title>
</head>
<body>
<ul class="mainList">
@foreach(var x in ViewData.model)
{
<li>@x.PropertyName</li>
}
</ul>
</body>

และคุณมีมัน นั่นสะอาดมากและอ่านง่าย จริงอยู่ที่นี่เป็นตัวอย่างง่ายๆ แต่แม้ในหน้าเว็บที่ซับซ้อนและรูปแบบก็ยังง่ายต่อการอ่านและทำความเข้าใจ

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

ขอบคุณ Nathj07

— nathj07
แหล่งที่มา

1

Doh! เพิ่งสังเกตว่าการสนทนานี้มีอายุเท่าไหร่ แหมคนอาจจะพบว่ามันจะยังคงมีประโยชน์

— nathj07

10

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

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

— MunkiPhD
แหล่งที่มา

ขอบคุณสำหรับคำตอบ. ฉันเริ่มต้นสิ่งที่คุณแนะนำอย่างแท้จริงเมื่อฉันคิดว่า "มีคนต้องทำสรุปแล้ว" ฉันหวังว่าจะรวมเป้าหมายการออกแบบและข้อบกพร่องบางประเภทเหล่านี้ "The Spark View Engine ... มุ่งกำจัดมุมมองของ" tag soup "โดยพยายามทำให้ทุกอย่างคล่องแคล่วและสามารถอ่านได้" นั่นหมายถึงเหตุผลในการสร้างมันรวมถึงข้อบกพร่องของเอ็นจิ้นการดูเริ่มต้น สัญลักษณ์แสดงหัวข้อย่อยอีกหนึ่งรายการ

— mckamey

7

ตรวจสอบSharpDOMนี้ นี่คือ ac # 4.0 dsl ภายในสำหรับการสร้าง html และ asp.net mvc view engine

— Anton Shelin
แหล่งที่มา

ฟังดูเป็นวิธีที่สมเหตุสมผลในการสร้างมุมมอง

— Stephan Eggermont

คุณสามารถเพิ่มมันลงในคำตอบทั่วไปของวิกิได้หรือไม่

— Mauricio Scheffer

ฉันหามันไม่พบใน CodePlex หรือ Google อีกต่อไป มันหายไปไหน ?? (มันยังอยู่ใน Codeproject: codeproject.com/Articles/667581/ … )

— Jared Thirsk

5

ฉันชอบndjango มันใช้งานง่ายและยืดหยุ่นมาก คุณสามารถขยายฟังก์ชั่นการดูได้อย่างง่ายดายด้วยแท็กและตัวกรองที่กำหนดเอง ฉันคิดว่า "การผูกติดกับ F #" นั้นค่อนข้างได้เปรียบกว่าข้อเสีย

— rdovhan
แหล่งที่มา

4

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

รูปภาพพูดคำพันคำและตัวอย่างมาร์กอัปเป็นหน้าจอสำหรับเครื่องมือดู :) ดังนั้นนี่คือหนึ่งในSpark View Engine ที่ฉันโปรดปราน

<viewdata products="IEnumerable[[Product]]"/>
<ul if="products.Any()">
  <li each="var p in products">${p.Name}</li>
</ul>
<else>
  <p>No products available</p>
</else>

— mythz
แหล่งที่มา

4

ดูเหมือน Coldfusion มากเกินไป ฉันไม่ใช่แฟนตัวยงของการผสมรหัสในมาร์กอัปเช่นนี้ มันยากที่จะรักษา

— Agile Jedi