Unterschied zwischen Entität und DTO

Was ist der Unterschied zwischen einem DTO und einer Entität? Im Einzelnen sind dies meine Fragen:

1. Welche Felder sollten die DTOs haben? Zum Beispiel sind meine Entitätsklassen:

   @Entity
   public class MyFirstEntity implements Serializable {
   
       @Id @GeneratedValue
       private Long id;
   
       private String stringData;
   
       @OneToOne
       private MySecondEntity mySecondEntity;
   
       @OneToMany
       private List<MySecondEntity> mySecondEntitesList;
   
   }
   
   @Entity
   public class MySecondEntity implements Serializable {
   
       @Id @GeneratedValue
       private Long id;
   
       private Integer integerData;
   
       @ManyToOne
       private MyFirstEntity myFirstEntity;
   
   }
   

Es gibt eine einseitige Verbindung (One-to-One) und eine zweiseitige Verbindung (Many-to-One), einfache String- und Integer-Daten und natürlich die IDs. Was von ihnen in die zu setzen MyFirstDTO und MySecondDTO Klassen?

2. Wenn es eine Vererbung zwischen den Entitäten gibt, wie soll ich sie dann in den DTOs darstellen? Zum Beispiel:

   @Entity
   public class MyFirstEntity extends MySecondEntity {
       ....
   }
   
   @Entity
   public class MyFirstDTO extends MySecondDTO {
       ....
   }
   

3. Wie sollte ich sie verwenden? Ich erfahre zum Beispiel Folgendes: Ich arbeite an einem Webprojekt. Der Benutzer der Webseite möchte sich registrieren. Er/Sie füllt die Formulare aus und sendet sie an den Server. Auf der Serverseite erstelle ich zuerst ein DTO, weil dessen Felder die Validierungen haben. Aus dem DTO erstelle ich eine Entität und behalte sie in der Datenbank bei. Wenn eine Entität angefordert wird, konvertiere ich die angeforderte Entität in DTO und gebe sie dem Benutzer auf der Clientseite. Ist es eine gute Vorstellung oder nicht?

Kurze Antwort:

• Entitäten vielleicht Teil einer Geschäftsdomäne. Somit können sie Verhalten implementieren und auf verschiedene Anwendungsfälle innerhalb der Domäne angewendet werden.

• DTOs werden nur verwendet, um Daten von einem Prozess oder Kontext zu einem anderen zu übertragen. Als solche sind sie verhaltenslos – abgesehen von sehr einfachen und meist standardisierten Speicher- und Abruffunktionen.

Lange Antwort:

Während der Begriff „Data Transfer Object“ (DTO) recht eindeutig definiert ist, wird der Begriff „Entity“ in verschiedenen Zusammenhängen unterschiedlich interpretiert.

Die relevantesten Interpretationen des Begriffs „Einheit“ sind meiner Meinung nach die folgenden drei:

1. Im Zusammenhang mit Entity-Relationship- und ORM-Frameworks – insbesondere Enterprise Java und Jpa:

   “Ein Objekt, das persistente Daten darstellt, die in einer Datenbank verwaltet werden.”

2. Im Zusammenhang mit “Domain-Driven Design” (von Eric Evans):

   “Ein Objekt, das hauptsächlich durch seine Identität und nicht durch seine Attribute definiert wird.”

3. Im Kontext von „Clean Architecture“ (von Robert C. Martin):

   “Ein Objekt, das unternehmensweite kritische Geschäftsregeln kapselt.”

Die Jee- und Jpa-Community sieht Entitäten primär als Objekte, die einer Datenbanktabelle zugeordnet sind. Diese Sichtweise kommt der Definition eines DTO sehr nahe – und daher kommt wahrscheinlich ein Großteil der Verwirrung.

Im Kontext von Domain-Driven-Design sowie aus Sicht von Robert Martin sind Entitäten jedoch Teil einer Geschäftsdomäne und können und sollten daher Verhalten implementieren.

Unterschied zwischen DTO & Entität:

Entität ist der Tabelle zugeordnete Klasse. Dto ist eine Klasse, die meistens der Ebene “Ansicht” zugeordnet ist. Was gespeichert werden muss, ist eine Entität, und was auf der Webseite „angezeigt“ werden muss, ist DTO.

Beispiel : Wenn ich das Mitarbeitermodell wie folgt speichern möchte: Nehmen Sie als Beispiel einen Mitarbeiter, ich muss das Geschlecht entweder männlich/weiblich/andere speichern. Aber auf JSP muss ich alle drei Werte als Formularoptionen anzeigen, damit der Benutzer einen auswählen kann.

@Entity
public class Employee{
//annotate with @Id and others

private Long id;
private String name;
private Gender gender; //this is enum viz Male,female
}
//Now extend Dto with employee

public EmployeeDto extends Employee{
Gender[] genders=Gender.values(); //put all gender types in array.
}

beim rendern von jsp können wir geben

<select name="gender"> //pointed towards entity gender field.
  <option value="Male">Male</option>
  <option value="Female">Female</option>
  <option value="Other">Other</option>
</select>

