2

最近我创建了一个视图引擎的尖峰，其中视图是普通的类，内容是通过使用有趣的using范围块创建的。

代码和一个简单的示例站点可在http://code.google.com/p/sharp-view-engine/ 获得

在这里，我想听听您对这种想法的看法。是完全奇怪还是有人喜欢它？

4

2 回答 2

3

我实际上不喜欢那样。

我可以同意 DSL（例如 Parser-Combinator 或用于在data-context中生成 XML 节点），但在这种情况下，我认为在代码中放入了太多内容。最后，这只会使边界复杂化并导致难以维护的代码。（您已经可以做同样的事情，但只是使用“标准”Web 控件会更加冗长。您始终可以{subblock}在 C# 中使用来限制变量范围。）

我更喜欢使用的方法是带有绑定的模板（但没有“模板中的代码”）。这使得“设计师”（希望不是我，或者下一个出现的人）可以轻松地编辑他们认为合适的视图布局。然而，核心逻辑（可用的控件和绑定）保存在代码中——整洁。（模板的另一个优点是，如果它们在外部安装，则不需要为每一个微小的变化重新编译。）

简单性和可维护性就像……禅。

于 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 回答