RazorまたはXSLTは私のプロジェクトに適していますか？[閉まっている]

私は、本質的に2つの部分に分割されるシステムの設計の初期段階にいます。1つはサービスで、もう1つはODataやXMLなどのデータを提供するサービスとのインターフェースです。アプリケーションは、MVCアーキテクチャパターンに基づいています。ビューについては、ASP.NETでXSLTまたはRazorの使用を検討しています。

XSLTまたはRazorは、元のXMLまたは応答がモデルを表す場合、XSLTまたは 'Razorビュー'がビューを表す場合の懸念を分離するのに役立ちます。この例では、コントローラーを省略します。最初の設計提案ではXSLTを推奨していますが、よりフレンドリーなビューエンジンとしてRazorを使用することを提案しました。

これらは私がRazor（C＃）に提案した理由です：

• より複雑なページの操作と作成が簡単になります。
• * ML以外の出力（csv、txt、fdfなど）を簡単に生成できます
• 冗長でないテンプレート
• ビューモデルは強く型付けされており、ブール値や日付値など、XSLTは規則に依存する必要があります。
• マークアップはより近づきやすいです。たとえば、nbsp、改行の正規化、属性値の正規化、空白ルール
• 組み込みのHTMLヘルパーは、DTO属性に基づいてJS検証コードを生成できます
• 組み込みのHTMLヘルパーはアクションへのリンクを生成できます

そして、かみそりよりもXSLTの議論は：

• XSLTは標準であり、今後も何年も存続します。
• 誤ってロジックをビューに移動するのは難しい
• プログラマー以外の方が簡単です（同意しません）。
• 過去のいくつかのプロジェクトで成功しています。
• データ値はデフォルトでHTMLエンコードされます
• 常に整形式

だから私はどちらかの側の意見、推奨事項、または同様の選択をする経験を探していますか？

私が持っている成功した最後の12年間では1999年に...ウェブプレゼンテーション層としてXSLTを使用し、より良いオプションは、一緒に来ています。自分自身に大きな好意を示し、Razorを使用します。喜んで。

これは基本的な構文比較です

かみそり

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

2つの例のデータソース

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

HTMLページとXML出力の間に1対1の関係はありますか？以下のケースを検討してください。

• 強い相関関係：各Webページには、HTMLおよび対応するXMLフォームがあります。

例：映画のレビューが掲載されたウェブサイトをホストしているとします。最新のレビューが掲載されたホームページ、レビューごとに1ページ、ゲストのコメントと評価が掲載されたページがあります。登録は一切ありません。見苦しいHTML解析を行わずに、プログラムでWebサイトを簡単に使用できるようにしたいとします。この場合、1対1の関係を持つことができます。人間が実行できるすべてのこと、ボットも実行できることです。同じ要求で、同じコンテンツを取得します。

http://example.com/Movie/View/12345/The%20Adjustment%20Bureauは人間が使用します。
http://example.com/Movie/View/12345/The%20Adjustment%20Bureau?xmlは、ボットが同じ情報にアクセスするために使用します。

• 相関関係が弱いか、まったくありません。片側には多数のWebサービスがあり、もう一方には多数のWebページがあります。

例：あなたは別のFacebookの作成者です。ウェブサイトがあり、APIがあります。唯一の共通点は、同じデータベースが使用されますが、ボットは人々がアクセスできるものにアクセスできず、情報の表示方法が異なることです。

http://example.com/MyFriends/には、自分のアカウントにいる友達のトップ10が表示されます。[もっと見る]をクリックすると、AJAXリクエストが作成され、他の友達が表示されます。
http://api.example.com/friends?user=MainMa&key=1DE051C6F&xmlは、私が持っているすべての友達と対応するXMLを示しています。

あなたはそれを見ることができます：

• APIは別個のサーバー上で個別にホストされ、
• ページとAPIの関係はわかりにくいです。
• Webサイトは、セッションを使用してログオンを追跡する必要があります。APIは、すべてのリクエストで送信される生成されたキーを必要とします。
• リクエストの数は同じではありません。1つのケースでは、ページをクエリしてから、AJAXリクエストを実行して、残りの友達を取得する必要があります。それ以外の場合は、リスト全体を一度に取得します。
• 返される情報は同じではありません。人間として、あなたは友達の名前で友達を識別します。APIを使用するボットは、Webサイトでは決して見られない固有の識別子によってそれらを識別します。

XSLTは、1対1の関係に近い場合にのみ選択することをお勧めします。この場合、アプローチが単純になります。アプリケーションは毎回XMLを出力しますが、ブラウザーのXSLTで変換することもあります。

この関係がなければ、XSLTがRazorより優れていることはわかりません。Razorが提供する懸念の分離も提供します。それはあなたがウェブサイトを再コンパイルする必要なしにHTMLを修正することを可能にします、それはRazorも許可します。

あなたがリストした利点については：

XSLTは標準であり、今後も何年も存続します

