upper programacion nomenclatura nombres kebab estandares ejemplos convención convencion constantes camelcase camel c# naming-conventions poco dto

c# - programacion - nomenclatura de variables y constantes



prefijando DTO/POCOS-convenciones de nombres? (4)

Una pregunta simple, realmente, quería saber qué convenciones de nomenclatura pone cualquiera DTO / POCOS ...

Realmente no quería prefijo como notación húngara .. ¡Me alejé de eso !.

Pero mi denominación de dtos está en conflicto con mis nombres de objetos devueltos reales y, aunque están en un espacio de nombres diferente, todavía es un poco confuso ...

Me preguntaba qué convenciones de nomenclatura le aplican a alguien.

por ejemplo, mi objeto cliente se llama Cliente

y hago un mapeo a dto ... que es Cliente ... estaba pensando en DtoCustomer ...

No es seguro

Alguien?


En mi experiencia, los DTO son a menudo subconjuntos o agregaciones de datos que representan sus entidades de dominio. Esto suele deberse a que las entidades de dominio son objetos ricos, altamente interrelacionados y complejos que tienen tanto comportamiento como datos. Como tal, trato de nombrar a mis DTO para reflejar lo más posible el subconjunto de información que representan. En el caso de los clientes, a menudo tengo DTO que están ajustados a la información solicitada:

  • CustomerHeader
  • CustomerDetail
  • Clientes con órdenes recientes
  • CustomerAndBill

En los ejemplos anteriores, CustomerHeader probablemente solo contendría el ID y el nombre del cliente, que a menudo se usa para mostrar a los clientes en listas simples. CustomerDetail contendría la mayor parte de la información del cliente, pero no contendría ninguna de las propiedades relacionales que probablemente contenga una entidad de cliente completa. Los otros deben explicarse por sí mismos, que es el objetivo final.


Me gusta CustomerDto más que DtoCustomer. Me gusta tenerlos ordenados uno junto al otro.

Pero la denominación también puede depender del uso del DTO. Por ejemplo, en un MVC de ASP.NET a menudo llamo un DTO que se envía a una vista para CustomerViewModel.


Normalmente agrego DTO en situaciones como esta.


Prefiero usar los espacios de nombres para esto. El uso de alias de espacio de nombres para esto lo hace aún más claro.

Esto haría que el código se vea como:

Customer myCustomer = new Customer(); Dto.Customer dtoCustomer = ....;

Si estoy trabajando completamente en la capa DTO, todavía puedo trabajar con "Cliente" en este punto.