Должен ли объект знать свой собственный идентификатор?

obj.idкажется довольно распространенным, а также, кажется, попадает в диапазон того, что объект может знать о себе. Я спрашиваю себя, почему мой объект должен знать свой собственный идентификатор?

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

Я также однажды столкнулся с проблемой, когда я хотел сериализовать объект в JSON для RESTful API, где идентификатор, по-видимому, не помещался в полезную нагрузку, но только URI и включение его в объект сделали это более трудным.

Должен ли объект знать свой собственный идентификатор? Почему или почему нет?

Обновление : Условия

1. id: атрибут идентификатора объекта. в терминах базы данных суррогатный ключ не является естественным ключом.
2. Объект: объект или иным образом уникально идентифицируемый объект в системе.

Краткий ответ: включение идентификатора объекта в объект является обязательным условием, если на него будет ссылаться.

Для сценария, в котором вы планируете использовать коллекцию объектов и планируете ссылаться на отдельный объект / сущность, следует включить идентификатор. Однако могут быть случаи, когда естественный ключ / идентификатор, такой как, DateTimeможет искусственно удовлетворить эту потребность.

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

Редактировать: если вы хотите идентифицировать свой объект, вам нужен идентификатор. Этим идентификатором может быть суррогатный идентификатор, дата-время, guid и т. Д., В общем, все, что уникальным образом идентифицирует ваш объект от других.

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

Объект должен знать свой собственный идентификатор, если это необходимо.

Объект не должен знать свой идентификатор (или, что он даже есть), если ему это не нужно.

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

Довольно часто включать идентификатор, но также часто используют словари, то есть структуры данных, где каждый объект связан с его идентификатором таким образом, что вы можете легко извлечь этот объект, зная соответствующий идентификатор, но объект не знает Это.

Например, если вы создаете API двумя методами:

• http://api.example.com/products/

  Загружает список идентификаторов продуктов.

• http://api.example.com/product/452/

  Загружает продукт с идентификатором 452.

Тогда вам не нужно повторно отправлять ID 452 в ответе JSON на второй запрос. Пользователь API уже знает идентификатор.

Я думаю, что это субъективно и зависит от вашего дизайна.

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

При использовании других шаблонов, таких как хранилище с картографом данных, сохранение этих данных в объекте становится ненужным и, возможно, неуместным.

Возьмите для примера Personобъект. Мне дано имя, которое может быть или не быть уникальным в семье. Поскольку население увеличилось, имена больше не являются уникальными, и поэтому мы придумали суррогатные идентификаторы для все более крупной системы. Примеры этого включают в себя: мои водительские права и номер социального страхования. Я не родился с присвоенным идентификатором, все эти идентификаторы должны быть применены.

Большинство из них не делают хорошие первичные ключи / идентификаторы для программного обеспечения, поскольку они не универсальны. По крайней мере, вне их конкретной системы, очевидно, что SSN является уникальным и непротиворечивым для Администрации социального обеспечения. Поскольку мы, как правило, не являемся поставщиками этой информации, вы бы не называли их, idа скорее представляли данные, которые они представляют, например SSN. Иногда даже содержат полностью составленный объект, например, DriversLicenseкоторый может содержать всю информацию, которую содержит водительское удостоверение.

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

Поскольку an idне является частью концептуальных данных, я сомневаюсь, что они (как правило) принадлежат к объекту, так как они не принадлежат области. Скорее это должно быть сохранено для его цели, которая состоит в том, чтобы идентифицировать объект, у которого нет никакого другого способа представить уникальную идентичность. Это может быть сделано в хранилище / коллекцию с легкостью.

В программном обеспечении, если вам нужно представить объект в виде списка или сохранить его, вы можете просто сделать это из объекта репозитория / коллекции или какого-либо другого объекта, связанного с этим. При переходе к Data Mapper (если он отдельный) вы можете просто пройти .update( id, obj ).

Отказ от ответственности : я еще не пытался создать систему, которая не содержит идентификатор в сущности и, таким образом, может оказаться неправым.

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

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

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

В вашем случае, если вы только извлекаете данные из БД и проталкиваете их через веб-сервис, правильное решение может быть оставлено без идентификатора. Я просто не верю, что это имеет больше смысла, чем сохранение его в общем случае.

Вы правы, вам не нужно хранить идентификатор в объекте, если вам нужно знать его только в контексте вашего хранилища.

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

В этой ситуации у вас есть два варианта:

• ввести новый аргумент функции 'id' во всей цепочке функций между контекстом хранилища и функцией, где нужен идентификатор

• включить идентификатор в объект

В большинстве этих случаев хранение идентификатора внутри объекта будет лучшим решением. Это также уменьшит изменения кода, когда идентификатор необходим в непредвиденных местах, плюс это может быть полезно при отладке.

Вот почему я делаю это, когда я делаю это.