开发基于 Java EE 的 Web 应用程序时如何提高生产力

Posted 2023-02-23

技术标签:

【中文标题】开发基于 Java EE 的 Web 应用程序时如何提高生产力【英文标题】：How to improve productivity when developing Java EE based web applications 【发布时间】：2010-10-13 08:15:12 【问题描述】：

我想知道您如何解决与其他技术堆栈（Seaside、Ruby on Rails 等）相比，基于 Java EE 的 Web 应用程序开发效率低下的问题。

约束是：

完成的 Web 应用程序必须可部署在符合 Java EE 的应用程序容器上如果可能，应保留以前对基于 Java 的解决方案的投资，即与基于 Java 的系统和库的本机互操作性应该是可能的由于团队结构的原因，首选 Java 作为实现语言，尽管基于 JVM 的语言（例如 Groovy）也可以接受。生成的系统需要在架构上合理生成的系统需要可扩展和可维护

为了不让这变成哲学讨论，我只对基于实践经验的建议感兴趣。可能的示例包括特定领域的语言、框架和 MDSD。

如果您指向一个抽象类的解决方案（如 MDA / MDSD），请提供有关您如何实现它的详细信息以及有关常见缺陷和最佳实践的信息。

如果您不同意基于 Java EE 的 Web 应用程序开发意味着生产力低下的假设，我也想听听您的推理。

编辑： 由于答案比我预期的要少得多，我也会接受失败尝试的说法，基本上将问题扩展到“在开发基于 Java EE 的 Web 应用程序时如何（不）提高生产力？”。

【问题讨论】：

【参考方案1】：

Spring、Hibernate、Wicket 等框架无疑有助于简化和加速 Web 开发，因为它们提供了高度的可测试性并且集成得非常好。但是，即使您拥有一套良好的开发实践，也不足以达到 RoR 生产力。仍然需要太多的技术和管道。

Grails 可能是这张图片中更接近 RoR 的缺失部分。这是我的下一个实验。

顺便说一句，我的 MDA 经历与生产力的提高相反，所以我不会提及它们（实际上，MDA 正在扼杀我们的生产力）。

【讨论】：

【参考方案2】：

经常提到基于动态语言的 RoR 和类似框架是更高效的环境，但我真的很想知道是否有硬数据支持这一点。这并不容易，因为应该确保她没有将苹果与橙子进行比较。应考虑项目类型（Web 2.0、企业应用程序）和团队规模等因素。然而，对于小型项目来说，很明显这样的框架确实比 Java EE 更有效率。所以这是一个简短的参数列表，用于支持这一点，以及您可以在 Java 世界中为它们做什么。

Ruby 是一种更直观、更简洁的语言。你可以用更少的代码做同样的事情。

我认为你不能在 Java 中拥有相同的东西，除非你当然使用在 JVM 中运行的动态语言（JRuby、Scala、Groovy）。否则，您的 IDE 可以提供帮助。在 Jave 中，IDE 是必不可少的工具，如果您学会使用它（代码生成、sn-ps、重构），它将给您回报。事实上，您可以使用 Java IDE 完成许多使用 Ruby 或 Python IDE 根本无法完成的事情。此外，您还拥有静态类型语言的好处。键入可能需要更多时间，但它可以帮助您避免常见错误。

Ruby 使用起来更有趣。让开发者更快乐、更高效。

同上。不过，我认为这是高度主观的论点。

约定优于配置让事情变得更快

像 Spring 或 Guice 这样的依赖注入框架可以提供帮助

脚手架，MVC 已经为你准备好了。

Java MVC 框架再次提供帮助

数据库变得简单。将数据库项目加载为对象。可以即时更改数据库。

Hibernate、iBatis 或其他 ORM 框架可以提供帮助。使用Hibernate Tools，您可以使用 yml 文件实现与 RoR 中类似的功能

立即加载新模块

Maven 或 Ant Ivy 可以提供帮助

易于部署以进行测试

您的 IDE 或 Jetty 可以提供帮助。事实上，使用 Java 进行调试更容易

与框架集成的测试。使用模拟对象有助于测试

依赖注入框架可以帮助模拟对象。 JUnit 是单元框架的先驱。我不认为 Java 不太容易测试。

