MVCが「懸念の分離」である場合、なぜRazor Syntaxが導入されたのですか？

私の質問は、Microsoftによって導入されたMVCデザインパターンとRazor Syntaxに関連しています。

MVCの設計パターンを学習している間、私はこの考えは「懸念の分離」として知られる原則に基づいていると言われました。

ただし、Razor構文を使用すると、ビューで C＃を直接使用できます。

これは懸念事項の交差点ではありませんか？

Razor構文を懸念の分離と混同しています。

懸念の分離は、コードの構造に関係しています。

ビューでC＃を使用できるようにしても、それを防ぐことはできません。それ自体が懸念の分離とは関係ありません。

もちろん、関心の分離に準拠しないようにビュー内のコードを構成できますが、表示目的のみに使用されるC＃コードについてはどうでしょうか。それはどこに住んでいますか？

私の回答では、質問に直接答えるのではなく、質問で行われた仮定に疑問を投げかけています。つまり、MVC用にRazorが構築されたという仮定は間違っています。私はMicrosoftでASP.NETチームで働いており、これについて直接的な知識を持っています。

Razorは、MVCのビューエンジンとして開始しませんでした。ASP.NET Web Pages用に作成されました。これは、おそらくスペクトルの最も分離された懸念の側面に向かうことができる限りです。ASP.NET Web Forms / Classic ASP、およびもちろん他の多くの同様のサーバープログラミングフレームワークの最新の代替として作成されました。Razorのアイデアは、HTML（マークアップ）とC＃（コード）の間のほぼシームレスな遷移を作成することでした。

後になって、チーム（私も含む）は、同じチームによって作成されたMVCのビューエンジンのために、Razor構文が非常に理にかなっていると判断しました。

RazorがASP.NET MVCの懸念事項の分離の概念を有効化、妨害、改善、または変更するかどうかについては、Odedの答えが注目されています。

「技術の分離」と「懸念の分離」を混同しています。MVCの「ビュー」部分の背後にある基本的な考え方は、「ビュー」内のコードがデータアクセスや重いロジックを直接実行せず、それぞれ「モデル」部分と「コントローラー」部分に残されるということです。「コントローラー」はデータを変換し、必要なロジックを実行して、正しい「ビュー」にルーティングします。ビューはデータ変換も行うことができますが、上記の日付変換など、純粋に見た目を保つ傾向があります。

私は完璧なDon't do it例を考えることができます。

ProductControllerがあるとしましょう：

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

かみそりでは、代替手段があります

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

そして私たちの見解では：

@model IEnumerable<Product> 

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

2番目の解決策が非常に間違っていると感じるのは明らかだと思います。あなたがこのようなことをするなら、かみそりを非難しないでください-自分を非難してください。

また、C＃をビューで使用できるようにすることは、かみそりの機能ではなく、ASP.NETビューでも可能だったことを忘れないでください。かみそりを使えば、もう少し簡単です。

レールのようなテンプレートエンジンを検索する場合は、スーパーシンプルビューエンジンでnancy.fxを確認する必要があります。