Objektgraph mit Im- / Export ... Core Data oder was?

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Markus Müller schrieb:

      Also ich würde das nicht in die MO-Subklassen packen, denn da gehört es nicht hin.
      Das hatte ich genau anders empfunden: Jedes MO weiß doch am besten, wie es zu archivieren bzw. wiederherzustellen ist. So hangelt sich das Archivieren des Root-Objektes nahezu automatisch durch den Graphen, ähnlich dem NSCoding-Protokoll. Das empfinde ich als sehr aufgeräumt, auch wenn die jeweiligen Methoden verstreut sind, liegen sie genau dort, wo ich sie erwarten würde.

      Eine zentrale Archivierungs-Instanz ... den Gedanken werde ich mal beim nächsten Projekt verfolgen.

      Mattes
      Diese Seite bleibt aus technischen Gründen unbedruckt.
    • Ja, hab den Thread auch nur kurz überflogen. Kommt halt auf die policies an: wenn nur quasi die properties extrahiert werden mag das noch gehen (würde ich dann aber in eine Kategorie packen), aber schon sowas wie dubletten rausfiltern kann dann schnell in SRP und ISP-Verletzung ausarten. Mit einer extra Exportklasse hältst Du die Sachen schön getrennt und exponierst den export-Code nicht an die normalen Klienten Deiner MOs.
    • Ergänzend zu Markus noch ein weiterer Grund, warum sich nicht die Entitäten mit dem Export befassen sollten: Die exportierten Daten sind eine Darstellung des Objektmodells, und es gibt häufig nicht nur eine mögliche Exportdarstellung.

      MyMattes schrieb:

      Jedes MO weiß doch am besten, wie es zu archivieren bzw. wiederherzustellen ist.

      Wenn du nur Komplettexporte siehst. Allgemein müssen aber die exportierten Daten nicht alle Informationen des Modells enthalten. Und dann weiß der Exporter, was exportiert werden muss.
      „Meine Komplikation hatte eine Komplikation.“