Projem için Razor veya XSLT daha iyi mi? [kapalı]

Esasen iki parçaya bölünecek bir sistemin tasarımının ilk aşamalarındayım. Bir kısmı bir hizmet, diğeri ise OData veya XML gibi bir şey aracılığıyla veri sağlayan bir arayüz. Uygulama, MVC mimari modeline dayanacaktır. Görünümler için, ASP.NET altında XSLT veya Razor kullanmayı düşünüyoruz.

XSLT veya Razor , orijinal XML veya yanıtın modelinizi, XSLT veya 'Razor görünümü'nün görüşünüzü temsil ettiği endişelerin ayrılmasını sağlamaya yardımcı olur. Bu örnek için denetleyiciyi dışarıda bırakacağım. İlk tasarım önerisi XSLT'yi önerir, ancak Razor'un daha samimi bir görünüm motoru olarak kullanılmasını önerdim.

Razor (C #) için önerdiğim nedenler:

• Daha kolay çalışmak ve daha karmaşık sayfalar oluşturmak.
• Kolayca * ML olmayan çıktılar üretebilir, örn. Csv, txt, fdf
• Daha az ayrıntılı şablonlar
• Görünüm modeli, XSLT'nin boole veya tarih değerleri gibi konvansiyona güvenmesi gereken güçlü bir şekilde yazılmıştır.
• İşaretleme daha erişilebilir, örn. Nbsp, satırsonu normalizasyonu, özenli değer normalizasyonu, boşluk kuralları
• Yerleşik HTML yardımcısı, DTO niteliklerine dayalı JS doğrulama kodu oluşturabilir
• Dahili HTML yardımcısı eylemlere bağlantılar oluşturabilir

Ve XSLT'nin ustura üzerindeki argümanları şunlardı:

• XSLT bir standarttır ve gelecekte uzun yıllar devam edecektir.
• Yanlışlıkla mantığı görünüme taşımak zordur
• Programcı olmayanlar için daha kolay (kabul etmiyorum).
• Geçmiş projelerimizden bazılarında başarılı oldu.
• Veri değerleri varsayılan olarak HTML kodludur
• Her zaman iyi biçimlendirilmiş

Yani her iki tarafta da agresifler, öneriler veya benzer bir seçim yapan herhangi bir deneyim mi arıyorsunuz?

Ben VAR başarıyla geçen 12 yıl içinde 1999 yılında ... Bir web sunum katmanı olarak XSLT kullanılan çok daha iyi seçenekler gelmek var. Kendinize büyük bir iyilik yapın ve Razor kullanın. Bu bir zevk.

Temel bir sözdizimi karşılaştırması

Ustura

@foreach(var item in View.List) {
  <span>@item.Name</span><br/>
}

XSLT

  <xsl:template match="/">
    <xsl:apply-templates/>
  </xsl:template>

  <xsl:template match="item">
    <xsl:for-each select="name">
      <xsl:value-of select="."/><br/>
    </xsl:for-each>
  </xsl:template>

</xsl:stylesheet>

İki örnek için veri kaynakları

XML

<?xml version="1.0" standalone="no"?>
<?xml-stylesheet type="text/xsl" href="transform.xsl"?>
<list>
    <item>
        <name>List item one</name>
        <url>http://site.com/one</url>
    </item>
    <item>
        <name>List item two</name>
        <url>http://site.com/two</url>
    </item>
</list>

C #

ViewModel.List = new[] {
    new Link {
        Name = "List item one",
        Url = "http://site.com/one"
    },
    new Link {
        Name = "List item two",
        Url = "http://site.com/two"
    }
};

HTML sayfaları ile XML çıktısı arasında 1: 1 ilişki var mı? Aşağıdaki durumları düşünün:

• Güçlü korelasyon: her web sayfasının bir HTML'si ve buna karşılık gelen bir XML formu vardır.

Örnek: Film incelemelerine sahip bir web sitesi barındırıyorsunuz. En son yorumları içeren bir ana sayfanız, her inceleme için bir sayfa ve misafir yorumları ve değerlendirmeleri olan bir sayfanız var. Herhangi bir kayıt yok. Çirkin HTML ayrıştırması olmadan web sitenizi programlı olarak kullanmayı kolaylaştırmak istiyorsunuz. Bu durumda, 1: 1 bir ilişkiniz olabilir: tüm insan yapabilir, bot da yapabilir: aynı isteklerle aynı içeriği elde ederler.

http://example.com/Movie/View/12345/The%20Adjustment%20Bureau insanlar tarafından kullanılıyor.
http://example.com/Movie/View/12345/The%20Adjustment%20Bureau?xml , botlar tarafından aynı bilgilere erişmek için kullanılır.

• Zayıf veya korelasyon yok: bir tarafta sadece bir grup web hizmeti, diğer tarafta bir grup web sayfası var.

Örnek: Başka bir Facebook'un yaratıcısısın. Bir web sitesi ve bir API var. Tek ortak nokta, aynı veritabanının kullanılmasıdır, ancak botlar insanların neler yapabileceğine erişemez ve bilgiler farklı şekilde sunulur.

http://example.com/MyFriends/ hesabımda bulunan en iyi on arkadaşımı gösterir. "Diğer" düğmesini tıklatarak, diğer arkadaşları gösteren bir AJAX isteği yapılır.
http://api.example.com/friends?user=MainMa&key=1DE051C6F&xml , sahip olduğum tüm arkadaşlarla ilgili XML'yi gösterir.

Görebilirsin:

• API, ayrı bir sunucuda ayrı olarak barındırılır,
• Sayfalar ve API arasındaki ilişkiyi görmek zor.
• Web sitesi oturumları izlemek için oturumları kullanmalıdır. API'nın her istekte gönderilmesi için yalnızca oluşturulan bir anahtara ihtiyacı vardır.
• İstek sayısı aynı değil. Bir durumda, sayfayı sorgulamanız ve ardından diğer arkadaşlarınızı edinmek için AJAX isteği yapmanız gerekir. Diğer durumda, tüm listeyi bir kerede alırsınız.
• Döndürülen bilgiler aynı değil. İnsan olarak arkadaşlarınızı isimlerine göre tanımlarsınız. API'yı kullanan bir bot, onları web sitesinde asla göremeyeceğiniz benzersiz tanımlayıcılarıyla tanımlar.

XSLT'yi yalnızca 1: 1 ilişkisine yakınsanız seçmenizi öneririz . Bu durumda, yaklaşımı basitleştirecektir: uygulama her seferinde XML yayar, ancak bazen tarayıcılar için XSLT ile dönüştürür.

Bu ilişkiniz yoksa, XSLT'nin Razor'a göre herhangi bir faydası görmüyorum. Razor'ın da sağladığı endişelerin ayrılmasını sağlar. Razor'un da izin verdiği web sitesini yeniden derlemeye gerek kalmadan HTML'yi değiştirmenize izin verir.

Listelediğiniz faydalara gelince:

XSLT bir standarttır ve gelecekte uzun yıllar devam edecektir.

Çok uzun süre yaşayacak bir uygulama yapmayı planlıyor musunuz? Jilet dört yıl içinde kullanılma şansına sahiptir veya en azından desteklenecektir. Çoğu uygulamanın ömrü dört yıldan azdır, bu nedenle ...

Olmayan programcılar için daha kolay (bir şey ile mücadele olabilir).

Bir dakika ne?! Programcılar bile XSLT'nin berbat olduğunu, anlaşılması ve kullanılması zor olduğunu düşünüyor. Ve programcı olmayanlarla XML hakkında (XSLT'ye yakın bile değil) konuştuğumda ağlıyorlar ve kaçıyorlar.

