Объект называет по сравнению с именами таблиц

В качестве компромисса вы можете использовать такие имена, как TB_CUST , где действовать напрямую с базой данных, но затем использовать имена, такие как Customer, для ваших объектов передачи данных. Написание хорошего кода включает в себя создание абстракции любых источников данных, с которыми вы можете работать. Использование GetTB_CUST () во всем вашем коде немного похоже на то, чтобы GetTB_CUSTFromThatSQLDatabaseWeHave () разбросаны по всему месту.

Кто будет больше всего работать с новым кодом? Этот человек должен решить соглашение об именах. ИМХО.

Лично я, конечно, выбрал бы ваше решение, потому что, как уже упоминалось, если вы используете ORM, вам не нужно часто обращаться к БД напрямую.

Я лично ненавижу подобные имена таблиц, но это устаревшая система, и я уверен, что администратор баз данных не хочет переименовывать таблицы. Переименование таблиц может быть вариантом. Вам просто нужно будет создать представления, представляющие старые имена таблиц, чтобы ваша устаревшая система продолжала работать, пока вы разрабатываете новую систему. Если это не вариант, вы можете использовать ORM для сопоставления имен таблиц с именами сущностей. Или вы можете абстрагироваться от ORM на уровне доступа к данным и определять красивые имена сущностей в своей модели предметной области, при этом ваш DAL выполняет преобразование имен.

Соглашения об именах, используемые в двух разных доменах, просто не совпадают. Java, например, имеет очень хорошо определенные правила / соглашения для имен классов и имен полей , где использование заглавных букв имеет значение. В общем, ваше приложение может быть перенесено в совершенно другую базу данных с другим стандартом именования, неразумно требовать согласования имен в Business Logic с именами в базе данных. Рассмотрим немного более сложное отображение, одна сущность может не соответствовать одной таблице.

И, действительно, давай ...

 Customer == TB_CUST

Это просто не так сложно! Я с вами, делаю имена значимыми в коде и отображаю в ORM. Обучение для администратора базы данных / программиста не должно быть таким болезненным, я полагаю, что это '

GetMapEntry не статический , поэтому вы не можете вызвать его без объекта типа ThreeDCubeGame.

Альтернативы:
(и, следовательно, самодокументированное значение) кода.

Это правда, что getTP_COMP_CARS выглядит некрасиво (хотя и не, как вы утверждаете, «нечитаемым»). Верно также и то, что если вы начнете придерживаться «более современных» соглашений об именах, то где-то должен быть кто-то, кто будет поддерживать сопоставление между именами, которые являются синонимами. (И неверно, что такие имена, как TP_COMP_CARS, менее самодокументируются, чем полные имена «естественных слов»: обычно такие имена состоят из ОЧЕНЬ МАЛЕНЬКОГО набора мнемонических слов, которые используются снова и снова с одним и тем же значением. , что делает их более чем достаточно легкими для запоминания.)

В этом нет правильного и неправильного. Подобные имена были обычным явлением в дни до тех, в которых мы живем сейчас. Как минимум,

Если в базе данных 500 таблиц - у вас уже есть проблема сохранить эти имена прямо. Надеюсь, у вас есть метаданные и некоторые графические модели, которые описывают их более осмысленно.

Когда вы создаете следующие 500 объектов ORM, у вас будет еще одна проблема. Даже если вы дадите им многозначительные имена, их все равно будет слишком много, чтобы действительно надеяться, что все будет очевидно. Итак, теперь у вас есть 2 проблемы.

Если нет возможности связать эти два набора по 500 таблиц вместе - значит, у вас 3 проблемы. Подумайте об отладке производительности запросов в ORM и обращении к администратору базы данных с именами, которые он не узнает. Подумайте о своих тщательно созданных именах - их следует игнорировать при создании отчетов, которые напрямую попадают в базу данных.

Итак, я ' Я очень стараюсь использовать имена баз данных в ORM. Но я бы подправил несколько вещей:

• если имя слишком загадочно для понимания - я бы работал с администратором баз данных, чтобы улучшить его. Простой способ перейти к лучшим именам - это просмотры. В идеале вы со временем избавитесь от оригинального запутанного имени, хотя
• переход с подчеркивания на верблюжий регистр и т. Д. Не следует рассматривать как изменение имени - это просто изменение разделителя. Итак, используйте имя, соответствующее вашему языку.
• префиксы базы данных, вероятно, можно отбросить - на самом деле они просто атрибуты имени таблицы, которые были «денормализованы» и привиты к имени. Они могут быть необходимы, чтобы избежать дублирования, если они указывают на часть модели, но в целом могут иметь не меньшее значение.