相关链接

返回首页

认识安赫尔·莱昂纳德

发布者    |       讨论 Hibernate ORM 采访

在这篇文章中，我想向您介绍一位软件开发者、博主、书籍作者和Java EE爱好者——安赫尔·莱昂纳德。

Anghel Leonard, align=

嗨，瓦拉德，谢谢你的邀请。我叫安赫尔·莱昂纳德（Twitter上的@anghelleonard），我住在罗马尼亚的一个小村庄里，我是一名软件开发者，已经有17年的经验了，主要专注于Java和Web开发。我也是一个博主，并撰写了几本书。

我的职业生涯始于石油领域（Petrom S.A.）的一名Java开发者。主要在那里，我曾是开发石油模拟应用程序（旨在应用一些特定的数学模型）的团队的成员。之后，我们转向了Web应用程序（基于HTML、Servlets /JSP和Struts），并将数据库纳入其中（特别是MySQL和Visual FoxPro）。大约那时候，我开始使用Hibernate ORM的“原生”API。

简而言之，我开始学习Java EE（主要是JSF、EJB和JPA）和Spring。此后，我在GIS领域工作多年，开发RIA和SPA Web应用程序。从那时起，我一直在使用Hibernate对Java Persistence API（JPA）规范的实施。由于GIS RIA/SPA应用程序本质上需要处理大量数据（空间和非空间数据）并且必须快速运行，所以我一直对优化持久层的性能感兴趣。可以说，我见证了Hibernate的“成长”，并且一直努力了解它带来的每一个新功能和改进 :)

目前，我担任Java CA。在这里，我的主要任务是审查大量不同规模、技术和兴趣领域的项目。其中许多项目使用Hibernate“原生”API和Hibernate JPA。

您是一位多产的作家，已出版了关于JSF、Omnifaces、Hibernate、MongoDB甚至JBoss Tools的几本书。现在您正在自费出版您最新的书籍，您能否告诉我们与出版社合作和自行出版之间的区别？

我认为选择出版社或自费出版是一个权衡问题。根据我的经验，两边都有优点和缺点，我可以强调以下方面：

出版社与自费出版的优点

  • 出版社提供语法和拼写检查（这对于像我这样的非母语英语使用者来说可能是一个主要优势），以及技术审稿人（通常，作者也可以推荐审稿人），而在自费出版中，作者必须自己处理这些方面。

  • 出版社负责书籍的封面和目录，而在自费出版中，作者必须自己完成。

  • 出版社可能会认为作者非常出色，并就同一主题与他签订进一步合同，而在自费出版中，这种情况并不常见（至少我没有听说过）。

  • 出版社通过编辑、项目协调员、技术人员等提供写作过程中的持续和一致的帮助（通过电子邮件或Skype），而在自费出版中，这种帮助是不可用的。

  • 对于作者来说，费用是100%免费的，而在自费出版中，费用可能相差很大。

  • 出版社在市场上可能是强大的品牌。

出版社与自费出版的缺点

  • 出版社可能因不同原因拒绝一本书的提案（例如，他们已经有太多关于建议主题的书籍），而在自费出版中，被接受的机会要大得多。

  • 出版社只与截止日期工作（每个章节都有固定的日期，书籍有固定的日历），而在自费出版中，作者可以决定何时发布更新版本以及更新的程度。

  • 出版社为书籍问题提供“勘误表”（如错别字、错误、技术漏洞、内容准确性问题等），这些问题只能在下一次书籍版本中修复，而在自费出版中，作者可以立即修复这些问题。

  • 与自费出版相比，出版社通常支付的版税要小得多。

  • 通常，出版社每6个月支付一次版税，而在自费出版中，支付得更频繁。

  • 出版社在书籍大小、尺寸、格式、写作风格等方面不太灵活，而在自费出版中，这些坐标非常灵活。

  • 出版社要求成为书籍内容的唯一所有者，并禁止以任何其他形式或地点发布，而在自费出版中，这种限制并不总是适用。

  • 出版社设定书籍价格，而不咨询作者，而在自费出版中，作者可以设定价格（此外，作者可以在价格范围内选择价格）。

  • 出版社决定折扣和捐赠政策，而在自费出版中，作者可以提供优惠券、折扣和捐赠。

