使用Stripes的实际经验？

Question

我来自一个Enterprise Java背景，它涉及到一个相当重量级的软件堆栈，最近我发现了Stripes framework；我的初步印象是，这似乎很好地减少了用Java构建web应用程序中令人不快的部分。

有没有人在一个已经上线的项目中使用过Stripes？你能分享你在这个项目中的经验吗？另外，您是否考虑过其他技术，以及(如果有)为什么选择Stripes？

Answer 1

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

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

Stripes绑定到我们的实体/DTO，然后我们将它们放回EJB层中进行工作。对于我们的大多数CRUD东西来说，这是非常简单的事情，使我们80%的用例变得微不足道。然而，对于总是出现复杂应用的边缘情况，我们可以灵活地做任何我们想做的事情。

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

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

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

我们有一堆集成了YUI和JQuery的Ajax，它们都可以轻松地与我们的Stripes和EJB堆栈打交道。

我还为一个示例项目向GAE移植了一个轻量级的堆栈版本，基本上必须对EJB层做一些次要的工作。因此，整个堆栈是非常灵活和友好的变化。条纹是一个很大的因素，因为我们让它做一些它做的事情，而且做得很好。然后将其余部分委托给堆栈的其他部分。

像往常一样，有时人们更愿意使用不同的部分，但坦率地说，Stripes将是我们堆栈中的最后一部分。它可以更好地支持完整的HTTP谓词集，但我宁愿修复Stripes来做得更好，而不是切换到其他东西。

Answer 2

我们现在在我们所有的生产现场都使用条纹，并且已经使用了大约一年。与之前我们经常使用的struts相比，这是一个很棒的产品。实际上没有XML配置文件，并且您可以使用最少的类和注释来设置所有这些配置文件，这一事实本身就很棒。

在可伸缩性和速度方面，它实际上似乎比struts更好，我猜是因为它涉及的层更少。您最终得到的代码也要干净得多，因为您不必为了找出重定向的去向而去分离XML文件。

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

在我们的评估中，我们考虑了struts的alpha版本(支持注释)和许多其他框架，但stripes胜出，因为它具有卓越的文档、稳定性和整洁。

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

Answer 3

我们用了大约一周的时间将一个自家开发的web框架转换成了stripes。我们现在正在生产中使用它，这是一个很棒的框架。社区是非常有用的，而且框架不会妨碍你。它可以在许多地方进行扩展，以根据您的需要更改行为。url绑定功能也很棒。我们使用注释和拦截器实现了一个健壮的安全框架。我们正在使用spring进行依赖注入，而stripes对此有很好的支持。

如果你要使用新的1.5版本，我肯定会使用它。

我是这个框架的超级粉丝。我有struts背景，这正是我要找的框架。我们团队中的其他开发人员非常喜欢使用stripes框架。

我刚从实用主义程序员的网站上买了stripes测试版的书。这是Stripes 1.5上的一个很棒的资源。