ASP.NET MVC View Engine (Komunitas Wiki)
Karena daftar yang komprehensif tampaknya tidak ada, mari kita mulai satu di sini di SO. Ini bisa sangat bermanfaat bagi komunitas ASP.NET MVC jika orang menambahkan pengalaman mereka (khususnya siapa saja yang berkontribusi pada salah satunya). Implementasi apa pun IViewEngine(misalnya VirtualPathProviderViewEngine) adalah permainan yang adil di sini. Cukup abjad Lihat Mesin Baru (meninggalkan WebFormViewEngine dan Razor di atas), dan cobalah untuk bersikap objektif dalam perbandingan.
System.Web.Mvc.WebFormViewEngine
Tujuan Desain:
Mesin tampilan yang digunakan untuk merender halaman Formulir Web ke respons.
Pro:
- di mana-mana karena ia dikirimkan bersama ASP.NET MVC
- pengalaman yang biasa bagi pengembang ASP.NET
- IntelliSense
- dapat memilih bahasa apa pun dengan penyedia CodeDom (mis. C #, VB.NET, F #, Boo, Nemerle)
- kompilasi berdasarkan permintaan atau tampilan yang dikompilasi
Cons:
- penggunaan dikacaukan oleh adanya pola "ASP.NET klasik" yang tidak lagi berlaku di MVC (mis. ViewState PostBack)
- dapat berkontribusi pada anti-pola "tag soup"
- sintaksis kode-blok dan pengetikan kuat dapat menghalangi
- IntelliSense memberlakukan gaya yang tidak selalu sesuai untuk blok kode inline
- bisa berisik saat mendesain templat sederhana
Contoh:
<%@ 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
Tujuan Desain:
Pro:
- Kompak, Ekspresif, dan Cairan
- Mudah untuk dipelajari
- Bukan bahasa baru
- Memiliki Intellisense yang luar biasa
- Unit Dapat Diuji
- Di mana-mana, dikirimkan bersama ASP.NET MVC
Cons:
- Menciptakan masalah yang sedikit berbeda dari "tag soup" yang dirujuk di atas. Di mana tag server sebenarnya menyediakan struktur di sekitar kode server dan non-server, Razor membingungkan HTML dan kode server, membuat pengembangan HTML atau JS murni menjadi menantang (lihat Contoh Con # 1) karena Anda akhirnya harus "melarikan diri" HTML dan / atau JavaScript tag dalam kondisi tertentu yang sangat umum.
- Enkapsulasi + reuseability yang buruk: Tidak praktis untuk memanggil template pisau cukur seolah-olah itu adalah metode yang normal - dalam prakteknya pisau cukur dapat memanggil kode tetapi tidak sebaliknya, yang dapat mendorong pencampuran kode dan presentasi.
- Sintaksnya sangat berorientasi pada html; menghasilkan konten non-html bisa rumit. Meskipun demikian, model data pisau cukur pada dasarnya hanya penggabungan string, sehingga kesalahan sintaksis dan bersarang tidak terdeteksi secara statis maupun dinamis, meskipun waktu desain VS.NET membantu mengurangi hal ini. Kemampu-rawatan dan daya tahan dapat menderita karena hal ini.
Tidak ada API yang terdokumentasi , http://msdn.microsoft.com/en-us/library/system.web.razor.aspx
Contoh Con # 1 (perhatikan penempatan "string [] ..."):
@{
<h3>Team Members</h3> string[] teamMembers = {"Matt", "Joanne", "Robert"};
foreach (var person in teamMembers)
{
<p>@person</p>
}
}
Bellevue
Tujuan desain:
- Hormati HTML sebagai bahasa kelas satu dan bukan memperlakukannya sebagai "hanya teks".
- Jangan main-main dengan HTML saya! Kode pengikatan data (kode Bellevue) harus terpisah dari HTML.
- Terapkan pemisahan Model-View yang ketat
Brail
Tujuan Desain:
Mesin tampilan Brail telah diporting dari MonoRail untuk bekerja dengan Microsoft ASP.NET MVC Framework. Untuk pengantar Brail, lihat dokumentasi di situs web proyek Castle .
Pro:
- dimodelkan setelah "sintaksis python ramah-pergelangan tangan"
- Tampilan kompilasi berdasarkan permintaan (tetapi tidak tersedia prakompilasi)
Cons:
- dirancang untuk ditulis dalam bahasa Boo
Contoh:
<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 menggunakan VB.NET's XML literal alih-alih string seperti kebanyakan mesin view lainnya
Pro:
- Pengecekan waktu kompilasi terhadap XML yang valid
- Pewarnaan sintaks
- Intellisense penuh
- Tampilan yang dikompilasi
- Ekstensibilitas menggunakan kelas CLR biasa, fungsi, dll
- Kompabilitas dan manipulasi yang mulus karena merupakan kode VB.NET biasa
- Unit dapat diuji
Cons:
- Kinerja: Membangun seluruh DOM sebelum mengirimnya ke klien.
Contoh:
Protected Overrides Function Body() As XElement
Return _
<body>
<h1>Hello, World</h1>
</body>
End Function
NDjango
Tujuan Desain:
NDjango adalah implementasi
Bahasa Template Django pada platform .NET, menggunakan bahasa F # .
Pro:
NHaml
Tujuan Desain:
.NET port dari Rails Haml view engine. Dari situs web Haml :
Haml adalah bahasa markup yang digunakan untuk membersihkan dan hanya menggambarkan XHTML dari dokumen web apa pun, tanpa menggunakan kode inline ... Haml menghindari perlunya mengode XHTML secara eksplisit ke dalam templat, karena itu sebenarnya merupakan deskripsi abstrak XHTML , dengan beberapa kode untuk menghasilkan konten dinamis.
Pro:
- struktur singkat (yaitu KERING)
- indentasi baik
- struktur yang jelas
- C # Intellisense (untuk VS2008 tanpa ReSharper)
Cons:
- abstraksi dari XHTML daripada meningkatkan keakraban markup
- Tidak ada Intellisense untuk VS2010
Contoh:
@type=IEnumerable<Product>
- if(model.Any())
%ul
- foreach (var p in model)
%li= p.Name
- else
%p No products available
NVelocityViewEngine (MvcContrib)
Tujuan Desain:
Sebuah mesin pandangan berdasarkan
NVelocity yang merupakan pelabuhan NET yang populer proyek Java
Velocity .
Pro:
- mudah dibaca / ditulis
- kode tampilan ringkas
Cons:
- terbatasnya jumlah metode bantuan yang tersedia pada tampilan
- tidak secara otomatis memiliki integrasi Visual Studio (IntelliSense, pemeriksaan waktu kompilasi pandangan, atau refactoring)
Contoh:
#foreach ($p in $viewdata.Model)
#beforeall
<ul>
#each
<li>$p.Name</li>
#afterall
</ul>
#nodata
<p>No products available</p>
#end
SharpTiles
Tujuan Desain:
SharpTiles adalah port parsial JSTL
dikombinasikan dengan konsep di balik kerangka Tiles (pada Mile stone 1).
Pro:
- akrab bagi pengembang Java
- Blok kode gaya XML
Cons:
Contoh:
<c:if test="${not fn:empty(Page.Tiles)}">
<p class="note">
<fmt:message key="page.tilesSupport"/>
</p>
</c:if>
Spark View Engine
Tujuan Desain:
Idenya adalah untuk memungkinkan html mendominasi aliran dan kode agar sesuai dengan mulus.
Pro:
- Menghasilkan lebih banyak templat yang dapat dibaca
- C # Intellisense (untuk VS2008 tanpa ReSharper)
- Plug-in SparkSense untuk VS2010 (bekerja dengan ReSharper)
- Menyediakan fitur Bindings yang kuat untuk menyingkirkan semua kode dalam tampilan Anda dan memungkinkan Anda untuk dengan mudah menemukan tag HTML Anda sendiri
Cons:
- Tidak ada pemisahan yang jelas dari logika template dari markup literal (ini dapat dikurangi dengan awalan namespace)
Contoh:
<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 Lihat Engine MVC
Tujuan Desain:
- Ringan Tidak ada kelas halaman yang dibuat.
- Cepat. Template ditulis ke aliran Output Response.
- Dalam cache Templat di-cache, tetapi gunakan FileSystemWatcher untuk mendeteksi perubahan file.
- Dinamis. Template dapat dihasilkan dengan kode sambil jalan.
- Fleksibel. Template dapat disarangkan ke level apa pun.
- Sejalan dengan prinsip-prinsip MVC. Mempromosikan pemisahan UI dan Logika Bisnis. Semua data dibuat sebelumnya, dan diteruskan ke templat.
Pro:
- akrab bagi pengembang Java StringTemplate
Cons:
- sintaksis template sederhana dapat mengganggu output yang diinginkan (mis. konflik jQuery )
Ketukan sayap
Wing Beats adalah DSL internal untuk membuat XHTML. Ini didasarkan pada F # dan termasuk mesin view ASP.NET MVC, tetapi juga dapat digunakan semata-mata karena kemampuannya menciptakan XHTML.
Pro:
- Pengecekan waktu kompilasi terhadap XML yang valid
- Pewarnaan sintaks
- Intellisense penuh
- Tampilan yang dikompilasi
- Ekstensibilitas menggunakan kelas CLR biasa, fungsi, dll
- Kompabilitas dan manipulasi yang mulus karena merupakan kode F # biasa
- Unit dapat diuji
Cons:
- Anda tidak benar-benar menulis HTML tetapi kode yang mewakili HTML dalam DSL.
XsltViewEngine (MvcContrib)
Tujuan Desain:
Membangun tampilan dari XSLT yang sudah dikenal
Pro:
- secara luas di mana-mana
- bahasa template yang dikenal untuk pengembang XML
- Berbasis XML
- teruji waktu
- Sintaks dan kesalahan elemen bersarang dapat dideteksi secara statis.
Cons:
- gaya bahasa fungsional membuat kontrol aliran menjadi sulit
- XSLT 2.0 tidak (mungkin?) Tidak didukung. (XSLT 1.0 jauh lebih tidak praktis).