On 30/11/2009, at 1:35 PM, Jason Stephenson wrote: > NSDocument doesn't merely represent the document's data as in a "pure" MVC > design, rather it is a controller for the document's data. The subsection of > the Document-Based Applications Overview entitled "The Role of NSDocument" > makes this abundantly clear. The actual model data for the document is very > often an ivar of the NSDocument subclass. > > A data model should not be required to create controllers for GUI elements as > NSDocument is asked to do by NSDocumentController when a new document is > created. The creation and management of GUI elements is typically a > controller's job, not a model's job. A model should be abstract in the sense > that it is not tied to any particular visual representation of the data. It > should work in a command line application as well as it works in a GUI > application.--Admittedly, this is an ideal. > > While NSDocument doesn't necessarily break MVC, I think the class is poorly > named. It should probably more properly be named NSDocumentController and > NSDocumentController would more properly be named > NSDocumentControllerController, but that's a bit awkward.
Well, I think you're splitting hairs. NSDocument is a generic class, and on its own doesn't really do anything 'modely' but does provide 90% of the structure for it. Whether you then put your model into the NSDocument subclass or in some other way such that the document subclass 'has a' model is up to you. It is correctly named NSDocument because that's what it is - a document, defined as a file on disk representing your app's data. But since subclassing is always necessary, you can name it whatever makes most sense for your particular app. If it's more of a controller for your case, feel free to name it accordingly. It's also not unusual for model objects to support a controller or list of controllers that ultimately link to GUI. MVC does not mean that M is totally isolated from C, it just means that the functions are handled by separate classes. Of course models might need to talk to controllers and so will need to 'know about' them. It's certainly possible to design models in such a way that they are unaware of their C's (KVO for example) but this isn't the only good approach, and allowing M classes to reference C classes is not a violation of MVC. --Graham _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