【讨论】：

我当然同意使用框架的概念。尽管如此，在您的普通 JEE Web 应用程序中仍然存在大量结构冗余。关于“简单数据库”：当 ORM 工具隐藏的复杂性由于极端情况或滥用而浮出水面时，我看到许多项目突然停止。只是为了澄清。 Scala 不像其他列出的语言那样是动态类型的。你是对的。我应该说“面向函数式编程”的语言。【参考方案3】：

对于与持久性相关的东西，我肯定会选择 Spring 和 Hibernate。

为什么是春天？

使用 Spring 而不是其他框架的优势在于 Springs 的理念是“non-invasive”。通常，当您使用框架时，您很可能会开始依赖该框架，如果应用程序被认为运行更长的时间而您还必须进行维护等，这可能是一个糟糕的问题。Spring 使用 so - 称为“控制反转”(IoC) 模式。基本上你的代码不会（它可以但不是必须）调用 Spring，但 Spring 会调用你（好莱坞原则：“不要打电话给我，我会打电话给你”）。因此，例如，您可以使用普通 POJO（普通旧 Java 对象），而不必从任何与框架相关的类/接口继承。软件工程中的另一个大问题（如果不是最大的）是依赖关系。您将争取尽可能减少它们，因为它们会使您的生活更加艰难（尤其是在以后的维护中）。 Spring 通过配置文件和依赖注入模式管理组件的实例化，极大地减少了组件之间的依赖关系。我不想继续，最好的事情是你开始阅读官方Spring website的一些教程。最初可能需要一些时间来理解，但一旦你掌握了它，你将获得很多好处。

【讨论】：

【参考方案4】：

我相信 ~~Java EE~~ Java 堆栈实际上非常好。 Java EE 的低生产率有几个原因：

作为“企业堆栈”，它经常被用来创建boring, ugly, “good enough” 应用程序，一般来说，enterprises tend not to attract great developers 喜欢编程，思考和关心他们所做的事情。企业界的软件质量不是很好。作为赚钱的企业堆栈，软件供应商试图向他们出售一些东西。他们创建庞大、复杂和昂贵的解决方案并不是因为它们很好，而仅仅是因为它们可以将它们出售给企业。企业通常非常规避风险，他们所做的一切最好是“标准化”。标准是在在某些技术被证明是成功的之后或在之前创建的。在这两种情况下，这对企业（和 Java）都是不利的。企业最终要么太晚使用好的技术，要么使用彻底失败的技术。后一种情况也非常危险，因为它会让人产生一种错误的看法，即如果技术标准化并且每个人都在使用它，它就一定是好的（否则就是完全失败的）。从历史上看，Java EE 平台似乎吸引了很多架构师和大公司的开发人员，他们晋升为架构师，其唯一目的是创建更多层、更多框架、更多抽象和更复杂。

并不是没有好的 Java 工具和框架；就是有太多不好的，太多过度设计的，太多的官僚程序和方法，太多无用的标准。

在如此混乱的世界中，影响您工作效率的不仅仅是您选择的特定工具。这主要是关于你，关于你的价值观，关于你如何拒绝社区、供应商、同事和经理向你提出的大多数解决方案。这是关于你与当前的逆流，关于你的常识，关于你质疑每一个主流信仰和“最佳实践”。

也就是说，仅靠工具不会对您的工作效率产生太大影响，相反，合适的人也可以使用劣质工具提高工作效率。

我的建议：

