[TYPO3-german] Entity oder Value Object

Tue Oct 7 15:49:50 CEST 2014

Hallo Dieter,
ich bin mir nicht sicher ob du das Richtig Verstanden hast.
Ein Vektor z.b. ist typischer weise eher ein Value Objekt. Bei deinen anderen beispielen kommt es ein bischen darauf an.

Angenommen du hast schiffe und möchtest deren Bewegung festhalten.

Jedes Schiff währe eine Entity. Weil du jedes schiff eindeutig Identifizeiern möchtes selbst wenn es viele schiffe mit gleichem namen gibt.
Doch es ist nicht nötig X mal den Gleichen Bewegungswecktor in deiner datenbank zu speichern. Selbst wenn viele schiffe den gleichen Bewegungs vecktor verwenden.

Ship = ENTITY{
   Name:String
   Bewegungsrichtung: Vektor
 Position: geoCoordinate
}

Den Vektor und LatLong würdest du jetzt als Value Object Abbilden:

Vector = VALUEOBJECT {
  Rotation: Float
  Speed: Float
}

geoCoordinate = VALUEOBJECT {
  Lat: Float
  Long: Float
}

Ein Value Object wird Allein durch die Werte seiner Eigenschaften beschrieben es kann also viele schiffe geben die sich mit Vector(0,30) bewegen.
Aber solange sich alle Schiffe mit Vector(0,30) bewegen reicht es völlig aus einen einzigen wert in der Datenbank zu speichern. und alle schiffe auf diesen wert zeigen zu lassen.

Sobald sich jetzt bei einem Schiff die Geschwindigkeit ändert wird ein neuer Vektor erzeugt und zugewiesen(
$ship .Bewegungsrichtung = new Vector(0,15);

Jetzt hat nur diese schiff einen anderen Bewegungs Vector als der Rest der schiffe. Und wir müssen nun einen zweiten Vector in der Datenbank Speichern.

Wenn jetzt alle anderen schiffe ebenfalls die geschwindigkeit ändern (so das keines der schiffe mehr (0,30) fährt. Gibt es keinen grund mehr den Ursprünglichen Vector(0,30) zu behalten.
Da er nun von keinem Objekt mehr referenziert wird. Und das  Value Objekt Kann Gelöscht werden. (das houskeeping macht normalerweise das framework)

wenn du sehr viele Schiffe hast kannst du dir vorstellen das es einen großen Unterschied macht wie viele ValueObject du in der Datenbank halten musst.

Es Muss nur sichergestellt werden das ValueObjecte niemals verändert werden. Sondern neu erstellt werden. oder gelöscht werden wenn es keine referenzen gibt.

Anders bei Schiffen (ENTITIES).
Ein Schriff bleibt das gleiche Schiff.
Selbst wenn sich der Name des Käptens ändert. Oder die Farbe des Anstrichtes. Und selbst dann wenn jemand das Schiff Selbst umbenennt.
Und ein Schiff wird auch nicht einfach gelöscht nur weil nix mehr darauf verweist.

Ich hoffe dieses beispiel macht es noch mal etwas anschaulicher.

Gruss chris

Hallo Chris,

dann habe ich das Konzept vielleicht verstanden.
Ich habe entity immer assoziiert mit dem Datenbank-Type enum und mit der Übersetzung "Ding, Wesen, Objekt." Dabei habe ich immer noch einen primitiven Datentyp unterstellt, weil für mich ein Objekt ein primitiver Datentyp ist.

Deine Antwort läuft aber darauf hinaus, dass Entity quasi auch Vektoren, ein JSON-String oder auch Eigenschaftensgruppen umfassen können. (Sie sollen also quasi einen Record als Datenbankeintrag ermöglichen, wobei auf dem Eintrag dann auch die Standardaktionen wie view, change, delete, add, get, list sein müssen) Wenn ich dich richtig verstanden habe, würde man in einer Extension ein Feld "Adresse" als entinity anlegen, wobei die Entity 'Adresse' dann zum Beispiel Informationen zu Straße, Hausnummer, Postleitzahl, Stadt, und Nation enthalten kann. 

Am 7.10.2014 12:04, schrieb Chris Wolff - AERTiCKET AG:
> Konsequenzen (Praktisch)
> Ich Weiß nicht ob sich momentan Praktische Unterschiede in Extbase/flow gibt! 
>  Jedoch ist es wahrscheinlich Zukunft sicher wenn man bei der Extension Entwicklung Darüber Nachdenkt. Was eine Entity und was eine Value Object ist.
> Denn ich könnte mir vorstellen das zumindest die datenspeicherungs 
> unterschiede bald einzug halten (wenn das nicht schon der fall ist)
Schade. Genau an der Stelle wird es spannend. Die Entinity macht es möglich, mit Übersicht mächtig-schlanke Extensions zu schreiben, da man bei der Programmierung zum Beispiel nur die Validität der 'Adresse'
sicherstellen muss und per (convention over configuration) darauf vertraut, dass die Validität schon sichergestellt ist.
An dieser Stelle werden automatisierte Unit-Tests dann immer wichtiger, die die richtige Verarbeitung  von 'Adresse' sicherstellen. 

Am 7.10.2014 12:46, schrieb Sebastian g:
> Hallo ihr beiden,
>
> vielen Dank für Eure Antworten. Also ich habe das jetzt so verstanden, 
> dass die Value Objects keine "richtigen" Eigenschaften haben, die 
> veränderlich sind.
> Wenn wir jetzt mal als Beispiel die Orte in der Events-Extension 
> nähmen, können diese ja auch wieder Eigenschaften haben, 
> beispielsweise Namen und Verwaltungsbezirk oder 
> Einheitsgemeinde/Verwaltungsgesellschaft. In diesem Fall wären dann 
> Value Objects ungeeignet, da bei der Änderung einer Stadt in der 
> Beziehung zu einem Event die Städte in den anderen Events (mit dem 
> gleichen Ort) sich nicht aktualisieren würden, sondern für den 
> aktuellen Event ein zweites Stadt-Objekt (mit den veränderten
> Eigenschaften) erzeugt würde Ist das so richtig?
>
Ich denke, da kann ich dir keine Empfehlungen geben, da ich den Aspekt - nach Chris Antwort zu urteilen - wohl noch nicht tiefgehend genug verstanden habe.

Dieter

--
Dr. Dieter Porth -
Mein kleines TYPO3-Labor: http://www.mobger.de/