选择 Scala Web 框架 [英] Choosing a Scala web framework

查看:29
本文介绍了选择 Scala Web 框架的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我即将为一个应该在 Tomcat 服务器上运行的 Web 应用程序启动一个项目.我决定使用 Scala——我工作的另一个选择是 Groovy——主要是为了类型安全.我现在面临着为工作选择合适工具的任务.

I am about to start a project for a web application that should run on a Tomcat server. I have decided to go for Scala - the other alternative where I work being Groovy - essentially for type safety. I am now faced with the task of choosing the right tools for the job.

我需要开发的项目只能通过 JSON API 访问.它将与自己的数据库和两个外部服务交互,这两个服务分别公开一个 JSON 和 XML API.我还需要能够安排定期作业,在这些作业中我的应用程序将使用这些外部服务执行各种同步任务.

The project I will need to develop will be accessed only through a JSON API. It will interact both with its own database and with two external services, which expose respectively a JSON and XML API. I will also need to be able to schedule periodic jobs where my application will execute various synchronization tasks with these external services.

对于数据库,我希望能够在 Scala 中定义我的模型并自动生成模式.如果需要更改我的模型,我希望有迁移来处理它.

For the database, I would like to be able to define my models in Scala and automatically generate the schema. If the need arises to change my models, I would like to have migrations to handle it.

对于此应用程序,我正在尝试评估 Lift, Play!2 和 Scalatra.

For this application, I am trying to evaluate Lift, Play! 2 and Scalatra.

  • 电梯是我的第一选择.它是三个项目中最成熟的,似乎被认为是高度安全的(我不想在安全性上妥协).此外,它具有 Scala 中最好的 JSON 处理库.尽管如此,在稍微涉足之后,我不确定这是否是正确的选择.文档并不是我见过的最好的.此外,在我看来,Record + Squeryl 似乎是比 Mapper 更好的抽象,但是这种用途的文档更加稀缺.最后,虽然 Lift 肯定可以用于创建 Web 服务,但它的真正优势似乎在于状态处理,因此我不相信我的项目需要额外的复杂性.

  • Lift was my first choice. It is the most mature of the three projects, and seems to be considered highly secure (I do not want to compromise on security). Moreover it features what seems to be the best JSON handling library in Scala. Still, after dabbling a bit with it, I am not sure this would be the right choice. The documentation is not exactly the best I have seen. Moreover, Record + Squeryl seems to me a better abstraction than Mapper, but documentation for this use is even more scarce. Finally, although Lift can certainly be used to create a web service, it seems that its real strength lies in the state handling, and so I am not convinced that the additional complexity is needed for my project.

玩!2 似乎有更好的文档,而且我看起来更熟悉(我来自 Django 背景).同样,它的默认数据库抽象并没有真正让我满意:ANORM 依赖于 SQL,它对类型检查没有帮助.无论如何我都必须使用 Squeryl,我不确定这个用例的文档是否一样好.此外,部署 Play!2 个应用程序目前比我想要的更复杂.必须安装 Play!在生产服务器上,我不确定这是我工作的一个选项.否则,有一个插件可以使其与 servlet 容器一起使用,但它是非常新的,我不确定它的稳定性/可靠性.

Play! 2 seems to have a better documentation, and looks more familiar to me (I come from a Django background). Again, its default database abstraction does not really appease me: ANORM relies on SQL, which does not help with type checking. I would have to use Squeryl anyway, and I am not sure whether the documentation for this use case is as good. Moreover, deploying Play! 2 applications is at the moment moer complicated than I'd like. One has to install Play! on the production server, and I am not sure this is an option where I work. Otherwise, there is a plugin to to make it work with servlets containers, but it is very new and I am not sure how stable/reliable it is.

最后可以选择使用 Scalatra.Scalatra 似乎很容易设置,它的设计完全是为了创建 Web 服务.妥协是 Scalatra 没有提供太多功能.它不与现有的 ORM 集成或建议如何组织应用程序的模型部分,它对设计 cron 或命令行任务没有帮助.我也不确定该项目的长期未来.

Finally there is the option of using Scalatra. Scalatra seems very easy to set up, and it is designed exactly to create web services. The compromise is that Scalatra does not offer much functionality. It does not integrate with existing ORMs or suggest how to organize the model part of the application, and it does not help in designing cron or command line tasks. I am also not sure about the long term future of the project.

你认为我的任务的最佳选择是什么?

What do you think would be the best choice for my task?

推荐答案

如果您来自 MVC 背景,那么 Play 会感觉最熟悉.Lift 不是 MVC,需要一些时间来理解它.

If you are coming from a MVC background then Play will feel the most familiar. Lift is not MVC and it takes some time to wrap your head around it.

没有理由不能将 Scala 与基于 Java 的框架一起使用,例如 Jersey、Spring MVC、Dropwizard、Restlet、RESTEasy 等.或者您可以将 Scala 与 Grails 一起使用,就像您可以将 Java 与 Grails 一起使用一样.注 - Groovy 从 2.0 版开始具有类型安全性,因此需要考虑这一点.

There is no reason that you can't use Scala with a Java-based framework like Jersey, Spring MVC, Dropwizard, Restlet, RESTEasy, etc. Or you could use Scala with Grails just like you can use Java with Grails. Note - Groovy has type safety starting with version 2.0 so that's something to consider.

如果您正在考虑 Scalatra,请不要忘记 Spray未过滤, 蓝眼...

If you are thinking about Scalatra then don't forget Spray, Unfiltered, BlueEyes...

请务必查看 Matt Raible 的 网络综合比较框架.还有这些其他问题:用于 Rest API 服务器的 Scala 框架?如何使用 Akka 实现 REST Web 服务?

Be sure to check out Matt Raible's comprehensive comparison of web frameworks. And these other SO questions: Scala framework for a Rest API Server?, How to implement a REST Web Service using Akka?

这篇关于选择 Scala Web 框架的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