不要仅仅因为它是标准的、每个人都使用它或因为它是 Sun 官方推荐的技术而使用它。仅当您个人认为它是您工作的最佳工具时才使用该技术。这样一来，您可能会发现自己在拒绝 JSF、JSP、Web 服务、JMS、EJB、JTA、OSGi、MDA 等技术。保持简单，运用你的常识，质疑一切。您真的需要发布您的对象以进行远程访问吗？您是否真的需要创建另一个抽象层以便可以从 Hibernate 切换到 TopLink？您真的需要在每次需要时将数据与 XML 转换十次吗？你真的需要 XML 模式吗？你真的需要所有可配置的东西都可以互换吗？在运行时？由非开发者提供？保持过程简单。成为agile。你真的需要那个文件吗？你真的需要在一个巨大的表格中描述每个屏幕，得到批准，将它输入到一些自制的工具中，然后生成 JSP 吗？您是否拥有称职的程序员，或者您先设计所有内容，而程序员只“翻译”成 Java？所见即所得的 html 设计不起作用。图形编程通常不起作用。这包括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 烦恼。不过，这不是灵丹妙药，使用 ORM，您总是会用一组问题交换另一组问题。只需一点 Spring，您应该不需要太多，因为您已经小心避免了所有 Java EE 陷阱。谨慎使用依赖注入。在所有这些之后，您可能会发现 Java 语言过于冗长，并且在抽象出您复制/粘贴的代码时不是很有帮助。如果您想进行实验，请尝试使用 Scala。问题是 Scala 的主要卖点是您可以获得现代语言的所有好处，同时仍然保持类型安全，同时没有 solid IDE 支持。习惯了超酷的 Java IDE，除非有稳定可靠的 IDE 支持，否则切换到 Scala 没有多大意义。足够稳定是不够的。

【讨论】：

你偷了我的话。令人难以置信的答案。感谢您分享您的经验！ Tapestry 不适合企业使用，除非您是提交者。这可能很好，它也有一个不可接受的政策 w.r.t.维护当前的稳定版本。从 4 切换到 5 时，4 没有 bug 收获，5 很长时间没有稳定。我不同意“不使用标准，但最好的工作工具”。您的代码可能存在很长时间，这可能比“当今最好的工具”长很多，因此您的雇主可能最终需要 10 到 20 年的时间来维护您用工具包/语言编写的代码其他人完全不知道。概念验证：Visual Basical 停止向后兼容版本 6。这意味着这些应用程序陷入了时间泡，但可能仍然是重要的应用程序。基于标准的项目往往寿命更长，并且有多种实现。 "代码生成很糟糕"：你完全错了。 JEE 应用程序中的大多数代码都是无聊、重复的样板代码。你必须生成它以提高生产力：你生成无聊的部分，让你把时间花在你的应用程序试图解决的真正问题上。实际上，这就是 Django 和 Ruby on Rails 之类的框架所做的。我同意 UML 不能用作编程语言，而且 makind 序列图很糟糕：这比编码慢。此外，建模并不意味着图形：例如，请参见 xtext 之类的工具。我将建模视为快速创建 dsl 的一种方式。【参考方案5】：

从 Jython 2.5 开始，您可以使用 django 来满足您列出的要求。从 django 项目生成 war 文件并将它们部署到 J2EE 应用程序服务器上非常容易。

【讨论】：

JRuby on Rails 也是如此。唉，我可能处于对 Java（技能）进行巨额投资的情况。由于句法和部分惯用的相似性，Groovy 可能会起作用。 Python 可能会被拒绝。出于好奇：Jython 2.2 是否被视为生产质量？我推荐了 django，因为它不是另一个 rails 克隆，它比 rails/grails 更适合“企业”的东西。 Jython 2.2 稳定，2.5 也是稳定的（它已退出最后一个测试版）。我不明白为什么有人会使用 2.2，从那以后该语言已经走过了漫长的道路。【参考方案6】：

我会选择用 Scala 编写的 Lift framework。只需切换到Scala，您就会看到极大的生产力提升。 Scala 也非常稳定，从 Scala 代码调用 Java 代码非常容易。不仅如此，它还与 Java 非常相似，但增加了一些特性。对于一些示例，您应该参考5 Things a Java developer needs to know about Scala. Twitter 会将其部分代码库移至 Scala。

您永远不会“卡在”一段代码上，因为您只需考虑如何在 Java 中完成它并编写类似的代码。一流的函数和演员将为您提供更大的生产力提升，并且都在 Scala 中。 Scala 当然是静态类型的，其性能与 Java 类似。

我将引用 Lift 框架的作者对其的描述：

Lift 借鉴了现有的最佳产品框架，提供
Seaside 的高度精细会话和安全 Rails 快速闪现 Django 的“不仅仅是包含 CRUD” Wicket 对设计师友好的模板风格（参见电梯视图首先）
而且因为 Lift 应用程序是用 Scala 编写，一个优雅的新 JVM 语言，您仍然可以使用您的最喜欢的 Java 库并部署到你最喜欢的 Servlet 容器。采用您已经编写的代码和部署到您已经部署的容器配置好了！