あなたは非常に長い間存続するアプリケーションを作ることを計画していますか？Razorは4年間使用される可能性があり、少なくともサポートされる可能性があります。ほとんどのアプリケーションの寿命は4年未満なので、...

プログラマー以外の方が簡単です（私が対処できるもの）。

待って、何？プログラマーでさえ、XSLTはひどいものであり、理解し、使用するのが難しいことに気づきます。そして、プログラマー以外の人にXMLについて（XSLTにさえ近づいていない）と話すと、彼らは泣いて逃げます。

過去のいくつかのプロジェクトで成功しています。

チームが以前にRazorを使用したことがない場合は、それを学ぶのに必要な時間を考慮してください。

チームがそれを使用したが、それらのプロジェクトが失敗した場合、なぜ失敗したのか、そしてRazorが原因であったのか、そして将来のプロジェクトでそのような失敗を回避するために何ができるのかを分析することを検討してください。

私の推奨はRazorです。主な理由は、操作がはるかに簡単であることです（XSLTよりも、XSLTを支持する列挙された引数とは逆ですが、あなたは私の側にいます）。私は両方で作業した経験があり、Razorは条件付きステートメント、宣言的ヘルパー（基本的には関数）、分岐、ループなどで非常に強力になります。

結局のところ、Razorはプログラミング言語（そうですね、テンプレートエンジン、またはビューエンジンですが、C＃やVB.NETなどのプログラミング言語を介して実装されています）であり、XSLTはマークアップ構造を持っていることを忘れないでください。

あなたのシナリオは、複雑なビジネスアプリケーションを作成するためにC＃またはT-SQLを選択しようとしているようなものだと思います。T-SQLは集合演算ではかなり強力ですが、ロジック（if-else、switch、forなど）を実装しようとすると、壊れます。

選択する必要はありません。両方を使用できます。ASP.NET MVCでは、複数のビューエンジンを同時に使用できます。現在取り組んでいるプロジェクトでは、読み取り専用ビューにXSLTを使用し、フォームにRazorを使用しています。XSLTをRazorレイアウトで、またはRazorをXSLTレイアウトで使用することもできます。私はXSLTレイアウトを使用しているので、XSLTレイアウトを呼び出してセクションHTMLをパラメーターとして渡すRazorレイアウトを使用します。

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

...そしてhtmlRaw.xslあなたの中で単に使うdisable-output-escaping="yes"：

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

同じプロジェクトでのRazorとXSLTの使用を参照してください。

3番目のより良い方法があることをお勧めします。UIのない​​単一のサービス/アプリケーションレイヤーの上に2つの異なる薄いフロントエンドを配置します。

だからではなく

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

使用する

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

また、UIとサービスに、そのインターフェイスに固有のコードのみが含まれていることを確認してください。（ASCIIダイアグラムについての謝罪、私が今できる最善のこと）

あなたが議論している設計のどちらかについて私が心配する理由は、それがユーザーインターフェイスの開発をサービスの開発に結びつけることです。ビジネスがユーザーインターフェイスに機能の一部を追加する必要がある場合、それを行う前にそのサービスを強制的に作成する必要はありません。ユーザーインターフェイス部分を記述し、それがサービスで必要であると想定して、そこでコードを再利用します。

さらに悪いことに、サービスを介して機械ユーザーにデータを表示する方法とは非常に異なる方法でデータを表示したい場合（これは非常に可能性が高いようです）、複雑なコードをXSLTに挿入する必要があります。ユーザーのプレゼンテーションを表すために、サービスの上に2番目のサービスレイヤー（さらに悪い場合はファットコントローラー）を構築します。

この場合の検証について考えます。あなたは潜在的に3つのレベルの信頼を引き出しています。モデルでは、無効なデータを格納しないようにするための検証が必要です。次に、外部のコンシューマーが許可されていないことを行わないようにするために、サービスでさらに検証が必要になる場合があります。また、UIには、ポストバックを回避できるように、いくつかの検証ルールが必要です。

そして、これは、APIを介して許可されるべきではないが、APIを必要とするUIを介して許可されるべきである何かの粘着性のある状況にさえ触れる前です。

サービスを介してUIを実行することはドッグフーディングであり、したがってサービスの品質に優れているという議論を聞いたことがありますが、サービス間の懸念を確実に（そしてSOLIDで）分離しながら、これを行うより良い方法があることを強くお勧めします。 UIとビジネスモデル。

以上のことから、サービスをUIでラップする必要がある場合は、XSLTよりもRazorを強くお勧めします。

はい、XSLTは標準です。しかし、XSLT 2.0のサポートはまだ限られているので、その議論をしたい場合は、古い標準で立ち往生しています。

XSLTは読みにくい。XSLTのエキスパートではない方。新しいスタッフを雇う必要があるときに、誰が見つけやすいと思いますか？XSLTのエキスパートまたはASP.NET for MVCのエキスパートであると主張する人はいますか？

そして、はい、XSLTが正常に使用されているのを見てきましたが、MVC for ASP.NETがオプションになる前のみでした。