Re: Acid Test For MVC Design?
Re: Acid Test For MVC Design?
- Subject: Re: Acid Test For MVC Design?
- From: Jeffrey J Barbose <email@hidden>
- Date: Tue, 30 Jul 2002 13:14:43 -0700
I found that, for me, the best way to maintain the separations was to
learn and undersatnd the "bottleneck" data types, and talk through
those.
The datatypes: NSData, NSString, NSDictionary, NSArray.
Express your entire model (backend, datastore, algorithms, everything
that could, theoretically, be run as a service or commandline tool) in
terms of those data types, either extensively or as exportable data.
Then you get the benefit of using IB and the UI widgets with almost no
coding. The Views part of MVC is all (well, 99.999% for most) IB.
The "almost no coding" comes down to passing data from the model,
expressed in the datatypes above, to the Views. all this coding goes
into Controllers.
I have found that writing controllers is quite tedious, because you
mainly write setters and getters to and from views to models and back.
There should be a CB (ControllerBuilder) from apple. :)
This is all WAAAY oversimplified, but it's how i came to my present
understanding of MVC as laid out by Cocoa.
Jeff
On Tuesday, Jul 30, 2002, at 12:58 US/Pacific, Daniel Jalkut wrote:
The hardest part about Cocoa/ObjectiveC programming for me so far is
the unsteady footing I have on the "MVC design" paradigm. I think I
have a good notion of the approach, but sometimes I get stuck trying
to classify a certain class into one of the categories. At times, I
wish I had some kind of "key questions" to ask about the functionality
to help determine what it is. Sometimes, I think I get stuck because
the class I'm looking at inadvertently covers both model and
controller, or both view and model, or perhaps all three.
Does anybody have some kind of "MVC boot camp" - a bunch of examples
of pure MVC design that perhaps quiz the reader to determine the
philosophically correct home for each component. Or just a newsgroup
or source of writing where I could read a lot about the
"classification" thinking that must go along with this design > approach?
Some particulars that confuse me a little, and my attempts at
understanding them:
NSSound - the sound data itself is obviously model. Is the "playback"
best classified as "View" even though it's not seen? I assume that
anything that interacts physically with the user is "view". Does this
mean a microphone input for speech recognition would technically be
"View" as well? Assuming all this is correct, does "NSSound" actually
provide a view and model in one (NSSoundData and NSSoundPlayer) that
are just coupled together for programming convenience? And is the
reason they're coupled together because each of them is relatively
useless as separate objects on their own?
NSString - similarly, does the NSStringDrawing category take NSString
from the realm of model to the realm of view? Or is the
NSStringDrawing category more like "Controller" in that it connects up
the model with the actual view (the screen).
I feel like if I get my head thoroughly wrapped around this stuff
before I embark on a large project, I will save myself a lot of
rewriting/designing.
Daniel
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.