Ankündigung

Einklappen
Keine Ankündigung bisher.

extra Klasse für updated_at und created_at?

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • extra Klasse für updated_at und created_at?

    Hi,

    in den meisten meiner Klassen habe ich Attribute für "created_at" und "updated_at". Nun hab ich mich gefragt ob das nicht zu redundant ist. Was meint ihr, sollte ich diese beiden Attribute in einer eigenen Klasse auslagern und diese dann wiederum dort implementieren wo ich sie benötige? Oder lohnt das nicht?

    Wann ja, habt ihr einen Vorschlag wie man solch eine Klasse gut benennen könnte? Überlege, später die Klasse noch um ein "version"-Attribut zu erweitern.

    Gruß Kinger

  • #2
    Klassen? Felder?

    Meinst du Datenbankfelder? Oder Klassenvariablen?
    Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

    Kommentar


    • #3
      Zitat von lstegelitz Beitrag anzeigen
      Klassen? Felder?

      Meinst du Datenbankfelder? Oder Klassenvariablen?
      Klassenvariablen

      Kommentar


      • #4
        Was für eine Logik sollte denn die Extra-Klasse haben? Wenn alle Klassen diese Attribute haben, dann kannst du ja auch einfach vererben.

        Vor allem wüsste ich nicht wie eine zusätzliche Klasse die Redundanz auflösen würde. Dann müsstest du ja immer noch jedes Mal das Objekt instanziieren.

        Kommentar


        • #5
          In einer Klassenhierarchie böte sich dafür die oberste Klasse an, von der alle anderen erben.

          edit: Moment... meinst du, "created_at" und "update_at" sollen die Information sein, wann die Datei erstellt und aktualisiert wurde? Falls ja, dann reichen wohl Kommentarfelder ala javadoc.
          Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

          Kommentar


          • #6
            Hallöchen,

            derartige Meta-Daten gehören meiner Meinung nach in eine entsprechende Basisklasse. Ich referenziere an dieser Stelle auch gerne den jeweiligen Nutzer mittels der Felder createdBy, updatedBy.

            Viele Grüße,
            lotti
            [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

            Kommentar


            • #7
              Zitat von Tropi
              Was für eine Logik sollte denn die Extra-Klasse haben? Wenn alle Klassen diese Attribute haben, dann kannst du ja auch einfach vererben.

              Vor allem wüsste ich nicht wie eine zusätzliche Klasse die Redundanz auflösen würde. Dann müsstest du ja immer noch jedes Mal das Objekt instanziieren.
              Dachte da vielleicht an eine Revisions-Logik oder wie unten beschrieben, dass man noch den Ersteller mit speichert.

              Zitat von lstegelitz
              In einer Klassenhierarchie böte sich dafür die oberste Klasse an, von der alle anderen erben.

              edit: Moment... meinst du, "created_at" und "update_at" sollen die Information sein, wann die Datei erstellt und aktualisiert wurde? Falls ja, dann reichen wohl Kommentarfelder ala javadoc.
              Nein nein, geht schon um Datensätze nicht um die Datei.

              Okay, die implementierung als Basis-Klasse und dann davon zu erben scheint mir als Sinnvoll. Danke für den Hinweis.

              Wie würdet ihr eine solche Klasse nennen, die sich um solche Sachen wie created_at/by und updated_at/by und Co. kümmert?

              Kommentar


              • #8
                Ich habe mir darum eigentlich noch nie so richtig viele Gedanken gemacht und immer so gehandelt, wie ich es für richtig empfand. Wenn ich jetzt das Thema fundamental betrachte, dann würde ich diese Daten (wann erstellt, wann bearbeitet, von wem, warum, was...) als Metadaten sehen - ähnlich wie Annotations im Kontext einer OOP-Klasse.

                Gehören diese Daten in eine Entity-Klasse? Ich denke, eher nicht. Das sind Crosscutting-Concerns, die vielleicht nicht mal in das Repository gehören, welches das Datenmodel mit einer Datenquelle verbindet. Das könnte man alles in eine extra Schicht oder in eine eigene Komponente auslagern. Dann würde man diese Metadaten zur Entität ähnlich erreichen, wie Reflection die Metadaten einer Klasse zugänglich macht.

                Kommentar

                Lädt...
                X