Geçmiş projelerimizden bazılarında başarılı oldu.

Ekibiniz daha önce hiç Razor kullanmadıysa, öğrenmek için gereken zamanı düşünün.

Ekibiniz kullandı, ancak bu projeler başarısız olduysa, neden başarısız olduğunu ve Razor yüzünden olduğunu ve gelecekteki projelerde bu tür başarısızlıkları önlemek için ne yapabileceğinizi analiz etmeyi düşünün.

Benim tavsiyem Razor ve ana nedeni ile çalışmak çok daha kolay (XSLT'den daha çok ve XSLT lehine numaralandırılmış argümanınızın tersi olsa da, benim tarafımdasınız). Her ikisiyle de çalışma deneyimim var ve Razor koşullu ifadelerde, beyan yardımcılarında (temel işlevler), dallanmada, döngüde vb.

Sonuçta, Razor'un bir programlama dili olduğunu (evet, bir şablon motoru veya görünüm motoru, ancak C # veya VB.NET gibi bir programlama dili aracılığıyla uygulandı) unutmayalım, XSLT daha çok bir biçimlendirme yapısına sahip.

Senaryo karmaşık bir iş uygulaması yazmak için C # veya T-SQL seçmek gibi olduğunu düşünüyorum. T-SQL set işlemlerinde oldukça güçlü olsa da, içine mantık (if-else, switch, for vb.) Uygulamaya çalıştığınızda kırılır.

Seçmek zorunda değilsiniz, her ikisini de kullanabilirsiniz. ASP.NET MVC'de aynı anda birden çok görüntüleme motorunu kullanabilirsiniz. Şu anda üzerinde çalıştığım projede salt okunur görünümler için XSLT ve formlar için Razor kullanıyorum. XSLT'yi Jilet düzeniyle veya Jilet'i XSLT düzeniyle de kullanabilirsiniz. XSLT mizanpajını kullanıyorum, bu yüzden sadece XSLT mizanpajını çağıran ve bölümleri HTML olarak parametre olarak geçiren bir Razor mizanpajı kullanıyorum:

@{ 
   Html.RenderPartial("~/Views/shared/htmlRaw.xsl", null, new ViewDataDictionary { 
      { "head", RenderSection("head", required: false) },
      { "content", RenderBody().ToString() }
   });
}

... ve htmlRaw.xslsadece şunları kullanın disable-output-escaping="yes":

<div id="content">
   <xsl:value-of select="$content" disable-output-escaping="yes"/>
</div>

Aynı projede Razor ve XSLT kullanma konusuna bakın .

Üçüncü ve daha iyi bir yol olduğunu öneriyorum: iki farklı ince ön ucu, böyle bir kullanıcı arayüzü olmayan tek bir hizmet / uygulama katmanının üstüne koyun.

Yani, yerine

UI -> converts to and from xml -> Service -> talks to -> Application Layer -> Model

kullanım

UI -> talks to -> Application Layer -> manipulates -> Model
Service ^

ve kullanıcı arayüzünün ve Hizmetin SADECE bu arayüze özgü kod içerdiğinden emin olun. (ASCII diyagramları için özür dilerim, şu anda yapabileceğim en iyi şey)

Tartıştığınız tasarımlardan herhangi biriyle ilgili endişe duymamın nedeni, kullanıcı arayüzünün geliştirilmesini, hizmetin geliştirilmesiyle, nadiren nasıl çalışmak istediğinizle ilişkilendirmesidir. İşletme, kullanıcı arayüzüne bir parça işlevsellik eklemek istiyorsa, bunu yapmadan önce bu hizmeti yazmak zorunda kalmak istemezsiniz. Kullanıcı arabirimi bölümünü yazmak ve sonra da hizmette gerekli olduğunu varsayarak kodu orada yeniden kullanmak istersiniz.

Daha da kötüsü, işletme, son kullanıcıya verileri mekanik bir kullanıcıya hizmet yoluyla nasıl sunulduğundan (farklı görünüyor) çok farklı göstermek istiyorsa, karmaşık kodu XSLT'ye koymaya başlamanız gerekecek veya kullanıcıya sunumu temsil etmek için hizmetinizin üzerine ikinci bir servis katmanı (veya daha kötüsü, yağ kontrolörleri) oluşturun.

Bu durumda doğrulama hakkında düşünün. Potansiyel olarak üç düzeyde güven çekiyorsunuz. Modeliniz, geçersiz verileri saklamadığınızdan emin olmak için doğrulama gerektirecektir; harici tüketicilerin yapmasına izin verilmeyen bir şey yapmaya çalışmadığından emin olmak için hizmetinizin biraz daha doğrulanması gerekebilir; ve kullanıcı arayüzünüzün en iyi şekilde bir geri göndermeyi engelleyebilmesi için bazı doğrulama kurallarına ihtiyacı olacaktır.

Ve bu, API aracılığıyla izin verilmemesi gereken, ancak API gerektiren UI aracılığıyla izin verilmesi gereken bir şeyin yapışkan durumuna bile dokunmadan önce.

Kullanıcı arayüzünüzü hizmetiniz aracılığıyla çalıştırmanın dogfooding olduğu ve bu nedenle hizmetin kalitesi için iyi bir argüman duydum, ancak hizmet arasındaki endişelerin sağlam (ve katı) bir ayrılmasını korurken bunu yapmanın daha iyi yolları olduğunu şiddetle tavsiye ediyorum. kullanıcı arayüzü ve iş modeli.

Tüm bunlar, hizmetinizi bir kullanıcı arayüzü ile sarma yoluna gitmeniz gerekiyorsa, Razor'u XSLT üzerinden şiddetle tavsiye ediyorum dedi.

XSLT bir standarttır, evet. Ancak XSLT 2.0'ın hala sınırlı bir desteği var, bu yüzden bu argümanı yapmak istiyorsanız eski bir standarda bağlı kaldınız.

XSLT'nin okunması kolay değildir. XSLT uzmanı olmayan herkes tarafından. Sizce yeni personel almanız gerektiğinde kimi bulmak daha kolay? Birisi bir XSLT uzmanı mı yoksa MVC uzmanı için ASP.NET mi?

Ve evet, XSLT'nin başarılı bir şekilde kullanıldığını gördüm, ancak ASP.NET için MVC bir seçenek olmadan önce.