在没有用户界面的情况下使用 Grails
我正在考虑基于 EJB 的服务层的可能替代方案，并想知道仅使用 Grails 的服务和数据库层以及 远程插件还是使用大锤来破解坚果？
说到 Remoting 插件：是否有一种生成 JAR 文件的标准方法，该文件包含从非 Spring Java 应用程序远程调用 Grails 服务所需的类？
I'm thinking about possible alternatives for our EJB based service layer and wondered if it would make sense to use just the service and database layer of Grails together with the Remoting Plugin or is this using a sledgehammer to crack a nut?
Speaking of the Remoting Plugin: is there a standard way of generating a JAR file, that contains the necessary classes to make a remote call to a Grails service from a non-Spring Java application?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
有趣的想法。我认为这根本就不会太过分。好处是您的服务在协议和部署选项之间非常可移植（例如，将控制器层放在顶部并立即嵌入）。这为您提供了 EJB（持久性）的好处以及使用 Groovy 和 GORM 的能力。
FWIW，我们使用 Grails 作为我们的服务层；在某些情况下，我们将其嵌入（作为插件）使用，在其他情况下，我们将服务（通过控制器）公开为 JSON 或 SOAP；我认为将 RMI 公开为我们正在做的事情的变体（没有控制器层）。
Interesting idea. I don't think it'd be overkill at all. The nice thing is that your service would be very portable across protocols and deployment options (e.g. put a controller layer on top and it's instantly embedded). This gives you the benefits of EJB's (persistence) + the ability to use Groovy and GORM.
FWIW, we're using Grails as our service tier; in come cases we use it embedded (as a plugin), in others we expose the services (via controllers) as JSON or SOAP; I see exposing as RMI as a variation of what we're doing (without the controller layer).