Präfixierung DTO/POCOS - Namenskonventionen?

Question

einfache Frage wirklich, ich wollte wissen, welche Namenskonventionen jemand dort setzt DTO/POCOS ....

Ich wollte nicht wirklich wie ungarische Notation vorangestellt .. ich kam weg von diesem !.

Aber meine dtos Namensgebung sind kollidierende mit meinem eigentlichen Objektnamen zurück, und obwohl sie in einem anderen Namespace seine immer noch ein wenig verwirrend sind ..

Ich habe mich gefragt, welche Namenskonventionen jemand auf sie zutrifft

für Beispiel mein Kundenobjekt ist der Kunde

genannt, und ich tun, um eine Zuordnung zu dto ... die Kunden ist .. iwas DtoCustomer denken ..

Nicht sicher

Jedermann?

Answer 1

Ich bevorzuge dafür Namespaces. Durch die Verwendung von Namespace-Aliasen wird dies noch deutlicher.

Dies würde Code machen, die wie folgt aussieht:

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

Wenn ich ganz in der DTO Schicht arbeite, kann ich immer noch an dieser Stelle mit „Kunden“ arbeiten.

Answer 2

Ich mag CustomerDto mehr als DtoCustomer. Ich möchte, dass sie nebeneinander sortiert werden.

Die Benennung kann jedoch auch von der Verwendung des DTO abhängen. In einem ASP.NET MVC beispielsweise rufe ich oft ein DTO an, das an eine Ansicht für CustomerViewModel gesendet wird.

Answer 3

Ich hänge DTO typischerweise in Situationen wie diesem an.

Answer 4

Meiner Erfahrung nach sind DTOs oft Teilmengen oder Aggregationen von Daten, die Ihre Domain-Entitäten darstellen. Dies liegt in der Regel daran, dass Domänen-Entities reichhaltige, stark miteinander verbundene komplexe Objekte sind, die sowohl Verhalten als auch Daten aufweisen. Daher versuche ich, meine DTOs so zu benennen, dass sie die Teilmenge der Informationen, die sie repräsentieren, so gut wie möglich widerspiegeln. Im Falle von Kunden habe ich oft DTO, die fein abgestimmt auf die Informationen angefordert werden:

• CustomerHeader
• CustomerDetail
• CustomerWithRecentOrders
• CustomerAndBill

In den obigen Beispielen , CustomerHeader würde wahrscheinlich nur die Kunden-ID und den Namen enthalten, die oft dazu verwendet werden, Kunden in einfachen Listen anzuzeigen. CustomerDetail würde die meisten Kundeninformationen enthalten, würde jedoch keine der relationalen Eigenschaften enthalten, die eine vollständig durchgebrannte Customer-Entität enthalten könnte. Die anderen sollten selbsterklärend sein, was das ultimative Ziel ist.