2

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

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

ここでは、そのような考えについてご意見をお聞きしたいと思います。それは完全に奇妙ですか、それとも誰かが好きですか？

4

2 に答える 2

3

私は実際にはそれが好きではありません。

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

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

シンプルさと保守性は...禅のようなものです。

于 2010-04-02T04:49:26.000 に答える
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 配列を取り、それらを親の子コレクションに追加する拡張メソッドです。

于 2010-04-02T01:54:07.643 に答える