views:

523

answers:

1

Does anybody have any NSDocument pros and cons they'd like to share?

In particular:

  • Once you depend on the NSDocument architecture, is it difficult to refactor it out if you need to?

  • Are there performance implications?

  • Does it limit you in certain/many ways?

+11  A: 

(1) Once you go NSDocument, it is hard to go back. That is because the NSDocument architecture does a huge amount of the heavy lifting for you. It creates the basis for a properly functioning multiple document based Cocoa application. You can re-invent that wheel if you want, but it'll be a huge amount of work just to achieve parity.

(2) No; of course, the document architecture consumes some cycles in maintaining state, etc. But you'd pretty much have to do the same if you were to try and roll your own. And the folks on the AppKit team that maintain the document architecture do so because it is their job-- your job is to ship products to customers as quick and best you can. If you can justify building a document architecture as a part of meeting that goal, go for it. If not and you need one, reuse the one you are given.

(3) It limits you to creating a document based application application. :)

Seriously, if you need a document based application, go with NSDocument. If you don't, don't.

I recently wrote a data processing application where all of the per-document data is imported from various text-based files. I don't really have a need to persist the data between sessions -- it is on the nice to have list -- but I still went with NSDocument. It saved me a huge amount of time.

bbum
Great list of answers. Just to add to it, there are also very good UI reasons to go with the NSDocument architecture; it provides a great deal of subtle behaviours that are great for your users and easily missed when first designing the app.
Mike Abdullah