【讨论】：

您是否有在企业环境中使用 Scala 或 liftweb 的实际经验（即客户通常是风险厌恶的后期采用者）？虽然我发现 Scala 很漂亮，liftweb 很有前景，但我不确定其中任何一个是否已准备好用于生产环境。 Scala 已经准备好了。原因是它只是搭载了稳定的 suns jvm。编译到它并不难。我在小型互联网项目中使用过 Scala。我对 Lift 有一些疑问，尽管很小。 innovationgames.com希望我能帮助你更多。【参考方案7】：

Javarebel 可以大大减少使用 Java 进行 Web 开发所花费的时间。

这里引用官网：

JavaRebel 是一个 JVM 插件 (-javaagent)，可让您立即查看代码更改，而无需重新部署应用程序或执行容器重启。如果您厌倦了看着日志滚动，并希望看到您的更改以便继续前进 - JavaRebel 是您最好的新朋友。

【讨论】：

【参考方案8】：

讨论 Java EE 生产力时的一个重点：您应该使用 Java EE 5 和 EJB3.x，因为与以前的版本相比，它们提供了更高水平的生产力（和功能）。

遵守标准 Java EE 规范是绝对重要的，例如使用 Hibernate 而不是 JPA 对生产力没有好处。使用 JPA 时回退到 Hibernate 功能没有任何限制，但是通过使用 Hibernate 而不是 JPA，您将被锁定在单一的持久性提供程序中，没有廉价的出路。使用标准背后的整个想法是相同的：概念上的灵活性（通过插入不同的实现）和可用的可扩展性（如果绝对必要，通过使用专有扩展）。 Java EE 5 和 EJB3 是朝这个方向迈出的一大步。当然，您希望最大限度地减少任何专有功能，但如果某些功能看起来绝对必要，这是一个好兆头，它们将成为下一版本规范的一部分......

Java EE 生产力的主要障碍在于其对企业的关注（提供的功能远远超出大多数项目的需要）和遗留问题（向后兼容性）。在 JSF 和状态管理的表示层中还有很多工作要做 - 请注意 JSR-299 以解决这些以及其他改进。

【讨论】：

被“锁定在一个单一的持久性提供者中”听起来很可怕——但实际上一个规模合理的项目不会切换持久性提供者。因此，使用 JPA 和 Hibernate 只会增加更多的抽象和混乱，并且会阻碍生产力。我不同意。拒绝持久性 API 将阻碍任何 JEE 应用程序的生产力，除了极少数情况：Java 中不需要持久性操作、所有存储过程方法、仅批处理作业等。在 JPA 出现之前，我反对使用实体 EJB，但现在不再...... 【参考方案9】：

只是想提出另一个想法……您实际上可以使用 JRuby 和 Rails（类似于之前关于 Django 和 Jython 的评论）。

如果您将 JRuby 与 Rails 和 JRuby Rack 一起使用（可能还有其他一些实用程序……我并不是真正开始进行集成的人），您可以将 JRuby Rails 添加到现有的 Java Web 应用程序中。我们有一个使用 Tomcat 部署的旧版 JSP 应用程序，现在开始使用 Rails 使用该设置添加新页面（除了在必要时扩展 JSP 端）。到目前为止，它已经相当成功，尽管我们没有在 Rails 中实现任何主要的高流量页面，所以我不知道它的扩展性如何。

我们可以完全访问会话，甚至设置了从 Rails 页面调用 JSP 的机制（例如现有的页眉和页脚类型 JSP 包括）。完全集成 2 需要一些努力和反复试验，但如果可以选择 Rails 和 JRuby，我强烈推荐它（作为 Ruby 的个人粉丝）。

一位同事涉足了 JBoss Seam，这是一个由 Gavin King（为我们带来 Hibernate 的人）开发的框架，旨在模拟 Rails。两者都看过，我觉得 Rails 更容易开发。

【讨论】：

