¿Es una buena práctica usar objetos de entidad como objetos de transferencia de datos?

Me pregunto porque si es así, ¿por qué Entity Framework no ofrece lógica para crear un nuevo objeto con las mismas propiedades para transferir datos entre capas?

Utilizo los objetos de entidad que genero con el marco de la entidad.

Es tu decision.

La mayoría de la gente le dirá que no es una buena práctica, pero puede salirse con la suya en algunos casos.

EF nunca jugó bien con DDD por múltiples razones, pero dos se destacan: no puede tener constructores parametrizados en sus entidades y no puede encapsular colecciones. DDD se basa en eso, ya que el modelo de dominio debe incluir tanto datos como comportamiento.

En cierto modo, EF te obliga a tener un modelo de dominio anémico y en este caso puedes usar las entidades como DTO. Puede encontrar algunos problemas si usa las propiedades de navegación, pero puede serializar esas entidades y enviarlas por cable. Sin embargo, puede no ser práctico. Deberá controlar la serialización de cada entidad que tenga propiedades que no necesita enviar. La forma más fácil es simplemente diseñar clases separadas adaptadas para la transferencia de datos. Las bibliotecas como AutoMapper se crean para este propósito.

Por ejemplo: suponga que tiene una clase llamada Personcon la siguiente definición:

public class Person
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public DateTime DateOfBirth { get; get; }

    // plus a bunch of other properties relevant about a person
}

Suponiendo que desee mostrar una lista de empleados en algún lugar, puede ser práctico enviar solo el Id, FirstNamey LastName. Pero tendrá que enviar todas las demás propiedades irrelevantes. No es un gran problema si no le importa el tamaño de la respuesta, pero la idea general es enviar solo los datos relevantes. Por otro lado, puede diseñar una API que devuelva una lista de personas y, en ese caso, puede ser necesario enviar todas las propiedades, por lo que tiene sentido serializar y enviar las entidades. En este caso, crear una clase DTO es discutible. A algunas personas les gusta mezclar entidades y DTO, a otras no.

Para responder a su pregunta actualizada, EF es un ORM. Su trabajo es mapear los registros de la base de datos a objetos y viceversa. Lo que haces con esos objetos antes y después de pasar por EF no es parte de sus preocupaciones. Tampoco debería ser.

No, no es.

Idealmente, los DTO coincidirán con sus repositorios de persistencia (también conocidos como tablas de su base de datos).

Pero sus clases de negocios no son necesariamente una coincidencia. Es posible que necesite clases adicionales o clases separadas o unidas a lo que tiene en la base de datos. Si su aplicación es pequeña, es posible que no vea este tipo de problemas, pero en aplicaciones medianas a grandes, esto sucederá con frecuencia.

Otra cosa es que los DTO son parte del dominio de lo que sea que trate con persistencia, mientras que su Business Layer no debe saber nada sobre ellos.

En realidad es una muy mala idea. Martin Fowler tiene un artículo sobre DTO locales .

En pocas palabras, DTOPattern se usó para transferir datos fuera del proceso, por ejemplo a través del cable y no entre capas dentro del mismo proceso.

No, es una mala práctica.

Algunas razones:

1. Los nuevos campos de entidad estarán en el Dto, por defecto . Usar la entidad significa que toda la información estará disponible para ser consumida por defecto. Esto puede llevarlo a exponer información sensible o, al menos, hace que su contrato de API se infle, con mucha información que no se usa para quién consume la API. Por supuesto, puede ignorar los campos utilizando algunas anotaciones (como @JsonIgnoredel mundo de Java), pero esto lleva al siguiente problema ...
2. Muchas anotaciones / condiciones / controles en la entidad . Debe controlar lo que le gustaría enviar en Dto, cuando cambie el nombre de algún atributo (esto romperá el contrato), agregue algún atributo que no sea de la entidad, el orden de los atributos, etc. Pronto verá su simple entidad con muchas anotaciones, campos adicionales y cada vez será más difícil entender lo que está sucediendo.
3. Menos flexibilidad . Con un Dto, puede dividir la información en más clases, cambiar los nombres de los atributos, agregar nuevos atributos, etc. No puede hacer esto tan fácilmente con una entidad como Dto.
4. No optimizado . Su entidad siempre será más grande que un simple Dto. Por lo tanto, siempre tendrá más información para ignorar / serializar y probablemente se transmitirá más información innecesaria.
5. Problemas perezosos . Usando la entidad de algunos marcos (como Hibernate), si intenta recuperar alguna información que no se cargó de forma diferida dentro de una transacción de base de datos antes, el proxy ORM no se adjuntará a la transacción y recibirá algún tipo de "excepción diferida" solo para llamar a un getmétodo de la entidad.

Por lo tanto, es más fácil y seguro usar algún tipo de herramienta de mapeador para ayudarlo en este trabajo, mapeando los campos de entidad a un Dto.

Para completar lo que dijo @Dherik, los principales problemas de usar objetos de entidad como objetos de transferencia de datos son:

1. En una transacción, corre el riesgo de comprometer los cambios realizados en su entidad porque la usa como DTO (incluso si puede separar la entidad de la sesión en una transacción, la mayoría de las veces deberá verificar este estado antes cualquier modificación en su entidad-DTO y asegúrese de que no está en una transacción o que la sesión se ha cerrado si no desea que las modificaciones persistan).

2. El tamaño de los datos que comparte entre el cliente y el servidor: a veces no desea enviar todo el contenido de una entidad al cliente para minimizar el tamaño de la respuesta de la solicitud. Separar el DTO de la entidad es más flexible, para especializar los datos que desea enviar en ciertos casos de uso.

3. Visibilidad y mantenimiento: debe administrar sus anotaciones jpa / hibernate en los campos de su entidad y mantener las anotaciones jackson para serializar en json en el mismo lugar (incluso si puede separarlas de la implementación de la entidad al colocarlas en la interfaz heredada por el entidad). Luego, si cambia su contenido DTO al agregar un nuevo campo, otra persona probablemente pueda pensar que es un campo de la entidad, por lo tanto, un campo de la tabla en cuestión en su base de datos (incluso si puede usar la @Transientanotación en todos sus campos DTO para el caso ..!).

En mi opinión, crea ruido cuando lees la entidad, pero mi opinión es seguramente subjetiva.