迁移到新技术始终是一条崎岖不平的道路,因此不要指望您尝试为您工作的第一件事 - 可能是您需要自己实施某些东西。稍后我会用一个具体的例子来解决这个问题。
首先,Scala 表示可扩展,而不是可集成。也就是说,如果您选择在 Scala 中编写任何代码,请记住,用于在 Java 中实现自动化的框架大多不适用于 Scala。 ORM 就是一个很好的例子,因为 Scala 方法并不总是完全是 Java 方法,因此元数据最终会出现在不正确的位置,并且最终会出现损坏的数据。所以一般的指针是,如果你使用 Scala,你真的不能在 Java 生态系统中寻找助手,除非助手完全与语言语义隔离。
安全
假设您充分利用了 Spring Security,您使用的是 role-based access control。如果您使用 Java,您实际上应该能够使用 Spring Security,这绝对可以帮助您进行迁移并节省编写更多代码的时间。您真正需要的只是 Play 应用程序中的 Spring 容器,谢天谢地,其他人已经解决了这个问题:Integrating Play framework 2.0 and Spring framework
在 Scala 方面,RBAC 似乎是 RBAC 和 ACL 之间关于语义的文明斗争,没有明显的赢家。这是有问题的,因为似乎没有人真正在工作,这意味着您可能必须自己动手。
持久性
使用 Java,您应该能够使用 Hibernate/任何 JPA 解决方案,因为它不依赖于 Web 容器。 Play 也带有 EBean,但据我观察,它不能用于最奇特的用例。可能你永远不会打到那些,所以值得一试,因为它已经在那里了。
在 Scala 方面,正如您已经想到的那样,Slick 应该没问题。
全文搜索
搜索是一件非常复杂的事情,所以我实际上会设置独立的 Solr/ElasticSearch 并将其集成到它的 API 中,而不是将其嵌入到应用程序本身中,无论使用什么语言或框架。
国际奥委会
Latest Play 几乎支持 Guice,Scala 本身试图强制执行蛋糕模式。 Spring 应该可以通过之前链接的容器集成来实现。
我希望其他人对此有很好的见解,因为 Play 的构建方式,尤其是在 Java 方面,似乎对 IOC 非常不利。