dann wird im Frühling oder in einem anderen Rahmen, was auch immer ausgewählt wurde, als Geschlecht in der Entität gewählt. Dies wird ermöglicht, weil Dto alle drei Werte von Geschlecht in sich hatte. In ähnlicher Weise folgen die Dinge je nach Situation.
Da wir meistens die meisten Entity-Felder auf JSP benötigen, erweitern wir dto um Entity.

“Entitäten” beziehen sich auf Einheiten der Zusammensetzung der Gesamtsystemdaten. Sie stellen normalerweise Geschäftsobjekte wie Bankkonten, Mitarbeiter, Produkte usw. dar. Sie können verwendet werden, um den Zustand des Systems in einer Datenbank zu speichern.

„Datenübertragungsobjekte“ sind kurzlebige Sammlungen von Daten, die für einen ganz bestimmten Zweck übertragen werden. Zum Beispiel, um einem Endbenutzer eine Liste von Produkten einer bestimmten Art anzuzeigen. Sie möchten nicht alle Daten, die jede Produktentität repräsentieren, an den Benutzer senden, sondern nur das, was für diesen Zweck benötigt wird.

Das die Microsoft 2014 MVC-Dokumentation erklärt, warum Sie DTOs aus Entitäten erstellen möchten. Dies sind einige Beispiele dafür, was sie vorschlagen, um Entitäten in DTOs umzuwandeln.

• Entfernen Sie Zirkelbezüge.
• Blenden Sie bestimmte Eigenschaften aus, die Clients nicht anzeigen sollen.
• Lassen Sie einige Eigenschaften weg, um die Nutzlastgröße zu reduzieren.
• Reduzieren Sie Objektdiagramme, die verschachtelte Objekte enthalten, um sie für Clients bequemer zu machen.
• Vermeiden Sie „Over-Posting“-Schwachstellen. (Siehe Modellvalidierung für eine Diskussion über Overposting.)
• Entkoppeln Sie Ihre Serviceschicht von Ihrer Datenbankschicht.

Aber es ist wichtig zu verstehen, dass dies keine harten Regeln sind, die befolgt werden müssen. Es hängt alles davon ab, welche Daten am besten an Ihren Kunden gesendet werden und welches Format für Ihren Kunden am nützlichsten wäre.

Was muss der Kunde mit den Daten tun?

• Wird es bearbeitet oder nur angesehen?
• Interessieren sich Clients für die Reihenfolge der int-Liste?
• Müssen Einfügungen oder Löschungen eines int vorgenommen werden?
• Muss die Liste neu geordnet werden?

Muss der Klient über die 1-1- oder 1-viele-Beziehungen oder die Tatsache, dass es Vererbung gibt, Bescheid wissen? Das Senden dieser Informationen kann für den Kunden nur unnötig kompliziert werden.

Diese und andere Fragen müssen beantwortet werden, bevor entschieden wird, welche Daten an den Client gesendet werden und wie diese gesendet werden.

Einfaches Gespräch:
DTO steht für Data Transfer Object. DTOs werden hauptsächlich zum Übertragen von Daten zwischen Diensten (Webdiensten, APIs usw.) verwendet, die eine Vielzahl von Eigenschaften verschiedener Entitäten (mit oder ohne ihre ID) umfassen können. Nehmen Sie diese Zeile als Beispiel für ein DTO: Stellen Sie sich vor, eine Shopping-Website sendet ihre Versandanfragen über einen Webservice an ein Versandunternehmen. Sein DTO wäre etwa so: CustomerFullName, ShippingFee, ShippingAddress. In diesem Beispiel CustomerFullName ist eine Kombination von Eigenschaften FirstName + LastName für die Customer Wesen und ShippingFee ist das Ergebnis mehrerer Bestimmungs-, Steuer-, etc.-Prozesse gegenüber einigen anderen Einheiten.

Im Gegensatz dazu sind Entitäten eine Reihe von Eigenschaften, die gesammelt werden, um eine einzelne Entität mit einer bestimmten ID darzustellen (z. B. Teacher, Student, Employee, etc.). Mit anderen Worten, DTOs sind eine Reihe bedeutungsloser Eigenschaften, die gesammelt werden, um an den Client gesendet zu werden, und ein DTO hat nicht unbedingt eine Beziehung zu den anderen DTOs, während eine Entität Eigenschaften eines bestimmten Objekts mit sinnvoller Beziehung zu den anderen Entitäten enthält. In einem relationalen Datenbankparadigma können wir DTOs als Zeilen von Ansichten betrachten, während Entitäten die Zeilen von Tabellen mit dem Primärschlüssel sind. @Shatayu Darbhe hat dies auch in seiner/ihrer Antwort erwähnt.

Model ist jedoch eine Kombination aus diesen beiden. Ein Modell kann mehrere verwandte Entitäten sowie zusätzliche Daten enthalten, um reale Anwendungs-/UI-Probleme zu behandeln. Betrachten Sie ein Modell mit dem Namen CustomerOrdersModel das beinhaltet Customer Einheit, List<Order> Entitäten und ein zusätzliches Boolesches Flag PayWithCredit Angabe, ob der Benutzer mit Debitkarte oder Kreditkarte bezahlen wird.