2


0

ビューが完全にコードで作成されるASP.NET MVCビューエンジンが必要ですか?

最近、ビューエンジンのスパイクを作成しました。ビューエンジンはプレーンクラスであり、コンテンツは面白い「使用」スコープブロックを使用して作成されます。

コードと簡単なサンプルサイトは、http://code.google.com/p/sharp-view-engine/で入手できます。

ここでは、そのようなアイデアに関するあなたの意見を聞きたいと思います。 それは完全に奇妙なのでしょうか、それとも誰かがそれを好むのでしょうか?

3 Answer


3


私は実際にはそうではありません。

DSL(Parser-Combinatorや_data-context_でのXMLノードの生成など)には同意できますが、この場合、_too much_がそのコードに含まれていると思います。 そして、最終的に、これは境界を複雑にし、保守が困難なコードにつながります。 (すでに同じことができますが、「標準」のWebコントロールを使用するだけで、より詳細に表示できます。 変数スコープを制限するために、C#で常に `{subblock}`を使用できます。

私が使用したいアプローチは、バインディングを持つテンプレートです(ただし、「テンプレート内のコード」はありません)。 これにより、 "デザイナー"(できれば私や次の人ではない)がビューのレイアウトを自分の好みに合わせて簡単に編集できるようになります。 ただし、コアロジック(_available_コントロールとバインディング)はコード内に保持され、整理されています。 (テンプレートのもう1つの利点は、外部に格納されている場合、小さな変更ごとに再コンパイルする必要がないことです。)

シンプルさと保守性は…​ zen.


1


これは、私が言いたい極端に興味深いアイデアです。 私の店では、レイアウト以外のほとんどすべてにhtml規則を使用しています。 プロジェクトにある唯一の実際のhtmlは、Sparkマスターページです。 コンテンツ自体を生成するために、セマンティックhtmlモデルを生成するコンベンションエンジンを使用します。 (セマンティックモデルを構築するために、FubuMVCのHtmlTagsライブラリを使用しています。)

複数行テキストボックスをレンダリングするための規則の例は次のようになります。

public static HtmlTag Build(ElementRequest req)
{
    return Tags.TextArea
            .Rows(6)
            .Id(req.ElementId)
            .Attr("name", req.ElementId)
            .Text(req.StringValue());
}

これらの規則は、ビューモデルへの反映からトリガーされます(または、ヘルパーメソッドから手動で呼び出すことができます)。 出力は、マスターページのコンテンツセクションに(ToString()を介して)レンダリングされます。 すぐにビューエンジンさえ必要なくなると冗談を言っています。

psは、ネストの処理方法です。 (使用しているブロックは散らかっています!)

return Tags.Div.Nest(
    Tags.Button("save").AddClass("positive"),
    Tags.Span.Text(" or "),
    Tags.Anchor.Text("cancel").AddClass("negative")
);

Nest()は、HtmlTagのparams配列を受け取り、それらを親の子コレクションに追加する拡張メソッドです。


0


また、ASP.NET MVC用の別の純粋なC#ビューエンジンがあります-SharpDOM-http://sharpdom.codeplex.com/-同様のアイデアですが、それほど雑然としません-純粋なHTMLとロジックを組み合わせます-両方ともC#で表現されます