• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
MVC, DBA, CoreData (was: CoreData : fundamental (or not) questions)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

MVC, DBA, CoreData (was: CoreData : fundamental (or not) questions)


  • Subject: MVC, DBA, CoreData (was: CoreData : fundamental (or not) questions)
  • From: Joshua Scott Emmons <email@hidden>
  • Date: Sun, 19 Mar 2006 15:14:19 -0600

No, it doesn't.  The [NS]document object here is a controller.
...
The [Managed Object] context is another controller object.

Many thanks for the clarifications! It's things like this that I would think could be better integrated into "The Model-View- Controller Design Pattern" documentation. I've never really understood what it means that NSDocument "combines controller and model roles for each document". It's like, flip a coin. If it comes up head, it's Model. If tails, Controller.


Core data is even worse. We get explanations like, "The MVC and object modeling design patterns are essential determinants of the Core Data architecture," and "Core Data is tightly integrated with the Cocoa bindings technology." But I haven't found a place yet where it's laid out that a MOC is a Controller and the store is a Model and who knows what the persistent store coordinator is? And the only place I've ever seen an explanation of bindings and CoreData is when you have IB create an interface for you by dragging an entity onto a window.

And then there's particle/wave-like arguments to top it off. The MOC can be a Model (when you're using it as a scratch pad) -or- it can be a Controller (when you're using it to dispatch messages to the store coordinator).

Now that I think about it, my confusion is that both NSDocument and NSManagedObjectContext are conceived as model-controllers. Perhaps a better explanation of how this dual-purpose class of object fits between the Model and Controller layers could be provided. Something more than "A model-controller [is] a controller whose management responsibility is shifted towards the model layer." Something just a tad more concrete. Oh well. I've filed a documentation enhancement request. ;-)

Cheers,
-Joshua Emmons

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: MVC, DBA, CoreData (was: CoreData : fundamental (or not) questions)
      • From: mmalcolm crawford <email@hidden>
References: 
 >CoreData : fundamental (or not) questions (From: WhiteContainer <email@hidden>)
 >Re: CoreData : fundamental (or not) questions (From: Joshua Scott Emmons <email@hidden>)
 >Re: CoreData : fundamental (or not) questions (From: WhiteContainer <email@hidden>)
 >Re: CoreData : fundamental (or not) questions (From: Joshua Scott Emmons <email@hidden>)
 >Re: CoreData : fundamental (or not) questions (From: mmalcolm crawford <email@hidden>)

  • Prev by Date: Fwd: BiDirectional NSLevelIndicator
  • Next by Date: Fwd: BiDirectional NSLevelIndicator
  • Previous by thread: Re: CoreData : fundamental (or not) questions
  • Next by thread: Re: MVC, DBA, CoreData (was: CoreData : fundamental (or not) questions)
  • Index(es):
    • Date
    • Thread