Is NSDocument the right choice when most application documents are not file based?

Question

I am writing a Cocoa Mac application that will manipulate database files that can be easily implemented using NSDocument technology, as they relate directly to disk files.

However, most applications will manipulate the elements of this database. When a user opens a database item, a new window should appear, allowing you to view, edit, save the item, so the database item is not directly associated with the disk file. Please note that here are canceled and canceled.

Is NSDocument technology NSDocument for database windows and database element windows, or is there a better approach?

Answer 1

I think using NSDocument would be a great choice. This will allow you to use most of the features provided, such as NSDocumentController , undo support, window management, etc. You will have to override some methods, such as loading and saving. Perhaps it would be difficult to make the "Open Recent" menu work correctly for these documents (perhaps use a custom URL scheme?). The disadvantages of using NSDocument are ... I can't think of. You will have to write everything from scratch, and it would be even more difficult to integrate them into the rest of the application.

Answer 2

I built my application based on NSDocument - well, actually NSPersistentDocument , as it provides access to Core Data services to store my object graph. It worked great for me, and I did not find any flaws.

When you plan to work with an NS(Persistent)Document , you will have to come up with some kind of mechanism to pass an instance of your document to the various controllers that you will create to control the views / windows and their associated data. I implemented this by creating a generic View controller class that can hold a reference to my instance of NSPersistentDocument . All of my view controllers are subclasses of this universal controller, and thus can easily access Core Data services.

My application manages 15 master data objects with volumes varying from hundreds to hundreds of thousands of instances for each object. Not part of your original question, but you might want to use Core Data to save objects. I found this to be a real-time splash screen when creating my application (previously worked with PHP, Java and various DB layers, which usually do not contribute much to performance).