使用条纹的实践经验？

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

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

Stripes 会绑定到我们的实体/DTO，然后我们把它们推回 EJB 层进行工作。对于我们的大多数CRUD内容来说，这是非常直接和直接的，使我们的80%用例变得微不足道。然而，我们可以灵活地为边缘情况做任何我们想做的事情，这些边缘情况总是会出现复杂的应用程序。

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

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

这样做的好处是，我们可以保持我们喜欢的基于HTTP请求的隐喻，我们可以选择系统的各个部分，而不是使用一个胖堆栈。条纹层是精益和卑鄙的，永远不会妨碍我们。

我们有一堆集成了YUI和JQuery的Ajax，它们都毫不费力地针对我们的Stripes和EJB堆栈工作。

我还将堆栈的较轻版本移植到 GAE 以进行示例项目，基本上必须在我们的 EJB 层中执行少量工作。因此，整个堆栈非常灵活且易于更改。条纹是其中的一个重要因素，因为我们让它做它所做的几件事，并且做得很好。然后将其余部分委托给堆栈的其他部分。

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

我们现在在所有生产基地都使用条纹，现在已经有大约一年了。与我们之前使用的支柱相比，这是一个很棒的产品。事实上，实际上没有XML配置文件，并且您可以使用最少数量的类和注释来设置它，这真是太棒了。

在缩放和速度方面，它实际上似乎比支柱更好，我的猜测是因为涉及的层更少。您最终获得的代码也更加干净，因为您不必转到单独的XML文件来找出重定向的去向。

我们将其与 EJB3 后端一起使用，这两者似乎可以很好地协同工作，因为您可以在 actionBean 对象中使用 EJB POJO，而不需要像 struts 那样的表单对象。

在我们的评估中，我们考虑了struts的alpha版本（支持注释）和许多其他框架，但是stripes因其卓越的文档，稳定性和清洁性而获胜。

不知道如何发表评论：所以为了回答你的第二个问题，我们在Stripes中没有遇到过一个我所知道的错误。对于开源框架来说，这是非常令人印象深刻的。我还没有尝试过最新版本（1.5），但1.4.x非常稳定。