举起来，玩！或者BlueEyes(带有一堆Javascript框架）

Lift, Play! or BlueEyes (with a bunch of Javascript Frameworks)

本文关键字：起来 一堆 框架 Javascript 或者 BlueEyes      更新时间：2023-09-26

我发现自己陷入了一个小难题。我正在构建一个新的、现代的、基于web的应用程序，我不仅要选择一种技术，还要选择一种体系结构。我认为可以公平地说，现在是一个艰难的选择，因为我们比5年前有更多的选择。

首先，我决定将Scala作为服务器端语言。我有我的理由，这不是一个Scala与XYZ的帖子——已经做出了选择。我还意识到，我们在网络上，在云端，所以我甚至不会试图摆脱Javascript。也许我会使用CoffeeScript，但我会编写浏览器托管的代码。

现在，假设Scala，大多数人可能会跳到Play！或Lift。可能玩！考虑到它得到了Typesafe的支持，但我想我还有另一个更重要的问题需要首先回答。体系结构是什么？如果我想要一个非常丰富的客户端，我真的需要一个简单的无状态服务层吗？因为我们无论如何都会有大量的Javascript？我不确定它会是一个单页的网络应用程序，但像BlueEyes这样的应用程序可能是正确的选择吗？举起来玩！他们承担的责任要大得多。他们生成HTML，而对于这些框架，浏览器是相当愚蠢的。路由、验证、Ajax和Comet支持等都是服务器端关注的问题。因为浏览器现在的功能更强大了，所以通常通过从服务器生成和注入Javascript来实现丰富的交互式功能。

我的问题归根结底就是这个。我会选择传统的电梯/游乐设施吗！服务器同时承担客户端和服务器责任的框架，还是使用富客户端+REST风格的服务层，在该服务层中客户端在应用程序中扮演更重要的角色？客户端处理路由、验证、绑定等的架构。我看到了KnockOut.js、Sammy.js、Sproutcore、Backbone.js等框架。

如果我选择播放！，我是不是放弃了一些丰富的UI？如果我想为集成/mashup/移动目的提供服务API，情况会怎样？怎么玩！帮我一下？显然蓝眼睛在这里打得很好。我想我无论如何都需要一个服务层。

如果我选择BlueEyes，我的客户端代码是什么样子的？我需要多少基于Javascript的框架才能满足我的需求？我仍然希望我的大部分业务逻辑都在服务层中，但路由、绑定。。所有这些UI内容都将是客户端关心的问题。

我不确定答案是对是错，但我认为这个社区可能会给我指明正确的方向。

我也在我的博客上发布了这个http://www.andyczerwonka.com/picking-a-web-technology-isnt-as-easy-as-it-u-45228

如果您只想在后端使用REST API，那么Lift，Play！否则布鲁耶会好好工作的。但我只想指出使用Lift的优点。

  1. Lift试图同时做前端和后端，这不是真的。我们支持只使用REST的Lift，这是对正确项目的鼓励
  2. 虽然Lift提供了jQuery和blueprint，您可以使用任何javascript库和css框架，但目前邮件列表上有很多人展示了他们如何使用Lift的twitter boostrap。请参阅此帮助集成引导程序的提升模块
  3. 使用Lift，您可以开始无状态，如果在这一过程中您发现自己的需求发生了变化，则可以进入无状态状态。您甚至可以在同一个应用程序上混合和匹配它们
  4. 想要一些外观现代的用户界面吗？Lift的彗星支撑即使不是最好的，也是其中之一。使用非常简单，在许多浏览器/工作负载上经过验证和测试。我写了几篇文章，展示了Lift对彗星的支持
  5. 如果您决定同时对前端和后端使用Lift，您将免费获得一个默认安全的应用程序，无需担心xss、xsrf或许多前10个OWASP安全漏洞
  6. 需要商业支持，这里的列表越来越多
  7. 需要培训吗？伦敦即将举办基础培训，Lift的创始人还提供其他培训课程
  8. 有几本关于电梯的书。电梯在行动，简单的电梯和探索电梯
  9. 有一个非常活跃的社区随时准备提供帮助
  10. 谁使用Lift？仅举几个例子：Foursquare、OpenStudy、英国卫报、StackMob等等

好吧，我应该到此为止，但简而言之，Lift是一个很棒的框架，它有很多东西可以提供，你需要多少就拿多少。

Play 2.0 Beta包含一个正是您想要的示例应用程序（ZenContacts）。它的服务器端只是一堆restful接口，而客户端则利用coffeescript等来构建一个丰富的用户界面。

据我所知，两者都玩！Lift基本上可以作为"后端"使用，您可以使用HTML5+CSS+JS作为"前端"；它们不一定会限制你创造你想要的前端的能力，所以因此拒绝它们是愚蠢的。请注意像knockout.js这样的东西宣传它们"可以与任何web框架一起使用"。然而，它们可能确实比你需要的更"重量级"。

我以前从未听说过BlueEyes，但它似乎是针对一种特定的用例。如果这符合你的要求，那么它可能是解决你问题的最简单的方法。

但如果这是你计划实际放在网上的东西，"路由、验证、绑定等"实际上需要由后端处理；我简直无法想象在客户端浏览器中运行的代码会（安全地）处理这些事情。此外，如果您的用户选择禁用JavaScript，您的网站将完全不可用。

如果我选择播放！，我是不是放弃了一些丰富的UI？

你所说的富用户界面到底是什么意思？前端有更多javascript？

如果你认为HTML5+CSS3+jQuery是一个丰富的UI，那么它们可以很好地与任何"后端"（Lift/Play）配合使用。

您可能需要考虑的另一件事是框架的成熟度。就像你提到的，Play 2.0原生地支持Scala，支持Typesafe，并且正在迅速被采用。此外，您可以轻松地公开RESTful服务，然后在前端消费（这是您的需求之一）。

向HTML5+CSS3+jQuery+Play 2.0倾斜：）

只是我的想法。。

体系结构是什么？

玩！强烈鼓励您的服务器使用MVC架构，以标准模式创建包：

app/
  controllers/
    Application.scala
  views/
    Application/
      index.scala.html
  models/
public/
  images/
  stylesheets/
  javascripts/

这使得遵循体系结构比破坏体系结构更容易

我既不能代表Lift也不能代表BlueEyes，但恐怕他们都不鼓励架构。

最终看一看http://twitter.github.com/finagle在下定决心之前。Finagle可以处理大部分后端事务。它是围绕着一个非常灵活的体系结构设计的，该体系结构巧妙地使用过滤器来分离关注点。

我看过apache点击、wicket、一点Lift（感觉有点像wicket），然后玩1.2.4。到目前为止玩得还不错。非常漂亮的网络开发方法。继续努力，玩！团队

相关文章：