最近一直在学习 ASP.MVC 2,最近发现那里有不同的渲染引擎...... Spark 特别引起了我的注意,尽管有几件事。
- 我对 ASP.NET 有广泛的了解,所以除了 ASP.NET MVC 之外,是否值得一试
- 一般值得吗?真的有关系吗?这似乎真的是一种口味偏好,而不是性能,甚至是开发人员时间的大幅减少。
- 它似乎仍然不成熟,不是很好的智能感知支持,语法高亮支持,工具选项不多。它仅初步支持 MVC 2...
你怎么认为?我倾向于它可能不值得......
最近一直在学习 ASP.MVC 2,最近发现那里有不同的渲染引擎...... Spark 特别引起了我的注意,尽管有几件事。
你怎么认为?我倾向于它可能不值得......
按顺序回答三个部分的问题...
一次学习一个新事物可能是一个好主意。特别是因为几乎所有的 MVC 示例和教程都将采用 WebForms 语法。也就是说 - 最好在实验解决方案中学习,而不是在“真正的”项目中学习,所以在你觉得你已经掌握了 MVC 概念之后,创建一个新的沙箱并尝试一些 MVC + Spark 页面是一个好主意。
除了最大的网站外,内存压力或处理器利用率方面的性能可能不是所有网站最重要的考虑因素......对开发人员和设计师/创意人员的影响起初可能很小,但它是累积的和非线性的. 预先进行一些简化将为您在未来节省大量痛苦,而“简单、简单的语法”是 Spark 视图引擎前提的基石。
这是非常正确的。经验的完善和完善是工具和现代 IDE 中最昂贵的部分。我认为这就是为什么大多数 OSS Web 堆栈都从一个出色的编辑器(咳TextMate咳)开始,然后从那里开始工作。使用 Spark,您可以获得 csharp 语言智能感知,但这显然是工具支持的低水位标记。
这是轶事,但衡量的一种方法是有多少人后悔使用 Spark 并切换回来。我不确定很多——尽管在获得 MVC 2 支持方面的延迟让一些人想知道,我敢肯定。
取决于你想用 ASP.NET MVC 做什么。我们正在用它构建一个大型企业应用程序,我发现自己有点希望我们使用 Spark。但这只是在我们完成第 200 个视图之后,我才对框架感到足够舒服,可以考虑加入其他东西。
我建议首先使用常规视图引擎构建一些小型应用程序,如果您发现自己在“标签汤”中挣扎,请退后一步考虑原因。在许多情况下,这只是意味着您应该制作更好的 ViewModel 和映射数据、创建 html 帮助程序或使用部分文件,而不是用标签汤填充您的视图。
但是,有时视图中需要条件和大量循环逻辑,此时您可能希望拥有 Spark。好处是您可以并排使用两者。所以我会说使用默认设置,一旦你感到舒服就可以使用它。
Web 应用程序中 MVC 的优点之一是您可以更接近 HTML 的裸机,这是许多开发人员遇到的主要问题之一 - 缺乏对呈现的 HTML 的绝对控制
Spark 比 ASP.net 更接近于纯 HTML
一般来说,非编程的 HTML 设计师比 ASP.net 更有机会理解 Spark 并使用它
如果这对您来说是个问题,请使用 Spark,否则请使用您想要的任何渲染引擎。查看nhaml了解不同的内容
实际上,几个月前我也面临过同样的选择,但是是为了真正的商业应用,而不是为了教育目的。我的回答是“激发”。
当然,有一些棘手的事情,比如智能感知和包含用于预编译。但从我的角度来看,好处更显着。spark中视图的“可读性”要好得多。有更优雅的部分分离(再次,我个人的看法)。我还发现站点本地化的 spark 方式更自然(MyView.spark、MyView.de.spark、MyView.de-DE.spark 具有自动回退功能,主布局也是如此)。很多小便利 - 最重要的是我喜欢 ${} 和 !{} 来获取 html 编码或避免它。我的应用程序在预先编译的中等信任下工作。
我宁愿说spark已经足够成熟,可以在实际开发中使用了。但并不完美。
我知道这个问题在 Razor 推出之前已经得到了解答,但如果我开始一个新项目,我会选择 Razor。我目前有一个 Spark 项目,我绝对同意它是比 WebForms 更好的选择。但由于情况发生了变化,如果我今天必须做出决定,我会选择其他东西。
原因
我不认同 Razor 的优先级错误的说法。他们说 Razor 的默认设置是代码,然后是一些标记,而 Spark 则相反。我在一定程度上同意这个论点;两个视图引擎都可以使用这些工具来获得无代码或有代码的视图。这取决于最终输入它的人。