Se MVC è "Separazione delle preoccupazioni", allora perché è stata introdotta la sintassi del rasoio?

La mia domanda riguarda il modello di progettazione MVC e la sintassi del rasoio introdotta da Microsoft.

Durante l'apprendimento del modello di progettazione MVC mi è stato detto che l'idea si basa su un principio noto come Separazione delle preoccupazioni .

Ma Razor Syntax ci consente di usare direttamente C # in Views .

Questo incrocio di preoccupazioni non è?

Stai mescolando la sintassi del rasoio con la separazione delle preoccupazioni.

La separazione delle preoccupazioni ha a che fare con la struttura del codice.

Essere in grado di usare C # nelle viste non lo impedisce. Non ha nulla a che fare con la separazione delle preoccupazioni in quanto tale.

Certo, puoi strutturare il codice nella tua vista in modo da non rispettare la separazione delle preoccupazioni, ma che dire del codice C # che viene utilizzato solo a scopo di visualizzazione? Dove sarebbe vivere?

Piuttosto che rispondere direttamente alla domanda, la mia risposta mette in dubbio l'assunto formulato nella domanda. Cioè, il presupposto che Razor sia stato creato per MVC non è corretto. Lavoro in Microsoft nel team ASP.NET e ne ho una conoscenza diretta.

Razor non è nato come motore di visualizzazione per MVC. È stato creato per le pagine Web ASP.NET , che è probabilmente il più lontano possibile dal lato meno separato dello spettro. È stato creato come una moderna alternativa a ASP.NET Web Form / ASP classico e, naturalmente, a molti altri framework di programmazione server simili. L'idea di Razor era quella di creare transizioni quasi senza soluzione di continuità tra HTML (markup) e C # (codice).

Solo più tardi il team (che include me stesso) ha deciso che la sintassi del rasoio avrebbe avuto molto senso per il bene di un motore di visualizzazione per MVC, che era stato scritto dallo stesso team.

Se Razor abilita, ostacola, migliora o altera il concetto di separazione delle preoccupazioni in ASP.NET MVC, la risposta di Oded è esatta.

Stai confondendo la "separazione delle tecnologie" con la "separazione delle preoccupazioni". L'idea di base dietro la parte "Visualizza" di MVC è che il codice nella "Vista" non sta eseguendo direttamente l'accesso ai dati o la logica pesante, piuttosto che è lasciato rispettivamente alle parti "Modello" e "Controller". "Controller" trasforma i dati, esegue qualsiasi logica necessaria e li instrada alla "vista" corretta. La vista può anche fare trasformazioni di dati, ma tendo a mantenerle puramente estetiche, come la trasformazione della data sopra menzionata.

Mi viene in mente un Don't do itesempio perfetto .

Diciamo che abbiamo un ProductController:

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

Con il rasoio abbiamo un'alternativa

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

e a nostro avviso:

@model IEnumerable<Product> 

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

Penso che sia abbastanza ovvio che la seconda soluzione sembra così sbagliata. Se fai qualcosa del genere, non dare la colpa al rasoio, biasimati.

E non dimenticare: essere in grado di usare C # nelle viste non è una funzione di rasoio, ma è stato possibile anche con le viste ASP.NET. Con il rasoio è solo un po 'più semplice.

Se stai cercando un motore modello che è più binario come dovresti dare un'occhiata a nancy.fx con il motore di visualizzazione Super semplice.