我们正在使用Netbeans实用程序从数据库表生成实体类,现在我们可以在这里进行vise-a-verse。从表到实体POJO和反向,所以当我们在实体POJO中进行任何更改时 - 我们将获得更新的SQL。
Eclipse也有类似的实用程序可用于JPA,但它没有反向,现在问题是从表中生成实体POJO时我们无法选择命名约定。我们得到的所有字段名称都是小写的,并且同样适用于没有任何东西仅仅是大写字母的第一个字母而小写字母的字体。
现在这似乎在创建我们定义的编码标准的问题,因为它要求我们使用camel-casing作为变量和方法名称。
所以我们与团队进行了讨论,其中一个想法是将所有变量保持在整个项目中的小写,我个人不同意,因为它使代码非常难以理解,因为我们不打算使用下划线来分隔单词。您可以就此标准进行投票。
您认为最好的出路是什么?是否有任何实体POJO生成器可以转换两种方式,并且仍然能够在发现得分不足时从db表名称转换为camel-casing?
答案 0 :(得分:2)
最好的解决方案是立即停止并转移到标准的Java命名约定:
#define
)。 enum
字段建议使用相同的内容(但此建议并不严格)如果我忘记了什么,我很抱歉。但遵循大多数开发人员适用的命名和编码约定非常重要。首先,这些惯例基于非常大的经验。不要以为你可以改进它们。你不能。我不能。 :) 第二个以下编码约定使您的代码可以被其他人理解,并避免愚蠢的错误。
答案 1 :(得分:2)
我使用dali和eclipse进行实体生成,如果你不能设置naming you require,会感到惊讶。
另外,我想intellij允许你根据需要也这样做。
答案 2 :(得分:2)
您认为最好的出路是什么?
遵循Java样式约定。周期。
是否有任何实体POJO生成器可以转换两种方式,并且仍然能够在发现得分不足时从db表名称转换为camel-casing?
我不知道。
但如果找不到,请使用现有的开源生成器并修改以执行您想要的操作。然后将补丁提供给项目,以便其他人可以从您的工作中受益。
答案 3 :(得分:1)
[...]一个想法是在项目[...]
中保持所有变量小写
忘记这一点。你在Java土地上。这意味着所有其他框架都不会遵循该标准,因此您将永远不会只有一种干净的编码风格。 Java的优点之一就是 The One Style ,这使得阅读外国代码变得更加容易。
因此,应该尝试将其包含在可能的最小空间中 - 在您的情况下,工具生成的东西。下一步是改进或删除该工具。