LIFT-web 框架是否类似于 ASP.net Web 表单？
我曾从事 .NET 方面的工作，但我正在为新项目寻找新的基于开源的 Web 框架。
我研究了 LIFT-web、Play、Ruby on Rails 等。LIFT 似乎在开箱即用的安全性和性能方面非常有前途。但它声称有一种新方法“视图优先”而不是 MVC。这听起来与 ASP.net Web 表单范例非常相似，该范例非常适合拖放开发，但在可测试性和控制方面面临挑战，实际上
我想知道是否测试并具有对运行时行为的完全可见性和控制LIFT 会很困难。我将感谢使用过 LIFT 的人提供的任何反馈，如果他们都使用过就更好了。
谢谢！
I have worked on the .NET side of things but I am looking at new open-source based web frameworks for a new project.
I looked at LIFT-web, Play, Ruby on Rails etc. LIFT seems very promising for out of the box security and performance. But it claims to have a new approach "view first" instead of MVC. This sounds very similar to the ASP.net web forms paradigm, which was great for drag and drop development but had challenges in terms of testability and having control on what actually
I am wondering whether testing and having full visibility and control on the runtime behavior of LIFT will be difficult. I will appreciate any feedback from people who have used LIFT, better still if they have used both.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我可以理解为什么您认为它们可能相似，但实际上情况并非如此......无论如何不适用于较大的应用程序。如果您正在构建一个与 Web 表单类似风格的简单应用程序，那么您会看到类似的问题。提升片段在某些方面类似于 Web 表单用户控件，但后者通常被滥用，将所有方式或内容、请求、状态等混在一起，这确实会使测试变得困难。使用 Lift 也可以做到这一点，因为该框架不会阻止您。然而，通常我不会这样做，因为我试图确保我的代码片段（用户控件，如果你愿意的话）是引用透明的 NodeSeq => NodeSeq（xml 到 xml）函数。片段与渲染内容有着极其密切的关系，仅此而已。此外，您可能有兴趣更仔细地查看站点地图功能（许多人忽略它），因为有一些有趣的方式可以将其用作接收传入请求的迷你控制器。
因此，为了尝试并进行一定程度的限定，您确实可以使用 Lift 编写丑陋且无法测试的代码（很多人都这样做），但如果您将业务逻辑与 Web 层正确分离，并采用一些开发人员纪律，那么这是一个可以管理的问题。总的来说，好处很大程度上大于坏处——特别是考虑到没有其他 Scala Web 框架实现 Lift 所具有的安全性或 Comet 功能。
最重要的是，如果您正在构建 CRUD 应用程序，那么 Lift 很可能不适合您。然而，如果您正在构建一个丰富的、ajax 或 comet 应用程序，那么它肯定值得一看。
希望有帮助。
PS：您可能有兴趣查看“Lift in Action”；它涵盖了其中一些主题 - http://www.manning.com/perrett/
I can see why you think they might be similar, but in practice it's not really the case... not for larger applications anyway. If you're building a trivial application in a similar style to web forms, then you'll see similar issues. Lift snippets are in some respects similar to web forms user controls, but the latter are typically abused with munging all manner or content, request, state and so forth together which can indeed make things difficult to test. It's also possible to do that with Lift, as the framework won't stop you. However, idiomatically I wouldn't do that, as I try to ensure my snippets (user controls if you like) are referentially transparent NodeSeq => NodeSeq (xml to xml) functions. Snippets have an exceedingly close relationship with rendering content, and thats all. In addition, you may be interested to look more closely at the site map feature (many people overlook it), as there are some interesting ways in which that can be employed as a mini-controller w/r/t to the incoming request.
So, to try and qualify somewhat, you could indeed make ugly, untestable code with Lift - many people do - but if you keep your business logic properly separated out from the web tier and employ some developer discipline it's a manageable issue. In the main, the benefits largely outweigh the cons - especially in light of no other Scala web frameworks implementing the kinds of security or comet features Lift has.
The bottom line is that if you're building a CRUD application, then its highly likely Lift isn't for you. However, if you're building a rich, ajax or comet app, then its certainly going to be worth a look.
Hope that helps.
PS: You might be interested in checking out "Lift in Action"; it covers some of these topics - http://www.manning.com/perrett/