Разве плохо иметь бессмысленные ключи в моих классах модели домена?

Question

При создании модели предметной области у нас почти всегда есть поле или свойство Id для наших сущностей, которое представляет столбец первичного ключа соответствующей таблицы в базе данных. У меня вопрос: если у меня есть это ключевое свойство, которое не имеет ничего общего с моделью домена (другими словами, это просто проблема с базой данных; Мартин Фаулер предпочитает называть его бессмысленным ключом ) , слой персистентности просачивается в мой домен? И если это так, как я могу предотвратить это?

Answer 1

Посмотрите на проблему по-другому: сокрытие первичных ключей облегчит вашей команде для разработки решения или сделает его даже сложнее ?

Не беспокойтесь о «утечке» значений PK в ваши сущности - я уверен, что у вашего программного обеспечения есть большие проблемы, которые необходимо решить.

Answer 2

Убедитесь, что значимые ключи также указаны в модели. Включение суррогатов может быть необязательным, но включение значащих ключей, которые имеют смысл ваших данных в реальном мире, гораздо важнее.

Answer 3

Из большой книги под названием: Системы баз данных - Полная книга .

Ключи - это атрибуты или наборы атрибутов, которые однозначно определяют сущность вего сущность установлена.Никакие два объекта не могут согласовать свои значения для всех атрибутов, составляющих ключ.Однако допустимо для двух организаций, чтобы согласовать некоторые, но не все, атрибуты.

-

Наш опыт [...] может заставить нас поверить, что трудно найти ключи или быть уверенным, что набор атрибутов образует ключ.На практике дело обычно намного проще.В реальных ситуациях, обычно моделируемых базами данных, люди часто стараются изо всех сил для наборов сущностей.Например, компании обычно присваивают идентификаторы сотрудников всем сотрудникам, и эти идентификаторы тщательно выбираются, чтобы быть уникальными номерами.Одна из целей этих идентификаторов состоит в том, чтобы в базе данных компании можно было отличить каждого сотрудника от всех других, даже если есть несколько сотрудников с одинаковыми именами.Таким образом, атрибут employee-ID может выступать в качестве ключа для сотрудников в базе данных.

Хотя сущности, отличающиеся только вставленным искусственным идентификатором, могут представлять собой дублирующие (избыточные) данные, их использованиедалеко от бессмысленно .Дополнительный способ различения различных доменных сущностей, на мой взгляд, не мешает самому домену.

Но что касается ответа на ваш вопрос:

Не просачивается ли слой постоянства вмой домен?И если это так, как мне это предотвратить?

Если вы действительно, очень хотите.Вы можете использовать комбинацию атрибутов сущности для определения ключей сущности.

Надеюсь, это поможет.