Si MVC est une «séparation des préoccupations», alors pourquoi la syntaxe Razor a-t-elle été introduite?


22

Ma question est liée au modèle de conception MVC et à la syntaxe Razor introduits par Microsoft.

Tout en apprenant le modèle de conception MVC, on m'a dit que l'idée était basée sur un principe connu sous le nom de séparation des préoccupations .

Mais Razor Syntax nous permet d'utiliser directement C # dans les vues .

N'est-ce pas l'intersection des préoccupations?


7
Il convient de mentionner que ASP.NET MVC n'implémente pas réellement le modèle de conception MVC. MVC dicte que le modèle est observé par la vue des modifications, ce qui n'est clairement pas le cas dans ASP.NET MVC.
Benjamin Gruenbaum

11
Cela peut également être utile si vous changez votre façon de voir les vues. Les vues ne sont pas du code côté client. Ce sont des modèles côté serveur qui, une fois traités, génèrent du code HTML côté client. Et en tant que code côté serveur, il est parfaitement acceptable qu'il y ait du code C # là-bas.
Eric King

6
@EricKing, à l'exception de la partie où les systèmes de modèles qui autorisent du code arbitraire conduisent toujours, via le chemin de moindre résistance, à une mauvaise conception, à une horrible violation de superposition et à une maintenance impossible. Malheureusement, il semble que ce soit une leçon que chaque communauté doit apprendre par elle-même.
hobbs

12
@hobbs Wow, ok. Pas d'après mon expérience. Certainement pas toujours, et (bien sûr) il y a une responsabilité professionnelle de la part du programmeur. Je ne blâme pas l'outil.
Eric King

7
@BenjaminGruenbaum N'est-ce pas comme chaque cadre "MVC" de nos jours différent dans la façon dont ils gèrent les interdépendances? Au point où il n'est plus productif de parler de The One And Only True MVC-Style, mais où il serait plus pragmatique d'utiliser le terme pour tout système qui répartit raisonnablement la responsabilité dans les modèles , les vues et les contrôleurs, mais ceux-ci sont interdépendants?
Alex

Réponses:


66

Vous confondez la syntaxe Razor avec la séparation des préoccupations.

La séparation des préoccupations concerne la façon dont vous structurez votre code.

Pouvoir utiliser C # dans les vues n'empêche pas cela. Cela n'a rien à voir avec la séparation des préoccupations en tant que telles.

Bien sûr, vous pouvez structurer le code à votre avis pour ne pas respecter la séparation des préoccupations, mais qu'en est-il du code C # utilisé uniquement à des fins d'affichage? Où cela vivrait-il?


1
Mais C # est un langage côté serveur?
John Strowsky

6
@John - alors? Si vous devez formater des dates pour l'affichage (et l'affichage signifie toujours côté client), où les formateriez-vous? Le modèle? Le controlle? Ni. Vous le feriez dans la vue.
Oded

16
@John - donc, votre date est stockée dans la base de données, vous la passez par le modèle / contrôleur à votre vue. Vous avez besoin là-dedans dans le HTML, donc vous le sortiriez en quelque sorte vers JS pour formater, au lieu de formater directement avec C #? Pourquoi? Pourquoi est-ce mieux? Ou plutôt, comment cette approche est-elle davantage une séparation des préoccupations?
Oded

25
@ NPSF3000 - une langue n'est pas "côté serveur" ou "côté client". C'est une séparation architecturale - et peut-être l'une des implémentations de langage (JavaScript est un langage côté serveur ou côté client - souvenez-vous de node.js).
Odé

14
@FreeAsInBeer - c'est le genre de logique qui appartient au côté client - quelqu'un en France voudrait voir les dates (et les devises / nombres) formatées différemment de quelqu'un aux États-Unis. Le client «connaît» le mieux comment ces informations doivent être affichées. C'est une logique de présentation , et en tant que telle appartient à la vue.
Oded

35

