Apakah Razor atau XSLT lebih baik untuk proyek saya? [Tutup]

Saya dalam tahap awal dalam desain sistem yang pada dasarnya akan dibagi menjadi dua bagian. Satu bagian adalah layanan dan yang lainnya adalah antarmuka dengan layanan yang menyediakan data melalui sesuatu seperti OData atau XML. Aplikasi akan didasarkan pada pola arsitektur MVC. Untuk tampilan, kami mempertimbangkan untuk menggunakan XSLT atau Razor di dalam ASP.NET.

XSLT atau Razor akan membantu memberikan pemisahan kekhawatiran di mana XML atau respons asli mewakili model Anda, XSLT atau 'Razor view' mewakili pandangan Anda. Saya akan meninggalkan controller untuk contoh ini. Proposal desain awal merekomendasikan XSLT, namun saya menyarankan penggunaan Razor sebagai tampilan engine yang lebih ramah.

Ini adalah alasan yang saya sarankan untuk Razor (C #):

• Lebih mudah untuk bekerja dengan dan membangun halaman yang lebih rumit.
• Dapat dengan mudah menghasilkan output non-* ML, mis. Csv, txt, fdf
• Template verbose lebih sedikit
• Model tampilan sangat diketik, di mana XSLT perlu mengandalkan konvensi, misalnya nilai boolean atau tanggal
• Markup lebih mudah didekati, misalnya nbsp, normalisasi baris baru, normalisasi nilai attibute, aturan spasi putih
• Built in HTML helper dapat menghasilkan kode validasi JS berdasarkan atribut DTO
• Pembantu HTML bawaan dapat menghasilkan tautan ke tindakan

Dan argumen untuk XSLT atas pisau cukur adalah:

• XSLT adalah standar dan masih akan ada bertahun-tahun ke depan.
• Sulit untuk secara tidak sengaja memindahkan logika ke tampilan
• Easer untuk bukan programmer (yang saya tidak setuju).
• Sudah berhasil di beberapa proyek kami di masa lalu.
• Nilai data dikodekan-HTML secara default
• Selalu terbentuk dengan baik

Jadi saya mencari agenda di kedua sisi, rekomendasi atau pengalaman apa pun yang membuat pilihan serupa?

Saya TELAH berhasil menggunakan XSLT sebagai tingkat presentasi web ... pada tahun 1999. Dalam 12 tahun terakhir, banyak pilihan yang lebih baik telah muncul. Bantulah diri Anda sendiri, dan gunakan Razor. Itu adalah suatu kesenangan.

Berikut ini adalah perbandingan sintaksis dasar

Pisau cukur

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

Sumber data untuk dua contoh

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"
    }
};

Apakah ada hubungan 1: 1 antara halaman HTML dan output XML? Pertimbangkan kasus-kasus berikut:

• Korelasi yang kuat: setiap halaman web memiliki HTML dan formulir XML yang sesuai.

Contoh: Anda meng-hosting situs web dengan ulasan film. Anda memiliki beranda dengan ulasan terbaru, satu halaman per ulasan dan halaman dengan komentar dan peringkat tamu. Tidak ada pendaftaran apa pun. Anda ingin membuatnya mudah untuk menggunakan situs web Anda secara terprogram tanpa parsing HTML yang jelek. Dalam hal ini, Anda dapat memiliki hubungan 1: 1: semua manusia dapat melakukannya, bot juga dapat melakukannya: dengan permintaan yang sama, mereka akan mendapatkan konten yang sama.

http://example.com/Movie/View/12345/The%20Adjustment%20Bureau digunakan oleh manusia.
http://example.com/Movie/View/12345/The%20Adjustment%20Bureau?xml digunakan oleh bot untuk mengakses informasi yang sama.

• Lemah atau tidak ada korelasi: hanya ada banyak layanan web di satu sisi, dan banyak halaman web di sisi lain.

Contoh: Anda adalah pencipta Facebook lain. Ada situs web, dan ada API. Satu-satunya titik umum adalah bahwa database yang sama digunakan, tetapi bot tidak dapat mengakses apa yang orang bisa, dan informasinya disajikan secara berbeda.

