¿Debe un objeto conocer su propia identificación?

obj.idparece bastante común y también parece estar dentro del rango de algo que un objeto podría saber sobre sí mismo. Me pregunto por qué mi objeto debe conocer su propia identificación.

¿No parece tener una razón para tenerlo? Una de las principales razones para que exista es recuperarlo, por lo que mis repositorios necesitan saberlo y, por lo tanto, usarlo para la interacción con la base de datos.

También una vez encontré un problema en el que quería serializar un objeto a JSON para una API RESTful donde la identificación no parecía encajar en la carga útil, pero solo el URI e incluirlo en el objeto lo hizo más difícil.

¿Debería un objeto saber que es su propia identificación? ¿por qué o por qué no?

actualización : Términos

1. id: atributo identificador en un objeto. en términos de base de datos, una clave sustituta no es una clave natural.
2. Objeto: una entidad u otro objeto identificable de forma única dentro del sistema.

Respuesta corta: incluir un identificador de objeto dentro del objeto es imprescindible si va a ser referido.

Para un escenario en el que planea usar una colección de objetos y tiene planes para referir un objeto / entidad individual, se debe incluir el identificador. Sin embargo, puede haber casos en los que la clave / identificador natural como DateTimepuede satisfacer artificialmente esa necesidad.

Además, puede tener sus DTO como un contenedor liviano de su objeto, que puede omitir / incluir un identificador de objeto en sí mismo. Realmente todas estas opciones dependen realmente de los casos y necesidades de uso de su negocio .

Editar: si desea identificar su objeto, debe tener un identificador. Ese identificador puede ser un Id sustituto, fecha-hora, guid, etc., básicamente, cualquier cosa que identifique su objeto de otros de una manera única.

En un intento de dejar mi respuesta tan abstracta como su pregunta, creo que realmente ha respondido su propia pregunta.

Un objeto debe conocer su propia ID si es necesario.

Un objeto no debería conocer su ID (o que incluso tiene uno) si no es necesario.

Como señaló, hay casos en los que es inconveniente o innecesario que el objeto retenga o sepa si es su ID. Pero hay otros casos en los que es más conveniente que el objeto conozca su ID. Codifique sus objetos según sea apropiado para su uso.

Es bastante común incluir la ID, pero también es común usar diccionarios, es decir, las estructuras de datos donde cada objeto está asociado con su ID de una manera que puede recuperar fácilmente este objeto conociendo la ID correspondiente, pero el objeto no sabe eso.

Por ejemplo, si está creando una API con dos métodos:

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

  Carga la lista de ID de productos.

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

  Carga un producto de ID 452.

Entonces no necesita reenviar el ID 452 en la respuesta JSON de la segunda solicitud. El usuario de la API ya conoce la ID.

Creo que esto es subjetivo y depende de su diseño.

Principalmente, aunque parece ser un diseño que proviene de un registro activo . En un registro activo, su entidad tiene métodos para realizar operaciones de base de datos y, por lo tanto, también debe conocer su identificador de base de datos.

Cuando se utilizan otros patrones, como un repositorio con un mapeador de datos, almacenar estos datos en el objeto se vuelve innecesario y quizás inapropiado.

Tomemos por ejemplo un Personobjeto. Me dan un nombre que puede o no ser único dentro de una familia. A medida que la población ha crecido, los nombres más grandes ya no son únicos, por lo que hemos creado identificadores sustitutos para un sistema cada vez más grande. Ejemplos de estos incluyen: mi licencia de conducir y número de seguro social. No he nacido asignado una identificación, todas estas identificaciones deben ser solicitadas.

La mayoría de estos no son buenas claves / identificadores primarios para el software, ya que no son universales. Al menos no fuera de su sistema específico, obviamente un SSN es único y consistente para la Administración del Seguro Social. Dado que generalmente no somos los proveedores de esta información, no los llamaría idsino los datos que representan, por ejemplo SSN. A veces, incluso contienen el objeto compuesto completo, como el DriversLicenseque podría contener toda la información que contiene la licencia de conducir.

Por lo tanto, todas las identificaciones generales son claves sustitutas en el sistema, y ​​podrían reemplazarse con referencias en la memoria, que solo contienen identificaciones para facilitar la búsqueda y los registros persistentes.

Dado que un idno es un dato conceptual, dudo que (generalmente) pertenezca al objeto, ya que no proviene del dominio. Más bien, debe mantenerse para su propósito, que es identificar un objeto que no tiene otra forma de representar una identidad única. Esto podría hacerse en un repositorio / colección con facilidad.

En el software, si necesita representar el objeto como una lista, o persistirlo, simplemente puede hacerlo desde el objeto de repositorio / colección, o algún otro objeto asociado con eso. Al pasar al Data Mapper (si está separado), simplemente puede pasar .update( id, obj ).

Descargo de responsabilidad : todavía no he intentado construir un sistema que no contenga la identificación dentro de la entidad y, por lo tanto, puede demostrar que estoy equivocado.

Como GlenH7 señaló en un comentario, es una buena pregunta, porque desafía lo que muchas personas dan por sentado. Sin embargo, mi opinión es que incluso si dejar la identificación fuera puede parecer conceptualmente puro, lo más pragmático sería mantener la identificación con el objeto en la mayor cantidad de capas posible del sistema. Cuesta poco, pero puede ser útil cuando las cosas comienzan a deteriorarse.

Es posible que una entidad no necesite saber su identificación, al igual que una persona no necesita saber su número de identificación personal, número de licencia de conducir ni ningún otro identificador que pueda estar en uso en su ubicación. Ciertamente podría prescindir de él la mayor parte del tiempo. Sin embargo, es aconsejable llevar algún tipo de identificación, por si acaso.

Lo mismo puede decirse de un objeto. Independientemente de las complejidades de la capa de acceso a datos, el objeto finalmente se asigna a una determinada entrada de la base de datos. Esta entrada solo puede ser identificable de forma única por la identificación del objeto. Si es así, preferiría tener esta información a mi disposición en cualquier momento, independientemente de si estoy depurando algún código de la interfaz de usuario, el procesamiento de números en la capa empresarial, el repositorio en sí o un sistema dependiente a través de un servicio web. O si estoy buscando registros de errores para el caso.

En su caso, si solo está obteniendo datos de la base de datos y empujándolos a través del servicio web, dejar la identificación fuera podría ser lo correcto. Simplemente no creo que tenga más sentido que mantenerlo en el caso general.

Tienes razón, no necesitas almacenar la identificación en el objeto, siempre y cuando solo necesites saberlo en tu contexto de repositorio.

La situación cambia cuando pasa el objeto a un código fuera de ese contexto, código que no solicitó el objeto por ID (y por lo tanto aún no lo sabe), pero necesita el ID para cualquier propósito (por ejemplo, para colocarlo en una lista de identificadores que se solicitarán más tarde al repositorio, mediante otro código más).

En esa situación, tiene dos opciones:

• Introducir un nuevo argumento de función 'id' en toda la cadena de funciones entre el contexto del repositorio y la función donde se necesita el id.

• incluir la identificación en el objeto

En la mayoría de estos casos, almacenar la identificación dentro del objeto será la mejor solución. También reducirá los cambios de código cuando se necesita la identificación en lugares imprevistos, además, a veces puede ser útil para la depuración.

Por eso lo hago cuando lo hago.