Имена объектов против имен таблиц

Question

Мы собираемся разработать новую систему на основе унаследованной базы данных (с использованием .NET C #). Всего около 500 таблиц. Мы решили использовать инструмент ORM для нашего уровня доступа к данным. Проблема заключается в соглашении намиг для сущностей.

Таблицы в базе данных имеют такие названия, как TB_CUST - таблица с данными клиента или TP_COMP_CARS - служебные автомобили. Первая буква префикса определяет модуль, а вторая буква определяет его отношение к другим таблицам.

Я хотел бы назвать сущности более значимыми. Как TB_CUST просто Customer или CustomerEntity. Конечно, был бы комментарий, указывающий на имя таблицы.

Но администратор БД и программист в одном лице не хотят таких имен. Он хочет, чтобы имена сущностей точно совпадали с именами таблиц. Он говорит, что ему придется запомнить два имени, и это будет сложно и грязно. Скажу сразу, его не очень знакомы с принципами ООП.

Но в случае имени сущности, подобного TP_COMP_CARS, должны быть имена методов, подобные Get TP_COMP_CARS или SaveTP_COMP_CARS .. Я думаю, что это нечитабельно и безобразно.

Поэтому, пожалуйста, скажите мне ваше мнение. Кто прав и почему.

Заранее спасибо

Answer 1

Вся идея инструментов ORM состоит в том, чтобы избежать необходимости запоминания объектов базы данных. Обычно мы создаем класс базы данных со всеми именами таблиц и столбцов, поэтому никому ничего не нужно запоминать, и ORM должен сопоставлять «имена» базы данных с обычными объектами.

Хотя это субъективно, на мой взгляд, вы правы, а он неправ ....

Answer 2

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

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

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

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

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

Answer 3

«Я должен сказать, что он не очень знаком с принципами ООП.

Но в случае имени объекта, такого как TP_COMP_CARS, должны быть имена методов, такие как Get TP_COMP_CARS или SaveTP_COMP_CARS..Я думаю, что это нечитаемо и некрасиво.

Поэтому, пожалуйста, скажите мне свое мнение. Кто прав и почему. "

Какие имена присваиваются тем, что управляет вашими ИТ-системами, абсолютно не связано с «принципами ООП».

То же самое относится к именам, которые присваиваются «стандартным» методам «получения и установки»: это просто соглашения и соглашения, а не «принципы ООП».

Проблема заключается в некой эргономике (и, следовательно, в самодокументированном значении) кода.

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

В этом нет ничего правильного или неправильного. Такие имена были обычным соглашением в те дни, когда мы жили сейчас. По крайней мере, эти имена обычно имеют преимущество, заключающееся в том, что они нечувствительны к регистру, в отличие от правил именования (потому что они чувствительны к регистру), которые навязывают нам так называемые «более современные» системы.

Через двадцать лет люди будут называть соглашения об именах, которые мы используем в эти дни, тоже "мозговой смертью".

Answer 4

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

Answer 5

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

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

 Customer == TB_CUST

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

Answer 6

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

Answer 7

Кто будет работать в основном с новым кодом? Этот человек должен принять решение об именовании IMHO.

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