您最新的书籍叫做《Java Persistence Performance Illustrated Guide》。您能否更多地介绍您这个新项目？

当然可以。

最初，这本新书的内容并不是为了成为任何一本书的一部分。故事是这样的：随着时间的推移，我收集了关于Java持久化层（JPA、Hibernate、SQL等）的最好在线文章，并且在桌子上，我有关于这些主题的一些最令人惊叹的书籍。

如果您说您的博客和书籍，即《High-Performance Java Persistence》是这些收集中的主要部分，您不会感到惊讶。

为了减轻与持久化层相关的性能问题，我强烈且持续地向涉及持久化层的开发者推荐这些资源，但剩下的问题是：在日常工作日中，团队成员如何能够快速理解/识别性能问题以便修复它？

在那个时刻，没有时间学习，所以我决定采取一种新的方法：绘制一个特定的性能问题，并在5-15分钟内讨论这幅图（毕竟，“一张图胜过千言万语”）。这样，听众可以快速理解/识别问题并获得修复它的提示。

此外，我把这些图发到了Twitter上，令人惊讶的是，即使没有文字（谈话），它们也受到了欢迎。随着时间的推移，我收集了大量的图，人们开始问我是否会把它们发布到某个地方（我记得我们还在Twitter上谈过这个问题）。就这样，书的想法诞生了。：）

选择自出版方式的主要原因是我不受固定截止日期的约束。我唯一做的额外工作就是找人制作封面——它是由一位杰出的画家，弗洛里安·巴桑先生设计的。

现在，这本书的目标是作为需要处理持久化层性能问题的开发者的快速插图指南（SQL、JDBC、JPA、Hibernate（涵盖最多）和Hazelcast）。

每幅图都附有对问题的简要描述和解决方案。它就像“急救”，一个快速且浓缩的食谱，可以遵循一个扩展且详尽的带有示例和基准的文章，就像你在博客上看到的那样。

我审查的大多数应用程序都是基于Java EE和Spring的应用程序。由于大多数性能损失都源于持久化层，我试图列出最频繁的编程错误，这些错误导致了这些问题（这个趋势是根据来自不同项目的约300个PR计算得出的，并且仍在进行中）

  1. 拥有过长或无用的事务（例如，在Spring控制器中使用@Transactional在类级别上委托任务到“重”服务或永不与数据库交互）

  2. 避免使用PreparedStatement绑定参数，并在SQL查询中使用“+”连接来设置参数。

  3. 从数据库中获取过多的数据，而不是使用DTO、LIMIT/ROWNUM/TOP和JOIN的组合（例如，在最坏的情况下：一个只读查询（标记为只读或不）检索所有实体，然后在一个返回的集合上创建流，之后执行findFirst流终端操作以进一步检索和使用单个实体）。

  4. 错误配置批处理（团队生活在批处理在幕后工作的感觉中，但他们没有检查/检查实际的SQL语句和批处理大小）

  5. 错误使用或缺少事务边界（例如，省略只读查询的@Transactional或为必须在一个事务中运行的多个SQL语句执行单独的事务）

  6. 忽视数据是懒加载的事实。

  7. 不要依赖于连接池或避免调整连接池（应该大力推广Flexy Pool）。更糟糕的是，将连接数增加到300、400。

  8. 使用单向一对一关联，包括插入和删除实体操作

  9. 为所有SQL语句使用CriteriaBuilder，并依赖于幕后生成的任何内容

  10. 缺乏对Hibernate特性的了解（例如，属性懒加载、字节码增强、延迟DB连接获取、抑制发送DISTINCT到数据库等）

我们始终重视用户的反馈，所以请您告诉我们您希望我们改进的地方，或者是否有我们应支持的新功能？

首先，我想祝贺整个Hibernate团队，因为他们做得非常出色！我真的很喜欢最新的特性和文档中的全面改进。考虑到我所参与的应用类型，我希望Hibernate - CDI集成能够尽快完成。

感谢Leonard抽出宝贵时间。有您在这里是一种巨大的荣幸。要联系Leonard，您可以在Twitter上关注他。

返回顶部