我想知道您如何解决基于 Java EE 的 Web 应用程序开发与其他技术堆栈( Seaside 、 Ruby on Rails 等)相比看似低效率的问题。
约束条件是:
完成的 Web 应用程序必须可部署在符合 Java EE 的应用程序容器上 如果可能，应保留之前对基于 Java 的解决方案的投资，即应该可以实现与基于 Java 的系统和库的 native 互操作性 由于团队结构，Java 作为实现语言是首选，尽管基于 JVM 的不太奇特的语言(即 Groovy)也可以接受 由此产生的系统需要在架构上是合理的 生成的系统需要可扩展和可维护 为了不让它沦为哲学讨论，我只对基于实践经验的建议感兴趣。可能的示例包括领域特定语言、框架和 MDSD。
如果您指向抽象类的解决方案(如 MDA/MDSD)，请提供有关您如何实现它的详细信息以及有关常见陷阱和最佳实践的信息。
如果您不同意基于 Java EE 的 Web 应用程序开发意味着生产力低下的假设，我也想听听您的推理。
编辑:
由于答案比我预期的少得多，我也接受失败尝试的说法，基本上将问题扩展到“在开发基于 Java EE 的 Web 应用程序时如何(不)提高生产力？”。
我相信 Java EE Java 堆栈实际上非常好。有几个原因可以解释 Java EE 的低生产力:
作为“企业堆栈”，它通常用于创建 boring, ugly, “good enough”应用程序，一般来说，enterprises tend not to attract great developers热爱编程，思考并关心他们所做的事情。企业界的软件质量并不好。 作为赚钱的企业堆栈，软件供应商试图向他们出售一些东西。他们创建庞大、复杂和昂贵的解决方案并不是因为它们很好，而仅仅是因为它们可以将它们出售给企业。 企业通常非常规避风险，他们所做的一切都更好地“标准化”。标准是在某些技术被证明成功之后或之前创建的。在这两种情况下，这对企业(和 Java)都是不利的。企业最终要么太晚使用好技术，要么使用彻底失败的技术。后一种情况也非常危险，因为它会产生一种错误的看法，即如果技术(否则完全失败)必须是好的，如果它是标准化的并且每个人都在使用它。 从历史上看，Java EE 平台似乎吸引了很多架构宇航员和大公司的开发人员晋升为架构师，他们的唯一目的是创建更多层、更多框架、更多抽象和更多复杂性。 并不是没有好的 Java 工具和框架；是有太多不好的，太多过度设计的，太多官僚的流程和方法，太多无用的标准。
在如此困惑的世界中，影响生产力的不仅仅是您选择的特定工具。这主要是关于你，关于你的值(value)观，关于你如何拒绝社区、供应商、同事和经理向你提出的大多数解决方案。这是关于你逆流而上，关于你的常识，关于你质疑每一个主流信仰和“最佳实践”。
也就是说，仅靠工具不会对您的生产力产生太大影响，相反，合适的人也可以使用劣质工具提高生产力。
我的建议:
不要仅仅因为某项技术是标准的、每个人都在使用它，或者因为它被 Sun 正式推荐而使用它。仅当您个人认为它是您工作的最佳工具时才使用该技术。通过这种方式，您可能会发现自己拒绝了 JSF、JSP、Web 服务、JMS、EJB、JTA、OSGi、MDA 等技术。 保持简单，运用你的常识，质疑一切。你真的需要发布你的对象以供远程访问吗？您是否真的需要创建另一个抽象层以便您可以从 Hibernate 切换到 TopLink？您真的需要在每次需要时将数据转换为 XML 或从 XML 转换十次吗？您真的需要 XML 模式吗？你真的需要所有可配置的东西都可以互换吗？在运行时？非开发人员？ 保持过程简单。是 agile .你真的需要那个文件吗？你真的需要在一个巨大的表格中描述每个屏幕，获得批准，输入到一些自制的工具中，然后生成JSP吗？你有称职的程序员还是你先设计一切然后程序员只“翻译”到 Java？ HTML 的 WYSIWYG 设计不起作用。 图形编程通常不起作用。这包括 UML as blueprint和 UML as programming language ，MDA，绘制页面流程图。代码生成不好。 从不 design a framework prior to using it , 总是 harvest a framework . 首选只有很少 XML 配置的框架。 争取低 LOC 计数。查看代码中的实际字符。每个角色都很重要吗？思考。你能做些什么来让你的代码更小？你需要那个课吗？它有什么作用？为什么你需要这样做？ 测试不是神牛；您不需要 100% 的测试覆盖率。只测试有意义的内容。如果很难测试，就让它更简单；或者根本不测试。不要测试视觉外观。 最后，一些具体的 Java 建议:
对于表示层尝试 Tapestry .为什么我喜欢它？因为使用 Tapestry，您可以创建漂亮的代码。它是专门为此设计的，因此 你的代码可以很漂亮 .你的代码。我所说的美丽是指所有重要的东西——它简短、易于更改、易于阅读、易于创建抽象并且仍然灵活，它不会试图隐藏您正在为 Web 开发的事实。当然，让你的代码变得漂亮的仍然是你。 随意使用 Hibernate，尤其是对于 CRUD 和大型应用程序。不要打扰 JPA。不过，这不是 Elixir ，使用 ORM，您总是会用一组问题与另一组问题进行交换。 只需要一点 Spring，您应该不需要太多，因为您已经小心地避免了所有 Java EE 陷阱。谨慎使用依赖注入(inject)。 毕竟，您可能会发现 Java 语言过于冗长，并且在抽象您复制/粘贴的代码时不是很有帮助。如果您想进行实验，请尝试 Scala。问题是 Scala 的主要卖点是您可以获得现代语言的所有好处，同时仍然保持类型安全，同时没有可靠的 IDE 支持。习惯于超酷的 Java IDE，除非有稳定可靠的 IDE 支持，否则切换到 Scala 没有多大意义。不够稳定是不够的。