NSDocument architecture pour et contre

Question

Est-ce que quelqu'un a des avantages et des inconvénients NSDocument qu'il aimerait partager?

En particulier:

• Une fois que vous dépendez sur l'architecture NSDocument, est-il difficile de le refactoriser si vous devez?

• Y at-il des implications de performance?

• Est-ce que cela vous limite de certaines façons?

Answer 1

(1) Une fois que vous allez NSDocument, il est difficile de revenir en arrière. C'est parce que l'architecture de NSDocument fait énormément de choses pour vous. Il crée la base d'une application Cocoa basée sur plusieurs documents fonctionnant correctement. Vous pouvez réinventer cette roue si vous voulez, mais ce sera une énorme quantité de travail juste pour atteindre la parité.

(2) Non; bien sûr, l'architecture du document consomme des cycles pour maintenir l'état, etc. Mais vous auriez à faire la même chose si vous deviez rouler le vôtre. Et les membres de l'équipe AppKit qui gèrent l'architecture des documents le font parce que c'est leur travail. Votre travail consiste à expédier les produits aux clients le plus rapidement possible. Si vous pouvez justifier la construction d'une architecture de document dans le cadre de la réalisation de cet objectif, allez-y. Si ce n'est pas le cas et que vous en avez besoin, réutilisez celui que vous avez reçu.

(3) Il vous limite à la création d'une application d'application basée sur un document. :)

Sérieusement, si vous avez besoin d'une application basée sur un document, allez avec NSDocument. Si vous ne le faites pas, ne le faites pas.

J'ai récemment écrit une application de traitement de données où toutes les données par document sont importées à partir de divers fichiers texte. Je n'ai pas vraiment besoin de persister les données entre les sessions - c'est sur la bonne liste, mais je suis toujours allé avec NSDocument. Cela m'a fait gagner énormément de temps.