Jika MVC adalah "Pemisahan Kekhawatiran" maka mengapa Razor Syntax diperkenalkan?

Pertanyaan saya terkait dengan pola desain MVC dan Sintaks Razor yang diperkenalkan oleh Microsoft.

Saat mempelajari pola desain MVC saya diberi tahu bahwa ide tersebut didasarkan pada prinsip yang dikenal sebagai Separation of Concerns .

Tapi Razor Syntax memungkinkan kita untuk menggunakan C # dalam Views secara langsung.

Bukankah ini persimpangan keprihatinan?

Anda menggabungkan sintaks Razor dengan pemisahan kekhawatiran.

Pemisahan masalah berkaitan dengan bagaimana Anda menyusun kode Anda.

Mampu menggunakan C # dalam tampilan tidak mencegah hal itu. Itu tidak ada hubungannya dengan pemisahan keprihatinan seperti itu.

Tentu, Anda dapat menyusun kode dalam pandangan Anda untuk tidak mematuhi pemisahan masalah, tetapi bagaimana dengan kode C # yang digunakan untuk tujuan tampilan saja? Di mana itu akan tinggal?

Daripada langsung menjawab pertanyaan, tanggapan saya justru mempertanyakan asumsi yang dibuat dalam pertanyaan. Artinya, asumsi bahwa Razor dibangun untuk MVC tidak benar. Saya bekerja di Microsoft di tim ASP.NET dan memiliki pengetahuan tangan pertama tentang ini.

Razor tidak mulai sebagai mesin tampilan untuk MVC. Itu dibuat untuk ASP.NET Web Pages , yang mungkin sejauh yang Anda bisa pergi ke sisi spektrum yang paling terpisah. Itu dibuat sebagai alternatif modern untuk ASP.NET Web Forms / Classic ASP dan tentu saja banyak kerangka kerja pemrograman server serupa lainnya. Gagasan Razor adalah untuk membuat transisi yang hampir mulus antara HTML (markup) dan C # (kode).

Baru kemudian tim (termasuk saya sendiri) memutuskan bahwa sintaks Razor akan membuat banyak akal demi mesin tampilan untuk MVC, yang sedang ditulis oleh tim yang sama.

Mengenai apakah Razor mengaktifkan, menghambat, meningkatkan, atau mengubah konsep pemisahan kekhawatiran di ASP.NET MVC, jawaban Oded tepat.

Anda membingungkan "pemisahan teknologi" dengan "pemisahan masalah". Gagasan dasar di balik bagian "Tampilan" MVC adalah bahwa kode dalam "Tampilan" tidak melakukan akses data atau logika berat secara langsung, melainkan diserahkan kepada masing-masing bagian "Model" dan "Kontroler". "Controller" mentransformasikan data, melakukan semua logika yang diperlukan, dan mengarahkannya ke "View" yang benar. Pandangan juga dapat melakukan transformasi data, tetapi saya cenderung menjaganya agar tetap murni kosmetik, seperti transformasi tanggal yang disebutkan di atas.

Saya bisa memikirkan Don't do itcontoh yang sempurna .

Katakanlah kita memiliki ProductController:

public class ProductController()
{
    public ViewResult Discontinued()
    {
        var db = new ProductsDb();
        var products = db.Products.Where(x => x.Discontinued).ToList();
        return new ViewResult(products);
    }
}

Dengan pisau cukur kami punya alternatif

public class ProductController()
{
    public ViewResult Discontinued()
    {
        var db = new ProductsDb();
        var products = db.Products.ToList();
        return new ViewResult(products);
    }
}

dan dalam pandangan kami:

@model IEnumerable<Product> 

@foreach (var item in Model.Where(x => x.Discontinued)) {
    ....
}

Saya pikir cukup jelas bahwa solusi kedua terasa sangat salah. Jika Anda melakukan sesuatu seperti ini, jangan salahkan pisau cukur - salahkan diri Anda.

Dan jangan lupa: Mampu menggunakan C # dalam pandangan bukanlah fitur pisau cukur, itu mungkin dengan tampilan ASP.NET juga. Dengan pisau cukur itu hanya sedikit lebih sederhana.

Jika Anda mencari mesin templat yang lebih rel seperti Anda harus melihat nancy.fx dengan mesin tampilan super sederhana.