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

22

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

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

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

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

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

  1. id: атрибут идентификатора объекта. в терминах базы данных суррогатный ключ не является естественным ключом.
  2. Объект: объект или иным образом уникально идентифицируемый объект в системе.
xenoterracide
источник
1
Чтобы оставаться абстрактным, если нет причин хранить информацию, не храните ее. Это просто создает головные боли.
3
Если вы не знаете уникальный ключ объекта, как бы вы обновили данные в базе данных или позволили пользователю выбрать вхождение в списке?
NoChance
@EmmadKareem я говорю о том, что коллекция (хранилище) знает идентификатор, поэтому зачем нужен сам объект. Если бы я рендерил список, я бы, вероятно, рендерил коллекцию, которая знает идентификаторы.
ксенотеррацид
Если вы не используете идентификатор, который хранится вместе с объектом, и никогда не собираетесь или не хотите его использовать, его явно не нужно.
GrandmasterB
@GrandmasterB хорошо, конечно, вы используете идентификатор, вопрос в том, сохраните ли вы идентификатор в памяти вместе с объектом, и почему.
ксенотеррацид

Ответы:

8

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

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

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

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

Е.Л. Юсубов
источник
2
почему они должны быть включены в объект, а не просто в коллекцию (при условии, что коллекция - это своего рода словарь)?
ксенотеррацид
я хотел сказать, что если вы хотите идентифицировать свой объект, вам нужен идентификатор. это может быть Id, дата-время и т. д ... все, что идентифицирует ваш объект от других.
Е.Л. Юсубов
1
Ну, конечно, мой вопрос больше в том, почему сам объект должен знать об этом идентификаторе.
ксенотеррацид
Чтобы пояснить немного, я имею в виду суррогатный идентификатор, обычно такие вещи, как числа типа datetime или vin, являются естественными и, следовательно, частью данных, а не id
именуются
6

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

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

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

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


источник
в каких случаях ему удобно знать свой идентификатор? Я размышлял об этом и думал, что большинство из них может быть просто основано на том, как это было закодировано, возможно, цикле for, используемом для рендеринга, obj.idа не на рендеринге самой коллекции.
ксенотеррацид
1
@xenoterracide - один из примеров - асинхронный просмотр и обновление записей в БД. В некоторых случаях у меня не будет достаточной информации для уникальной идентификации записи, за исключением ее идентификатора, поэтому имеет смысл сохранить идентификатор вместе с объектом записи.
но это причина или следствие? это требование? если ваш репозиторий / коллекция / datamapper (или некоторая их цепочка) отвечает за сохранение обновлений, и он знает идентификатор и может передать его ... Я пытаюсь понять, есть ли причина для его следования или если это происходит потому, что многие люди используют активный шаблон записи.
ксенотеррацид
@xenoterracide - в тех случаях, о которых я думаю, это определенно было причиной. В некоторых случаях, в которых я был, было намного удобнее сохранять идентификатор, связанный с объектом. Ваш вопрос был хорош, потому что он поставил под сомнение исходное предположение, которое делают многие люди. Мы склонны учиться, когда копаемся в таких предположениях. С другой стороны, не переусердствуйте в анализе и идите в противоположном направлении. В противном случае вы в конечном итоге сделаете то же самое время священных заявлений, что вы в первую очередь сломали.
4

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

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

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

Арсений Мурзенко
источник
4

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

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

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

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

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

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

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

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

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

xenoterracide
источник
2

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

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

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

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

scrwtp
источник
2

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

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

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

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

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

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

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

Пол Томанн
источник