java - 使用 Stripes 的实践经验？

Question

我来自企业 Java 背景，涉及相当重量级的软件堆栈，并且最近发现了 Stripes framework ;我最初的印象是，这似乎很好地减少了用 Java 构建 Web 应用程序的不愉快部分。

是否有人将 Stripes 用于已上线的项目？你能分享你在项目中的经验吗？另外，您是否考虑过任何其他技术？(如果有的话)您为什么选择 Stripes？

Answer 1

我们已经使用 Stripes 大约 4 年了。我们的堆栈是 Stripes/EJB3/JPA。

许多人使用 Stripes 和 Stripernate 作为单一的全栈解决方案。我们不这样做是因为我们希望 EJB 层中的业务逻辑，所以我们只是依赖 JPA 实体作为组合模型和 DTO。

Stripe 绑定(bind)到我们的实体/DTO，我们将它们推回 EJB 层进行工作。对于我们的大多数 CRUD 东西来说，这非常简单直接，使我们 80% 的用例易于使用。然而，对于总是出现复杂应用程序的边缘情况，我们可以灵活地为所欲为。

我们有一个非常大的基础 Action Bean，它封装了我们的大部分 CRUD 操作，这些操作可以回调特定于实体和表单的各个子类。

我们还有一个大型的内部标签文件库来管理我们的页面、安全性、导航、任务等。一个简单的 CRUD 编辑表单只不过是一个字段名称列表，我们可以获得所有的 chrome 和菜单以及“免费”访问控制。

这样做的好处是我们可以保留我们喜欢的基于 HTTP 请求的隐喻，并且我们可以选择系统的各个部分，而不是使用一个胖堆栈。 Stripes 层简洁明了，从不妨碍我们。

我们有一堆集成了 YUI 和 JQuery 的 Ajax，所有这些都可以轻松地处理我们的 Stripes 和 EJB 堆栈。

我还将一个更轻量级的堆栈版本移植到 GAE 用于示例项目，基本上必须对我们的 EJB 层做一些小工作。因此，整个堆栈非常灵活且易于更改。 Stripes 是其中的一个重要因素，因为我们让它做它所做的几件事，而且做得很好。然后将其余部分委托(delegate)给堆栈的其他部分。

与往常一样，有时人们宁愿选择不同的部分，但坦率地说，Stripes 将是我们堆栈中最后一个部分。它可以更好地支持完整的 HTTP 动词集，但我宁愿修复 Stripes 以更好地做到这一点，而不是切换到其他东西。