代码之家  ›  专栏  ›  技术社区  ›  Nils Wloka

如何在开发基于JavaEE的web应用程序时提高生产率

  •  25
  • Nils Wloka  · 技术社区  · 15 年前

    我想知道,与其他技术相比,基于JavaEE的web应用程序开发的生产率似乎很低,您是如何解决这个问题的( Seaside , Ruby on Rails

    制约因素包括:

    • 如果可能,应该保留以前对基于Java的解决方案的投资,也就是说,与基于Java的系统和库的本机互操作性应该是可能的
    • 由于团队结构的原因,Java作为实现语言是首选,尽管基于JVM的语言(如Groovy)也可以接受
    • 由此产生的系统需要具有可扩展性和可维护性

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

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

    编辑: 由于答案比我预期的要少得多,我也将接受失败尝试的说法,基本上将问题扩展到“在开发基于JavaEE的web应用程序时如何(不)提高生产率?”。

    14 回复  |  直到 7 年前
        1
  •  49
  •   Cœur N0mi    6 年前

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

    • boring, ugly, “good enough” 一般来说, enterprises tend not to attract great developers 他们热爱编程,思考和关心自己的工作。企业界的软件质量不是很高。
    • 作为资金所在的企业,软件供应商试图向他们出售一些东西。他们创建了庞大、复杂和昂贵的解决方案,并不是因为它们很好,而是因为它们可以将它们销售给企业。
    • 之后 之前 . 在这两种情况下,这对企业(和Java)都是不利的。企业要么太晚使用好技术,要么彻底失败技术。后一种情况也是非常危险的,因为它产生了一种错误的观念,即如果一项技术是标准化的,并且每个人都在使用它,那么它(否则就是完全失败的)一定是好的。
    • 从历史上看,JavaEE平台似乎吸引了很多架构宇航员和大公司的开发人员,他们被提升为架构师,其唯一目的是创建更多的层、更多的框架、更多的抽象和更复杂的结构。

    在这样一个混乱的世界里,影响生产力的不仅仅是你选择的工具的特殊选择。主要是关于你,关于你的价值观,关于你如何拒绝社区、供应商、同事和管理者向你提出的大多数解决方案。这是关于你逆流而上,关于 你的 常识,关于

    也就是说,工具本身不会对你的生产力产生太大的影响,相反,合适的人也可以用劣质的工具来提高生产力。

    我的忠告是:

    • 不要仅仅因为某项技术是标准的,每个人都在使用它,或者因为它是Sun公司正式推荐的。只有当你个人认为技术是你工作的最佳工具时,才使用它。这样,您可能会发现自己拒绝使用JSF、JSP、Web服务、JMS、EJB、JTA、OSGi、MDA等技术。
    • 保持简单,运用你的常识,质疑一切。您真的需要发布对象以进行远程访问吗?您真的需要创建另一个抽象层以便从Hibernate切换到TopLink吗?您真的需要在每次需要时将数据与XML转换十次吗?您真的需要XML模式吗?你真的需要所有的东西都是可配置的并且是可互换的吗?在运行时?非开发人员?
    • agile
    • 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 你的代码可能很漂亮 .
    • 只需要一点Spring,您不需要太多,因为您已经小心地避免了所有JavaEE陷阱。少用依赖注入。
    • 在所有这些之后,您可能会发现Java语言过于冗长,在抽象复制/粘贴的代码时没有太大帮助。如果你想做实验,试试Scala。问题是Scala的主要卖点是,您可以在保持类型安全的同时,获得现代语言的所有好处,同时,没有 固体
        2
  •  6
  •   Pascal Thivent    15 年前

    框架如 Spring , Hibernate , Wicket 当然,这有助于简化和加速web开发,因为它们提供了高度的可测试性和良好的集成。但是,即使您有一套良好的开发实践,也不足以达到RoR生产率。仍然需要太多的技术人员和管道。

    Grails

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

        3
  •  5
  •   Anton Kuzmin    15 年前

    Javarebel

    让我在这里引用官方网站:

    JavaRebel是一个JVM插件(-javaagent),它使您能够立即看到代码的更改,而无需重新部署应用程序或执行容器重启。如果你厌倦了看着日志滚滚而过,想看看你的变化,这样你就可以继续下去——JavaRebel是你新的最好的朋友。

        4
  •  3
  •   Arjan Tijms Mike Van    11 年前

    遵守标准JavaEE规范是绝对重要的,例如,使用Hibernate而不是JPA对生产率没有好处。在使用JPA时,没有限制退回到Hibernate特性,但是通过使用Hibernate而不是JPA,您将被锁定在单个持久性提供程序中,没有廉价的出路。使用标准背后的整个想法是相同的:概念上的灵活性(通过插入不同的实现)和可用的可扩展性(如果绝对必要,通过使用专有扩展)。JavaEE5和EJB3是朝着这个方向迈出的巨大一步。当然,您希望最小化任何专有特性,但如果某些特性看起来绝对必要,这是一个好迹象,表明它们将成为下一版本规范的一部分。。。

    JavaEE生产率的主要障碍在于其企业重点(提供的远远超过大多数项目的需要)和遗留问题(向后兼容性)。在使用JSF和状态管理的表示层中还有很多工作要做——请注意 JSR-299

        5
  •  2
  •   Michael Borgwardt    15 年前

    Grails 是一个非常模仿RubyonRails的JavaWebApp框架,具有类似的原则(DRY、CoC)和生产率提高,但基于现有的Java框架(Spring、Hibernate等)。

    也许这个具体的例子最好地说明了这一点:我想在一个网页上编辑网格中的二维域对象数组,发现将生成的HTML请求数据自动映射到域对象(我相信是Spring MVC提供的)有一个bug,导致一些数据映射到错误的对象。我在网上浏览了一个小时,但显然没有人遇到或解决这个问题。最终,我决定放弃自动映射,而是“手动”进行映射,然后发现只需大约10行代码。。。

        6
  •  2
  •   Community Mike Causer    4 年前

    人们经常提到RoR和基于动态语言的类似框架是更高效的环境,但我真的很想知道是否有硬数据支持这一点。这并不容易,因为我们应该确定她不是在比较苹果和桔子。应该考虑项目类型(Web2.0,企业应用程序)和团队规模。然而,对于小型项目来说,很明显,这样的框架确实比JavaEE更有效率。这是一个简短的参数列表,用于支持这一点,以及在Java世界中可以为它们做些什么。

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

    同上。但在我看来,这是一个非常主观的论点。

    像Spring或Guice这样的依赖注入框架会有所帮助

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

    同样,Java MVC框架也可以提供帮助

    Hibernate、iBatis或其他ORM框架可以提供帮助。具有 Hibernate Tools 您可以通过yml文件在RoR中实现类似的功能

    Maven或Ant Ivy可以帮上忙

    易于部署以进行测试

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

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

        7
  •  1
  •   Juri    15 年前

    为什么是春天?

    非侵入性 “。通常,当您使用框架时,您很可能会开始依赖该框架,如果应用程序被认为要运行更长的时间,而您还必须进行维护等,那么这可能是一个坏问题。Spring使用所谓的 “控制反转”(IoC)模式 Spring减少了依赖性 通过配置文件和 Spring website

        8
  •  1
  •   Vasil    15 年前

    由于Jython2.5,您可以使用django来满足您列出的需求。从django项目生成war文件并将其部署到J2EE应用程序服务器上非常容易。

        9
  •  1
  •   Mike Stone    15 年前

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

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

    我们拥有对会话的完全访问权,甚至设置了从Rails页面调用JSP的机制(例如现有的页眉和页脚类型的JSP)。完全集成2需要一些努力和尝试,但如果Rails和JRuby是一个选项,我强烈推荐它(作为Ruby的个人粉丝)。

    一位同事涉猎了JBossSeam,这是Gavin King(给我们带来Hibernate的人)的一个框架,旨在模仿Rails。看过这两个版本后,我觉得Rails更容易开发。

        10
  •  1
  •   Thejesh GN    15 年前

        11
  •  1
  •   Damo    15 年前

    我用过 Jboss Seam 在过去的几年中,我发现用JavaEE(利用EJB3、Hibernate、Facelets)开发是一种非常高效的方法。我还做了一些奇怪的PHP编码,可以诚实地说,我使用Seam的效率更高(尽管这可能也是我PHP技能的一个标志)

    对我来说,几个亮点是:

    • 用小脸擦干
    • 基于注释的配置
    • Jboss工具的IDE支持

        12
  •  0
  •   Daniel O    15 年前

    我会和你一起去 Lift framework Scala . Scala也非常稳定,从Scala代码调用Java代码非常容易。不仅如此,它与Java非常相似,而且还增加了一些特性。有关一些示例,您应该参考 5 Things a Java developer needs to know about Scala. Twitter将把部分代码库转移到Scala。

    我将引用《升降机框架》的作者对其进行描述:

    Lift借鉴了现有的最佳技术 框架,提供

    • Django的“不只是包括积垢”
    • Wicket的设计师友好型模板样式(参见提升视图

    因为电梯的应用是 用Scala编写,一个优雅的新JVM 语言,你仍然可以使用你的 喜爱的Java库并部署到 您最喜欢的Servlet容器。使用 您已经编写的代码,并且 部署到已部署的容器

        13
  •  0
  •   Arjan Tijms Mike Van    11 年前

    一些基本规则:

    1. Kick out the appserver

    2. 使用Wicket实现您的web层-没有人再需要JSP了;Wicket的生产效率提高了10倍,而且易于测试(参见步骤2)。

    3. 使用SCRUM和敏捷开发方法

    Atomikos 我们有几个迁移项目是这样做的。因为我们从4GL平台迁移到Java/JavaEE,所以我们可以比较这两种平台的估计值。

    http://blog.atomikos.com/?p=87

        14
  •  -1
  •   User    15 年前

    嗯,我不是一个真正的Java人,所以我不能说太多,除了。。。JSF

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

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