我们将在传统数据库（使用.NET C＃）上开发一个新系统，大约有500个表。我们选择为我们的数据访问层使用ORM工具。问题在于实体的namig约定。实体名称与表名
数据库中的表格有名称，如TB_CUST - 包含客户数据的表格或TP_COMP_CARS-公司汽车。前缀的第一个字母定义模块，第二个字母定义与其他表格的关系。
我想命名实体更有意义。像TB_CUST只是客户或客户实体。当然会有一个注释指向它的表名。
但是DBA和程序员在一个人，不要这样的名字。他希望实体名称与表名完全相同。他说他必须记住两个名字，这将是困难和混乱。我不得不说他不太熟悉面向对象的原理。
但是如果像TP_COMP_CARS这样的实体名称应该有方法名称，如Get TP_COMP_CARS或SaveTP_COMP_CARS ..我认为这是不可读和丑陋的。
所以请告诉我你的意见。谁是对的，为什么。
预先感谢您
的ORM工具的整体思路，是避免记忆数据库对象的需要。 我们通常创建一个包含所有表和列名的数据库类，所以没有人需要记住任何东西，ORM应该将数据库“名称”映射到普通实体。
虽然它是主观的，在我看来，你是对的，他是错的....
谁来用新的代码大多是工作？那个人应该决定命名惯例恕我直言。
的个人当然，我会去你的解决方案，因为前面已经提到的，如果你使用ORM你不需要打DB直接频繁。
我不同意第一部分。如果将要使用代码的人改变，该怎么办？ – 2009-12-04 10:21:08
看看我是第一个选择改变名称以符合范例的人。我只是想找出硬币的这一面。但我并不坚持这一点。我希望我不会对我的观点得到更多的否定:-) – Petros 2009-12-04 10:38:03
+1为什么选择倒票？人刚刚表达了他的看法，这正是你的问题。错误信息可能是反对票，但分歧不应该是反对票。 – 2009-12-22 10:19:23
正如你可以使用的名称，如TB_CUST其中的行为直接与数据库但后来使用的名称，如客户对您的数据传输对象的妥协。编写好的代码涉及到创建可能正在使用的任何数据源的抽象。整个代码都有GetTB_CUST()有点像在这个地方点缀着GetTB_CUSTFromThatSQLDatabaseWeHave()。
在两个不同域中使用的命名约定根本不对齐。 Java中，例如，哈萨很好定义的规则/惯例类名和场名，其中资本是显著。通常，您的应用程序可能会移植到具有不同命名标准的完全不同的数据库，因此要求业务逻辑中的名称与数据库中的名称保持一致是不合理的。考虑一个稍微更复杂的映射，一个实体可能不对应一个表。
而且，真的，拜托...
Customer == TB_CUST
这只是不是那么难！我和你在一起，使得这些名字在ORM中的代码和映射中有意义。对于DBA /程序员的学习不应该那么痛苦，我的猜测是这些事情在预期中比现实感觉更糟。
以及GC_SU和S_OE或TB_FAKOE如何？我不知道那里有什么:-) – user137348 2009-12-04 09:34:34
这就是为什么你应该从数据库中删除原来的名字。如果它需要查找一些过时的文档来了解字段的含义，那么编码时可能会犯错误。因此，您可以将ORM映射看作字段含义的实际文档。好多了。 – 2009-12-04 11:34:45
我个人很讨厌这样的表名，但它是一个遗留系统，我确信DBA不喜欢重命名表。重命名表可能是一个选项。您只需创建代表旧表格名称的视图，以便在开发新系统时您的遗留系统继续运行。如果这不是一个选项，您可以使用ORM将表名映射到实体名称。或者，您可以将数据访问层中的ORM抽象出来，并在域模型中定义好的实体名称，让您的DAL进行名称转换。
“我不得不说，他没有真正熟悉OOP的原则。
但在像TP_COMP_CARS实体名称的情况下，应该有方法的名字，如获取TP_COMP_CARS或SaveTP_COMP_CARS..I认为这是不可读丑，
所以请告诉我你的意见，谁是对的，为什么。
哪些名称给予您的IT系统管理的东西完全与“OOP原则”无关。
对于“标准”“getter和setter”方法的名称也是如此：这些只是协议和约定，而不是“OOP原则”。
问题是代码的某种“人体工程学”（因此也是自我记录的价值）。
确实，getTP_COMP_CARS看起来很丑陋（尽管不是，正如你声称的那样，“不可读”）。同样，如果你开始遵守“更现代”的命名规则，那么就必须有某个地方需要维护同义名称之间的映射。 （和TP_COMP_CARS这样的名称比完整的“自然语言词”名称更少自我记录是错误的：通常这样的名字是由一组非常小的助记词构成的，它们一遍又一遍地用于相同的意义，让任何人都能够记住它们，这足够简单。）
对此没有正确和错误。像我们现在居住的那些日子那样的名字是通常的惯例。至少，这些名称通常具有不区分大小写的好处，与由所谓的“更现代”系统强加给我们的braindead（因为区分大小写）命名规则相反。
从现在起二十年后，人们会称这些天我们使用的命名约定“braindead”。
如果数据库中有500个表 - 你已经有了一个挑战，保持这些名字直。希望你有元数据和一些更有意义的图形模型。
当您创建接下来的500个ORM对象时，您将面临另一个挑战。即使你给他们有意义的名字，它仍然太多，真的希望一切都会变得明显。所以，现在你有两个问题。
如果没有办法将这两组500个表连接在一起 - 那么你有3个问题。考虑调试ORM中查询的性能，并以他无法识别的名称前往DBA。考虑一下你精心设计的名字 - 当你创建直接打到数据库的报表时，必须忽略它。
所以，我会尽量使用ORM中的数据库名称。但我会调整一些东西：
+1这就是ORM的要点：摆脱braindead表命名约定:) – 2009-12-04 09:25:41
这是现有的DBA/Programmer家伙的一些痛苦，他有他的美好的世界，对他而言这是改变。但在这种情况下，我重视在业务逻辑中仔细选择域名以节省一些工作。 – djna 2009-12-04 09:51:57
+1 - 我还可以补充一点：ORM工具意味着您可以开发应用程序层，而无需对精确的表名和列名进行硬编码。存储过程和硬编码SQL使得难以重构数据。在应用程序层中良好地使用ORM和类型安全的实体对象使重构数据变得容易得多。 – 2014-07-29 08:19:31