ASP.NET MVC View Engine Karşılaştırması


339

ASP.NET MVC için mevcut çeşitli View Engine'lerin dökümü için SO & Google'da arama yaptım, ancak bir görünüm motorunun ne olduğuna ilişkin basit üst düzey açıklamalardan çok daha fazlasını bulamadım.

Ben mutlaka "en iyi" veya "en hızlı" değil, bazı durumlarda büyük oyuncuların avantajları / dezavantajları (örneğin varsayılan WebFormViewEngine, MvcContrib View Engines, vb.) Bazı gerçek dünya karşılaştırmaları arıyorum. Bunun, varsayılan motordan geçişin belirli bir proje veya geliştirme grubu için avantajlı olup olmayacağını belirlemede gerçekten yararlı olacağını düşünüyorum.

Böyle bir karşılaştırma ile karşılaşan var mı?


43
"Yapıcı değil" i ancak yaklaşık 45 bin kez izleyenlere çok değer kattı. SO'nun toplumun ihtiyaçlarına rağmen kendi faydalarını kısıtlaması çok kötü. @ Jeff-atwood'un böyle hissedeceğinden şüpheliyim.
mckamey

Yanıtlar:


430

ASP.NET MVC Görünüm Motorları (Topluluk Wiki)

Kapsamlı bir liste mevcut olmadığından, burada SO'da bir liste başlayalım. İnsanlar deneyimlerini eklerse, ASP.NET MVC topluluğuna büyük değer verebilir (özellikle bunlardan birine katkıda bulunan herkes). Uygulayan her şey IViewEngine(örneğin VirtualPathProviderViewEngine) burada adil bir oyundur. Yeni View Engine'leri alfabetikleştirin (WebFormViewEngine ve Razor'ı en üstte bırakarak) ve karşılaştırmalarda objektif olmaya çalışın.


System.Web.Mvc.WebFormViewEngine

Tasarım Hedefleri:

Yanıt için bir Web Formları sayfası oluşturmak için kullanılan bir görünüm motoru.

Artıları:

  • ASP.NET MVC ile birlikte geldiği için her yerde bulunur
  • ASP.NET geliştiricileri için tanıdık deneyim
  • İyileştirmek
  • CodeDom sağlayıcısı ile herhangi bir dili seçebilir (örn. C #, VB.NET, F #, Boo, Nemerle)
  • isteğe bağlı derleme veya önceden derlenmiş görünümler

Eksileri:

  • MVC'de artık geçerli olmayan "klasik ASP.NET" örüntülerinin kullanımıyla karıştırılır (ör. ViewState PostBack)
  • "etiket çorbası" anti-desen katkıda bulunabilir
  • kod bloğu sözdizimi ve güçlü yazım engel olabilir
  • IntelliSense, satır içi kod blokları için her zaman uygun olmayan stili zorlar
  • basit şablonlar tasarlanırken gürültülü olabilir

Misal:

<%@ 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

Tasarım Hedefleri:

Artıları:

  • Kompakt, Etkileyici ve Sıvı
  • Öğrenmesi kolay
  • Yeni bir dil değil
  • Harika Intellisense
  • Birim Test Edilebilir
  • Her yerde, ASP.NET MVC ile birlikte gelir

Eksileri:

  • Yukarıda belirtilen "tag soup" den biraz farklı bir sorun oluşturur. Sunucu etiketlerinin aslında sunucu ve sunucu olmayan kod etrafında yapı sağladığı durumlarda, Razor HTML ve sunucu kodunu karıştırır ve HTML ve / veya JavaScript'ten "kaçmak" zorunda kaldığınızda saf HTML veya JS geliştirmeyi zorlaştırır (bkz. Örnek 1)). bazı çok yaygın koşullar altında etiketler.
  • Kötü kapsülleme + tekrar kullanılabilirlik: Bir tıraş makinesi şablonunu normal bir yöntemmiş gibi çağırmak pratik değildir - pratikte tıraş makinesi kodu arayabilir ancak kodun ve sunumun karıştırılmasını teşvik edebilecek şekilde tam tersi olamaz.
  • Sözdizimi çok html odaklı; HTML olmayan içerik oluşturmak zor olabilir. Buna rağmen, tıraş makinesinin veri modeli temelde sadece dize birleşimidir, bu nedenle sözdizimi ve yuvalama hataları ne statik ne de dinamik olarak algılanmaz, ancak VS.NET tasarım zamanı bunu biraz hafifletir. Sürdürülebilirlik ve yeniden düzenlenebilirlik bundan dolayı zarar görebilir.
  • Dokümante edilmiş API yok , http://msdn.microsoft.com/en-us/library/system.web.razor.aspx

Con Örnek # 1 ("string [] ..." yerleşiminin olduğuna dikkat edin):

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

Bellevue

Tasarım hedefleri:

  • HTML'ye "sadece metin" olarak davranmanın aksine birinci sınıf dil olarak saygı gösterin.
  • HTML ile uğraşma! Veri bağlama kodu (Bellevue kodu) HTML'den ayrı olmalıdır.
  • Sıkı Model-Görünüm ayrımını zorunlu kılın

Brail

Tasarım Hedefleri:

Brail görünüm motoru, Microsoft ASP.NET MVC Framework ile çalışmak üzere MonoRail'den taşınmıştır. Brail'e giriş için Castle projesi web sitesindeki belgelere bakın .

Artıları:

  • "bilek dostu python sözdiziminden" sonra modellenmiştir
  • İsteğe bağlı derlenmiş görünümler (ancak ön derleme mevcut değildir)

Eksileri:

  • Boo dilinde yazılmak üzere tasarlanmıştır

Misal:

<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, diğer çoğu görüntüleme motoru gibi dizeler yerine VB.NET'in XML değişmezlerini kullanır.

Artıları:

  • Geçerli XML'nin derleme zamanı denetimi
  • Sözdizimi renklendirme
  • Tam fikir
  • Derlenmiş görünümler
  • Düzenli CLR sınıfları, işlevleri vb. Kullanılarak genişletilebilirlik
  • Düzenli VB.NET kodu olduğu için sorunsuz kompoze edilebilirlik ve manipülasyon
  • Birim test edilebilir

Eksileri:

  • Performans: Tüm DOM'u istemciye göndermeden önce oluşturur.

Misal:

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

NDjango

Tasarım Hedefleri:

NDjango, Django Şablon Dilinin .NET platformunda F # dilini kullanan bir uygulamasıdır .

Artıları:


NHaml

Tasarım Hedefleri:

Rails Haml görünüm motorunun .NET portu. Gönderen Haml web :

Haml, satır içi kod kullanmadan herhangi bir web belgesinin XHTML'sini temiz ve basit bir şekilde tanımlamak için kullanılan bir biçimlendirme dilidir ... Haml, XHTML'yi şablona açıkça kodlamaktan kaçınır, çünkü aslında XHTML'nin soyut bir açıklamasıdır , dinamik içerik oluşturmak için bazı kodlarla.

Artıları:

  • kısa yapı (yani KURU)
  • iyi girintili
  • açık yapı
  • C # Intellisense (ReSharper olmadan VS2008 için)

Eksileri:

  • işaretlemenin aşinalıklarından yararlanmak yerine XHTML'den bir soyutlama
  • VS2010 için Intellisense yok

Misal:

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

NVelocityViewEngine (MvcContrib)

Tasarım Hedefleri:

Popüler Java projesi Velocity'nin .NET portu olan NVelocity tabanlı bir görüntüleme motoru .

Artıları:

  • kolay okuma / yazma
  • özlü görünüm kodu

Eksileri:

  • görünümde sınırlı sayıda yardımcı yöntem mevcut
  • Visual Studio entegrasyonuna otomatik olarak sahip değildir (IntelliSense, görünümlerin derleme zamanı kontrolü veya yeniden düzenleme)

Misal:

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

SharpTiles

Tasarım Hedefleri:

SharpTiles kısmi bir liman JSTL arkasındaki kavram ile kombine Fayans çerçeve (Mil taş 1 gibi).

Artıları:

  • Java geliştiricilerine aşina
  • XML tarzı kod blokları

Eksileri:

  • ...

Misal:

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

Spark View Motoru

Tasarım Hedefleri:

Fikir, html'nin akışa ve koda sorunsuz bir şekilde uyması için hakim olmasını sağlamaktır.

Artıları:

  • Daha okunabilir şablonlar üretir
  • C # Intellisense (ReSharper olmadan VS2008 için)
  • VS2010 için SparkSense eklentisi (ReSharper ile çalışır)
  • Görünümlerinizdeki tüm kodlardan kurtulmak için güçlü bir Ciltleme özelliği sağlar ve kendi HTML etiketlerinizi kolayca icat etmenizi sağlar

Eksileri:

  • Şablon mantığının değişmez biçimlendirmeden net olarak ayrılması gerekmez (ad alanı önekleriyle azaltılabilir)

Misal:

<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 Görünüm Motoru MVC

Tasarım Hedefleri:

  • Hafif. Hiçbir sayfa sınıfı oluşturulmadı.
  • Hızlı. Şablonlar Yanıt Çıkışı akışına yazılır.
  • Önbelleğe alınmış. Şablonlar önbelleğe alınır, ancak dosya değişikliklerini algılamak için bir FileSystemWatcher kullanır.
  • Dinamik. Şablonlar kod anında oluşturulabilir.
  • Esnek. Şablonlar herhangi bir seviyeye yerleştirilebilir.
  • MVC ilkeleri doğrultusunda. Kullanıcı arabirimi ve İş Mantığının ayrılmasını destekler. Tüm veriler önceden oluşturulur ve şablona aktarılır.

Artıları:

  • StringTemplate Java geliştiricilerine aşina

Eksileri:


Kanat Vuruşları

Wing Beats, XHTML oluşturmak için dahili bir DSL'dir. F # tabanlıdır ve bir ASP.NET MVC görüntüleme motoru içerir, ancak yalnızca XHTML oluşturma özelliği için de kullanılabilir.

Artıları:

  • Geçerli XML'nin derleme zamanı denetimi
  • Sözdizimi renklendirme
  • Tam fikir
  • Derlenmiş görünümler
  • Düzenli CLR sınıfları, işlevleri vb. Kullanılarak genişletilebilirlik
  • Düzenli F # kodu olduğu için sorunsuz birleştirilebilirlik ve manipülasyon
  • Birim test edilebilir

Eksileri:

  • Gerçekten HTML yazmazsınız, ancak bir DSL'de HTML'yi temsil eden kod yazarsınız.

XsltViewEngine (MvcContrib)

Tasarım Hedefleri:

Tanıdık XSLT'den görünümler oluşturur

Artıları:

  • yaygın olarak her yerde bulunan
  • XML geliştiricileri için tanıdık şablon dili
  • XML tabanlı
  • zaman içinde test
  • Sözdizimi ve öğe yerleştirme hataları statik olarak algılanabilir.

Eksileri:

  • fonksiyonel dil tarzı akış kontrolünü zorlaştırır
  • XSLT 2.0 (muhtemelen?) Desteklenmez. (XSLT 1.0 çok daha az pratiktir).


9
@ BrianLy: F # derlendiğinden ve işlevsel olduğundan, çalışma zamanının geri kalanıyla (en azından c # 4'e kadar) hızlı, daha birlikte çalışabilir ve idempotent olduğu anlamına gelir. ilk başta ironpython rotasına indik, ancak sonuçlardan memnun değildik. adlandırma kadar - biz önerilere açık :)
kolosy

7
Brail'in Eksileri bölümü nedeniyle aşağı oylama. Boo'yı dil olarak kullanmak kesinlikle bir aleyhte değildir.
Owen

48
@Owen: Evet öyle. Buna bir C # geliştiricisi açısından bakmalısınız. Sadece şablon motoru kullanmak için başka bir dil öğrenmek istemezsiniz. (doğal olarak Boo'yu zaten biliyorsanız, bu harika, ancak C # geliştiricilerinin çoğunluğu için, bu üstesinden gelmek için ek bir engeldir)
Christian Klauser

5
Jilet orada. Razor'u alfabetikleştirmek için güncellenmelidir.
mckamey

3
Boo bir profesyonel, Con değil. Zaten "dış" C #, şablon ters daha iyi gelebilir. C # "cazip" bir bağlamda kullanılmaya yönelik değildi, biraz etkileyici ama "bilek dostu" değil. Öte yandan, BOO bunu göz önünde bulundurarak yaratılmıştır ve bu nedenle, cazip bir bağlamda kullanılmasına çok daha iyi borç vermektedir.
Loudenvier

17

Şu anki seçimim Razor. Çok temiz ve okunması kolaydır ve görünüm sayfalarının bakımı çok kolaydır. Gerçekten harika bir akıllı destek de var. ALos, web yardımcılarıyla birlikte kullanıldığında da gerçekten güçlü.

Basit bir örnek sağlamak için:

@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>

İşte buyur. Bu çok temiz ve okunması kolay. Elbette, bu basit bir örnektir, ancak karmaşık sayfalarda ve formlarda bile okumak ve anlamak hala çok kolaydır.

Eksileri gelince? Şimdiye kadar (bunun için yeniyim) formlar için bazı yardımcıları kullanırken biraz sinir bozucu bir CSS sınıfı referansı eklemek için destek eksikliği var.

Teşekkürler Nathj07


1
Doh! Bu tartışmanın kaç yaşında olduğunu fark ettim. Oh, belki birisi onu bulur ve yine de faydalı olur.
nathj07

10

Bunun sorunuza gerçekten cevap vermediğini biliyorum, ancak farklı View Engine'lerin farklı amaçları var. Kıvılcım Görünüm Motor , örneğin, amaçları her şeyin akıcı ve okunabilir hale çalışarak "etiket çorba" görüşlerinizi kurtulmaktır.

En iyi seçeneğiniz sadece bazı uygulamalara bakmak olacaktır. Çözümünüzün amacına çekici geliyorsa, deneyin. MVC'de görüntüleme motorlarını karıştırabilir ve eşleştirebilirsiniz, bu nedenle belirli bir motorla gitmemeye karar verirseniz sorun olmamalıdır.


Cevap için teşekkürler. "Birinin zaten bir özet yapmış olması gerektiğini" düşündüğümde tam olarak önerdiklerinize başlıyordum. Bu tür tasarım hedeflerinin ve eksikliklerinin bir araya gelmesini umuyorum. "Spark View Engine ... her şeyi akıcı ve okunaklı hale getirmeye çalışarak" tag çorbası "ile ilgili görüşlerinizi gidermeyi hedefliyor." Bu, onu oluşturmak için bir nedenin yanı sıra varsayılan görünüm motorunun eksikliğini ima eder. Listede bir kurşun daha var.
mckamey


5

Ben ndjango severim . Kullanımı çok kolay ve çok esnektir. Özel etiketler ve filtrelerle görünüm işlevselliğini kolayca genişletebilirsiniz. Bence "büyük ölçüde F # ile bağlı" dezavantaj daha avantajı olduğunu düşünüyorum.


4

Kullanıcıların her web sitesini ziyaret etmeden her bir lezzeti alabilmeleri için bu listenin her görüntüleme motorunun örneklerini içermesi gerektiğini düşünüyorum.

Resimler bin kelime ve biçimlendirme örneklerinin görünüm motorları için ekran görüntüleri gibi olduğunu söylüyor :) İşte benim favori Spark View Engine'den bir tane

<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>

4
Coldfusion'a çok benziyor. Ben böyle bir biçimlendirme içine kod karıştırma büyük bir hayranı değilim. Bakımı zorlaşır.
Agile Jedi
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.