这听起来很诱人，考虑到 JRuby 已经走了多远。 Cucumber/RSpec 的无缝使用听起来也很诱人，但恐怕 JRuby 不会满足“Java 或较少异国情调的 JVM 语言”标准。出于好奇：您能否分享有关 JSP-Rails-Integration 的详细信息？我不能透露太多细节，因为这是我的工作，但我们做了一些事情，比如创建一个 jsp 助手来加载一个 jsp，使用我创建的模拟响应......助手将采取将存储在请求中的变量，然后 jsp 可以引用这些变量。我们的视图模板自动调用页眉和页脚，我们有一个 before 过滤器将检查会话以确保用户正确登录（所有 3 个使用 jsp 帮助器调用现有代码几乎没有重复的逻辑）。我们甚至可以使用 JRuby Rack 附带的 jsp 标签将一些 Ruby 部分嵌入到现有的 jsp 页面中。一个让我们感到困惑的笔记...... Rack 或其他一些工具正在将会话整数转换为 Longs......但是一个简单的 JSP 过滤器通过观察变量并在更改时将它们转换回来来解决它。【参考方案10】：

Grails 是一个非常模仿 Ruby on Rails 的 Java webapp 框架，具有类似的原则（DRY、CoC）和生产力提升，但基于现有的 Java 框架（Spring、Hibernate 等）。

我已经使用 Grails 进行了几个星期的探索性项目（之前没有使用 Grails 或 Groovy 的经验），我印象非常深刻。有一些粗糙的边缘 - 它不像 RoR 那样成熟，但你可以快速获得结果，并且永远不会觉得框架会妨碍你。

也许这个具体的例子能很好地说明：我想在单个网页的网格中编辑域对象的二维数组，发现生成的 HTML 请求数据到域对象的自动映射（由 Spring MVC 提供，我相信）有一个错误导致一些数据被映射到错误的对象。我在网上看了一个小时，但显然没有人遇到或解决这个问题。最终我决定放弃自动映射并“手动”进行 - 然后发现我只用了大约 10 行代码......

【讨论】：

【参考方案11】：

使用 AOP（面向方面的编程）进行横切方面，如日志记录、授权等。您可以使用 Spring AOP 或 AspectJ。它使代码变得整洁且易于维护。

【讨论】：

【参考方案12】：

好吧，我不是真正的 Java 人，所以我不能说太多，除了... JSF

我们尝试使用它一段时间，结果是一场灾难。 Almots 的所有基本步骤都必须通过大量的痛苦，没有文档，没有示例，没有社区知识。我们当时使用了一个用于 Eclipse 的插件（Exadel Studio），我们查看了其他一些 JSF 框架，它们都是不兼容的并且文档不完整。事实上，在我们尝试过的所有方法中，只有 Sun 框架（忘记了它的名字，基于 NetBeans）可以创建一个新的 JSF 项目，甚至可以开箱即用地编译。其余的需要很多天来配置 apache 和其他东西，这对于没有经验的人来说是一个真正的挑战（尽管我做到了）。

我们的团队花了几个月的时间在几周后用 ASP.NET 完成了一些事情。人们在 JSF 和 ASP.NET 方面都缺乏经验。

如果 JSF 生态系统仍然像 2007 年那样糟糕，我建议完全避免使用它，无论如何生产力都是不可能的。也许坚持使用 JSP 或经过时间验证且开发良好的东西？

【讨论】：

JSF 还不错。当然它在某些地方有点难看，但是当你将它与 Facelets 和像 Seam 这样的框架一起使用时，它实际上非常方便。【参考方案13】：

在过去的几年里，我一直在使用Jboss Seam，并发现它是在 Java EE（利用 EJB3、Hibernate、Facelets）中进行开发的一种非常高效的方式。我还做了一些奇怪的 php 编码，老实说，我使用 Seam 更有效率（尽管这可能也表明我的 PHP 技能。）

对我来说，有几个亮点是：

代码热部署（绝对必备）用 Facelets 干燥基于注解的配置广泛的插入式组件（尤其是 ajax4jsf）来自 Jboss 工具的 IDE 支持

IDE 和命令行中有一些工具可以以类似于 RoR 的方式构建框架代码。

【讨论】：

【参考方案14】：

一些基本规则：

Kick out the appserver - 周转和质量方面的巨大胜利。如果需要，保留一个 Web 容器，但在 Spring 和/或 Hibernate 中配置所有内容，以便 web.xml 最小化。