http://example.com/MyFriends/ menunjukkan sepuluh teman teratas yang saya miliki di akun saya. Dengan mengklik "Lainnya", permintaan AJAX dibuat, menunjukkan teman lain.
http://api.example.com/friends?user=MainMa&key=1DE051C6F&xml menunjukkan XML terkait dengan semua teman yang saya miliki.

Anda dapat melihat bahwa:

• API di-host secara terpisah, di server yang berbeda,
• Hubungan antara halaman dan API sulit dilihat.
• Situs web perlu menggunakan sesi untuk melacak login. API hanya perlu kunci yang dihasilkan untuk dikirim pada setiap permintaan.
• Jumlah permintaannya tidak sama. Dalam satu kasus, Anda harus menanyakan halaman, lalu melakukan permintaan AJAX untuk mendapatkan teman-teman Anda yang lain. Dalam kasus lain, Anda mendapatkan seluruh daftar sekaligus.
• Informasi yang dikembalikan tidak sama. Sebagai manusia, Anda mengidentifikasi teman-teman Anda dengan nama mereka. Bot yang menggunakan API akan mengidentifikasi mereka dengan pengenal unik mereka yang mungkin tidak pernah Anda lihat di situs web.

Saya sarankan memilih XSLT hanya jika Anda dekat dengan hubungan 1: 1 . Dalam hal ini, itu akan menyederhanakan pendekatan: aplikasi akan memancarkan XML setiap waktu, tetapi kadang-kadang mengubahnya dengan XSLT untuk browser.

Jika Anda tidak memiliki hubungan ini, saya tidak melihat manfaat XSLT dibandingkan Razor. Ini memberikan pemisahan kekhawatiran yang diberikan Razor juga. Ini memungkinkan Anda untuk memodifikasi HTML tanpa perlu mengkompilasi ulang situs web, yang memungkinkan Razor juga.

Adapun manfaat yang Anda cantumkan:

XSLT adalah standar dan masih akan ada bertahun-tahun ke depan

Apakah Anda berencana membuat aplikasi yang akan hidup untuk waktu yang sangat lama? Razor memiliki peluang untuk digunakan dalam empat tahun, atau setidaknya didukung. Umur kebanyakan aplikasi kurang dari empat tahun, jadi ...

Easer untuk bukan programmer (sesuatu yang bisa saya pertahankan).

Tunggu apa?! Bahkan programmer menemukan bahwa XSLT menyebalkan, sulit dimengerti dan digunakan. Dan ketika saya berbicara dengan non-programmer tentang XML (bahkan tidak dekat dengan XSLT), mereka menangis dan lari.

Sudah berhasil di beberapa proyek kami di masa lalu.

Jika tim Anda tidak pernah menggunakan Razor sebelumnya, maka pertimbangkan waktu yang diperlukan untuk mempelajarinya.

Jika tim Anda menggunakannya, tetapi proyek-proyek itu gagal, pertimbangkan untuk menganalisis mengapa itu gagal dan apakah itu karena Razor, dan apa yang dapat Anda lakukan untuk menghindari kegagalan seperti itu dalam proyek-proyek mendatang.

Rekomendasi saya adalah Razor dan alasan utamanya adalah bahwa ini jauh lebih mudah untuk dikerjakan (daripada XSLT, dan berlawanan dengan argumen Anda yang disebutkan dalam mendukung XSLT, meskipun, Anda ada di pihak saya). Saya memiliki pengalaman bekerja dengan keduanya dan Razor menjadi sangat kuat dalam pernyataan bersyarat, pembantu deklaratif (fungsi di kepala sekolah), percabangan, pengulangan, dll.

