Core Data Model in Static Library

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

    • Core Data Model in Static Library

      Hallo zusammen,

      Mein Problem vor welchem ich stehe ist eigentlich recht schnell beschrieben. Ich habe 2 Projekte, die sich im Code zu ca. 80% überschneiden, nennen wir sie Projekt A und Projekt B (Projekt B ist mal nur als Test aus einem fertigen Projekt A entstanden und dann aber ziemlich schnell gewachsen). Jetzt möchte ich den überlagernden Code in eine Static Library auslagern, weshalb muss ich wahrscheinlich nicht erläutern. Funktioniert bei "normalen" Klassen auch soweit.

      Das Problem ist nun, dass beide Projekte auf ein eigenständiges Core Data Model zurückgreifen, welches auch größtenteils identisch ist, aber eben nicht 100%. In der Static Library kann ich ja auch ein Core Data Model erstellen und via Bundle in Projekt A oder B integrieren und auch mergen mit einem Core Data Model in einem der Projekte, aber können diese auch untereinander in Beziehung stehen?
      Wie wie gehe ich vor, wenn ich in der Library beispielsweise eine Klasse "User" habe und diese nun im Projekt A erweitern möchte, und zwar nicht nur um Attribute sondern auch vielleicht Beziehungen zu neuen Klassen, die es nur in dem Core Data Model in Projekt A gibt. Idealerweise würde ich mir vorstellen, dass ich im Data Model Editor in Xcode unter Projekt A bei meiner Klasse User_Projekt_A (Beispiel) bei ParentEntity auf mein Core Data Model aus der Library zugreifen kann, was aber natürlich nicht geht, da es das zu dem Zeitpunkt gar nicht kennt.

      Doch nicht so schnell zu beschreiben, aber ich hoffe ich habe meine Problem klar gemacht.
    • volker schrieb:

      Mach für jedes Projekt ein eigenes Model...


      Das Problem dabei wäre, dass ich in der Library beispielsweise ganze ViewController ausgelagert habe, die natürlich die Datenklassen kennen müssen.Wenn ich in der Library einen ViewController habe, der eine Liste aller User anzeigt, muss er ja die Klasse User kennen. Spontan würde mir da KVC einfallen, aber da die Projekte wirklich recht komplex sind, müsste enorm viel Refactoring betrieben werden, oder gibt es eine andere Lösung?

      Manfred Kreß schrieb:



      du kannst dir dein CD Model auch komplett in Code zusammenbauen und dann natürlich auch in ne lib auslagern. Aber mit dem Modeleditor kannst du das vergessen.


      Ja daran hatte ich auch schon gedacht. Ist mein Vorhaben aus Software Engineering Perspektive denn Humbug oder ist Xcode dafür einfach nicht ausgelegt?
      Wofür kann man denn dann CoreData Models "mergen"? Nur wenn sie im unabhängig voneinander sind?
    • Ich verstehe nicht ganz, wie sich unterschiedlicher Code überlagern kann.
      Entweder das Modell stimmt überein und kann ausgelagert werden. Oder es unterscheidet sich und kann nicht ausgelagert werden.
      Das Merging funktioniert meines Wissens so abstrakt, dass Du aus beliebigen Bundles Modelle in Dein Programm laden und bearbeiten kannst, ohne ihre genaue Struktur kennen zu müssen. Es hat nichts damit zu tun, zwei unterschiedliche Modelle zu verschmelzen. Das musst Du manuell erledigen.

      Wenn sich Dein Core Data Modell in einigen Belangen überlagert, in Anderen jedoch nicht, dann könntest Du Dir pro gemeinsam genutzte Entity eine ganz spezifische Subklasse von NSManagedObject erstellen und in deine Lib mit reinpacken. Dann kann Dein Objekt 'User' theoretisch völlig unabhängig des verwendeten Stores agieren und Du garantierst, dass gewisse Methoden definitiv implementiert sind.

      Dort, wo sich Dein Core Data Modell unterscheidet, wird dann halt eine Eigenimplementierung fällig. Da jede Entity von einer beliebigen NSManagedObject Subklasse abgeleitet werden kann, gibt es dort keinerlei Probleme.

      Und eine andere Lösung als großes Refactoring sehe ich bei Deinem Problem leider nicht.
      Macht aber nix, mit ausreichenden und guten Unit Tests ist Refactoring gar nicht schlimm sondern im Gegenteil sogar sehr sinnvoll und gut für die Codehygiene. :)
      «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

      Iä-86! Iä-64! Awavauatsh fthagn!

      kmr schrieb:

      Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
    • Ja daran hatte ich auch schon gedacht. Ist mein Vorhaben aus Software Engineering Perspektive denn Humbug oder ist Xcode dafür einfach nicht ausgelegt?



      Coredata Models, Storyboards und nibs funktionieren nur dann optimal, wenn man den Begriff Softwareengineering völlig verdrängen kann oder nicht kennt.

      Jehova, soag I...
      Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.
    • Ach ja, das CDModel in Code zusammenzubauen ist wirklich keine schöne Sache. Das ist eben die Technologie, die hinter dem Editor steckt, aber wohl nicht für Handarbeit entworfen.

      Wenn dieser Editor einfach ne Möglichkeit hätte, das Ganze in Code zu exportieren, dann wäre das in der Hinsicht schon ein großer Schritt.
      Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.
    • Marco Feltmann schrieb:

      Wenn sich Dein Core Data Modell in einigen Belangen überlagert, in Anderen jedoch nicht, dann könntest Du Dir pro gemeinsam genutzte Entity eine ganz spezifische Subklasse von NSManagedObject erstellen und in deine Lib mit reinpacken. Dann kann Dein Objekt 'User' theoretisch völlig unabhängig des verwendeten Stores agieren und Du garantierst, dass gewisse Methoden definitiv implementiert sind.

      Dort, wo sich Dein Core Data Modell unterscheidet, wird dann halt eine Eigenimplementierung fällig. Da jede Entity von einer beliebigen NSManagedObject Subklasse abgeleitet werden kann, gibt es dort keinerlei Probleme.


      Aber du beziehst dich dabei auf die Lösung der manuellen Implementierung ohne den Editor in Xcode oder?

      Marco Feltmann schrieb:

      Und eine andere Lösung als großes Refactoring sehe ich bei Deinem Problem leider nicht.
      Macht aber nix, mit ausreichenden und guten Unit Tests ist Refactoring gar nicht schlimm sondern im Gegenteil sogar sehr sinnvoll und gut für die Codehygiene. :)


      Ohne eine gewisse Portion Refactoring gehts ja sowieso nicht und habe ich auch nichts gegen. Es sind halt ca. 50 Entities, und eine Lösung à la Core Data Model komplett in die Library packen und die vielleicht 5 unterschiedlichen Entities im jeweiligen Projekt zu differenzieren wäre halt schön.

      Da sich die Unterschiede Grenzen halten, habe ich auch schon überlegt, direkt in der Library das Datenmodell so zu ändern, dass es keine Anpassungen mehr in den Projekten braucht, was aber auch bedeuten würde, dass es dort Entities gibt, die überflüssig sind, was ich persönlich halt auch nicht für schön halte und ich jetzt aus dem Kopf auch nicht weiß, ob es da irgendwelche Konflikte geben würde.
    • Ich beziehe mich auf eine Implementierung der gebrauchten Objekte ohne den Editor im Falle der Library und auf eine Implementierung mit Editor unter Verwendung der Library-Objekte in den spezifischen Projekten.

      Du definierst also dein Modell als Objekt gemäß deiner Vorstellungen im Editor.

      C-Quellcode

      1. @interface MyUser : NSManagedObject
      2. @dynamic NSString * name;
      3. @dynamic NSString * shortName;
      4. @end
      5. @implementation MyUser
      6. @end


      In allen anderen Projekten erstellst Du dir jeweils ein Modell im Editor. (Das Ganze im Code zu zimmern wird vermutlich tödlich enden...)
      Und anstatt dass Du das Ganze 1:1 nachmodellierst fügst Du nur eine neue Entity ein und setzt sie auf den Typ MyUser.
      Das Schöne daran ist, dass diese Eigenimplementierung auch Relations beinhalten kann, die in die Library nicht hineingebaut werden müssen. Du kannst es also tatsächlich auch erweitern.
      «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

      Iä-86! Iä-64! Awavauatsh fthagn!

      kmr schrieb:

      Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
    • Manfred Kreß schrieb:

      Coredata Models, Storyboards und nibs funktionieren nur dann optimal, wenn man den Begriff Softwareengineering völlig verdrängen kann oder nicht kennt.

      Wie kommst Du darauf?
      All diese Technologien bestehen doch einzig und allein auf Grund der Existenz von Softwareengineering.
      Wenn man damit vergeblich die falschen Dinge versucht, bedeutet es ja noch lange nicht, dass es schlecht ist. ;)
      «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

      Iä-86! Iä-64! Awavauatsh fthagn!

      kmr schrieb:

      Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
    • Okay

      Marco Feltmann schrieb:

      Und anstatt dass Du das Ganze 1:1 nachmodellierst fügst Du nur eine neue Entity ein und setzt sie auf den Typ MyUser.


      Aber wie genau soll das funktionieren ? Wo genau soll ich den Typ setzen, denn im Editor geht es ja nicht, weil ich da nur ParentEntities aus dem gleichen Core Data Model auswählen kann (so scheint es jedenfalls)