prefijando DTO/POCOS - convenciones de nomenclatura?

pregunta simple de verdad, quería saber qué convenciones de nombres alguien pone allí DTO/POCOS ....prefijando DTO/POCOS - convenciones de nomenclatura?

No quería realmente prefijar como la notación húngara ... ¡me escapé de eso !.

Pero mis dtos de nombres están chocando con mis nombres reales de objetos devueltos ya pesar de que están en un espacio de nombres diferente su todavía un poco confuso ..

me preguntaba lo que las convenciones de nomenclatura se aplica a cualquiera que

de ejemplo, mi objeto de cliente se llama al cliente

I y hacer un mapeo de dto ... que es cliente .. iwas pensar DtoCustomer ..

No estoy seguro

¿Alguien?

Fuente

2009-07-02 mark smith

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

Esto haría que el código que se parece a:

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

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

Fuente

2009-07-02 16:58:22

Sí, lo adopté al final, tengo mis modelos en los modelos de espacio de nombres y mi dtos en dto ... gracias –

Eso nunca me había ocurrido. Increíble. Lo amo. Quiero algo más. – Sinaesthetic

esta es una situación donde calificar con un espacio de nombre tiene sentido y es un buen uso de esa gente.Pero de lo contrario, agregue el uso de las declaraciones en la parte superior de sus clases y no califica completamente si no es necesario. – PositiveGuy

Me gusta más CustomerDto than DtoCustomer. Me gusta tenerlos ordenados uno al lado del otro.

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

Fuente

2009-07-02 16:55:30 BengtBe

Normalmente anexo DTO en situaciones como esta.

Fuente

2009-07-02 17:05:53

En mi experiencia, los DTO a menudo son subconjuntos o agregaciones de datos que representan las entidades de tu dominio. Esto se debe generalmente a que las entidades de dominio son objetos complejos ricos, altamente interrelacionados, que tienen comportamiento y datos. Como tal, trato de nombrar 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 afinado a la información que se solicita:

CustomerHeader
CustomerDetail
CustomerWithRecentOrders
CustomerAndBill

En los ejemplos anteriores , CustomerHeader probablemente solo contenga la ID y el Nombre del cliente, 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 una entidad del cliente completa podría contener. Los demás deben ser autoexplicativos, que es el objetivo final.

Fuente

2009-07-02 17:15:23 jrista

@CoffeeAddict: Depende de cuáles sean sus objetivos. Si un buen desempeño es un requisito clave, a veces hay que "enturbiar las aguas puras" de lo que de otro modo podría ser una arquitectura "ideal" para mejorar el rendimiento de las cosas que pasan por alto. Si puede permitirse el lujo de no utilizar una arquitectura orientada a servicios, en primer lugar no es necesario contar con DTO granulares. – jrista

prefijando DTO/POCOS - convenciones de nomenclatura?

Respuesta

Cuestiones relacionadas