Lagi pula, jangan lupa Razor adalah bahasa pemrograman (ya, mesin template, atau mesin tampilan, tetapi diimplementasikan melalui bahasa pemrograman seperti C # atau VB.NET), sedangkan XSLT lebih memiliki struktur markup.

Saya pikir skenario Anda seperti mencoba memilih C # atau T-SQL untuk menulis aplikasi bisnis yang kompleks. Sementara T-SQL cukup kuat dalam operasi yang ditetapkan, itu hanya rusak ketika Anda mencoba menerapkan logika (jika ada, beralih, untuk, dll) di dalamnya.

Anda tidak harus memilih, Anda dapat menggunakan keduanya. Di ASP.NET MVC Anda dapat menggunakan beberapa mesin tampilan sekaligus. Dalam proyek ini saya sedang mengerjakan Saya menggunakan XSLT untuk tampilan hanya baca dan Razor untuk formulir. Anda juga dapat menggunakan XSLT dengan tata letak Razor atau Razor dengan tata letak XSLT. Saya menggunakan tata letak XSLT, jadi saya hanya menggunakan tata letak Razor yang memanggil tata letak XSLT dan melewati bagian HTML sebagai parameter:

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

... dan di dalam htmlRaw.xslkamu cukup gunakan disable-output-escaping="yes":

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

Lihat Menggunakan Razor dan XSLT dalam proyek yang sama .

Saya akan menyarankan ada cara ketiga dan lebih baik: menempatkan dua ujung depan tipis yang berbeda di atas lapisan layanan / aplikasi tunggal yang tidak memiliki UI seperti itu.

Jadi, bukannya

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

menggunakan

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

dan memastikan bahwa UI dan Layanan berisi HANYA kode yang unik untuk antarmuka itu. (permintaan maaf untuk diagram ASCII, terbaik yang bisa saya lakukan sekarang)

Alasan saya khawatir tentang salah satu desain yang Anda diskusikan adalah bahwa ia mengikat pengembangan antarmuka pengguna dengan pengembangan layanan, yang jarang bagaimana Anda ingin bekerja. Jika bisnis ingin menambahkan fungsionalitas ke antarmuka pengguna, Anda tidak ingin dipaksa untuk menulis layanan itu sebelum Anda bisa melakukannya. Anda ingin menulis bagian antarmuka pengguna dan kemudian, dengan asumsi itu diperlukan dalam layanan, gunakan kembali kode di sana.

Lebih buruk lagi, jika bisnis ingin menampilkan data yang sangat berbeda kepada pengguna akhir dari bagaimana disajikan kepada pengguna mekanis melalui layanan (yang tampaknya sangat mungkin), Anda harus mulai memasukkan kode kompleks ke XSLT, atau membangun lapisan layanan kedua (atau lebih buruk, pengendali gemuk) di atas layanan Anda untuk mewakili presentasi kepada pengguna.

Pikirkan tentang validasi dalam kasus ini. Anda berpotensi menarik tiga tingkat kepercayaan. Model Anda akan memerlukan validasi untuk memastikan Anda tidak menyimpan data yang tidak valid; maka layanan Anda mungkin memerlukan beberapa validasi lagi, untuk memastikan bahwa konsumen eksternal tidak mencoba melakukan sesuatu yang mereka tidak boleh lakukan; dan UI Anda akan memerlukan beberapa aturan validasi, paling baik agar dapat menghindari postback.

Dan ini bahkan sebelum kita menyentuh situasi lengket dari sesuatu yang seharusnya tidak diizinkan melalui API tetapi harus diizinkan melalui UI, yang membutuhkan API.

Saya telah mendengar argumen bahwa menjalankan UI Anda melalui layanan Anda adalah dogfooding dan dengan demikian baik untuk kualitas layanan, tetapi saya sangat menyarankan ada cara yang lebih baik untuk melakukan itu sambil menjaga pemisahan yang solid (dan PADAT) keprihatinan antara layanan, UI dan model bisnis.

Semua ini mengatakan, jika Anda harus pergi cara membungkus layanan Anda dengan UI, saya akan sangat menyarankan Razor over XSLT.

XSLT adalah standar, ya. Tapi XSLT 2.0 masih memiliki dukungan terbatas, jadi Anda terjebak dengan standar yang ketinggalan jaman jika Anda ingin membuat argumen itu.

XSLT tidak mudah dibaca. Oleh siapa pun yang bukan pakar XSLT. Menurut Anda siapa yang lebih mudah ditemukan, ketika Anda perlu merekrut staf baru? Seseorang yang mengaku sebagai pakar XSLT atau ASP.NET untuk pakar MVC?

Dan ya, saya telah melihat XSLT berhasil digunakan, tetapi hanya sebelum MVC untuk ASP.NET merupakan pilihan.