Plutôt que de répondre directement à la question, ma réponse remet en question l'hypothèse formulée dans la question. Autrement dit, l'hypothèse selon laquelle Razor a été créé pour MVC est incorrecte. Je travaille chez Microsoft dans l'équipe ASP.NET et j'ai une connaissance de première main de cela.

Razor n'a pas commencé comme moteur de vue pour MVC. Il a été créé pour les pages Web ASP.NET , ce qui est probablement le plus loin possible du côté des préoccupations les moins séparées du spectre. Il a été créé comme une alternative moderne aux formulaires Web ASP.NET / ASP classique et bien sûr à de nombreux autres cadres de programmation de serveur similaires. L'idée de Razor était de créer des transitions presque transparentes entre HTML (balisage) et C # (code).

Ce n'est que plus tard que l'équipe (qui comprend moi-même) a décidé que la syntaxe Razor aurait beaucoup de sens pour le bien d'un moteur de vue pour MVC, qui était écrit par la même équipe.

Quant à savoir si Razor permet, entrave, améliore ou modifie le concept de séparation des préoccupations dans ASP.NET MVC, la réponse d'Oded est parfaite.


2
Oui, downvote sans commentaire. J'ai modifié ma réponse pour indiquer clairement que je remets en question l'hypothèse formulée dans la question initiale. À mon avis, la question ne peut pas être directement répondue parce qu'elle a une prémisse invalide.
Eilon

Par curiosité, d'autres moteurs de modélisation ont-ils été envisagés pour ASP MVC?
NWard

2
@NWard Il existait à l'époque un certain nombre de moteurs de visualisation tiers pour ASP.NET MVC, mais nous ne les avons pas trop pris en compte. Nous avons estimé que Razor était plus facile à comprendre (le HTML est HTML, le C # est C #) et gélifiait également mieux avec le projet ASP.NET Web Pages.
Eilon

1
@Alex oh, je ne peux certainement pas prendre le crédit pour tout Razor, mais j'apprécie votre commentaire!
Eilon

1
@ateri Après un court instant, c'est le grand nombre en haut à gauche de la réponse.
Mark Hurd

9

Vous confondez «séparation des technologies» et «séparation des préoccupations». L'idée de base derrière la partie "Vue" de MVC est que le code dans la "Vue" n'effectue aucun accès aux données ou logique lourde directement, plutôt qu'il est laissé aux parties "Modèle" et "Contrôleur" respectivement. Le "contrôleur" transforme les données, exécute toute logique nécessaire et les achemine vers la "vue" correcte. La vue peut également effectuer des transformations de données, mais j'ai tendance à les garder purement cosmétiques, comme la transformation de date mentionnée ci-dessus.


cela ne semble pas offrir quoi que ce soit de substantiel par rapport aux points avancés et expliqués dans les réponses précédentes, en particulier celle-ci
moucher

4
+1 Formulé de manière concise et claire et avec un objectif d'explication différent des réponses précédentes.
Alex

@gnat Je voulais juste préciser où était sa confusion, puis expliquer rapidement comment le principe de séparation des préoccupations s'applique au modèle de conception MVC. Peut-être aurais-je dû consacrer plus de temps à ce que signifie «séparation des préoccupations»?
whoisthemachine

0

Je peux penser à un Don't do itexemple parfait .

Disons que nous avons 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);
    }
}

Avec le rasoir, nous avons une alternative

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

et à notre avis:

@model IEnumerable<Product> 

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

Je pense qu'il est assez évident que la deuxième solution se sent tellement mal. Si vous faites quelque chose comme ça, ne blâmez pas le rasoir - blâmez-vous.

Et n'oubliez pas: pouvoir utiliser C # dans les vues n'est pas une fonctionnalité de rasoir, c'était également possible avec les vues ASP.NET. Avec le rasoir, c'est juste un peu plus simple.

Si vous recherchez un moteur de modèle qui est plus de rails comme vous devriez jeter un oeil à nancy.fx avec le moteur de vue Super simple.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.