Re: Getting a handle on CoreAnimation and MVC
Re: Getting a handle on CoreAnimation and MVC
- Subject: Re: Getting a handle on CoreAnimation and MVC
- From: Quincey Morris <email@hidden>
- Date: Mon, 23 May 2011 22:05:54 -0700
On May 23, 2011, at 18:27, Graham Cox wrote:
> Am I worrying too much? Or is there a better way to think about layers that means I don't have to give up on strict MVC?
I'll take a stab at this -- not pontificating, just expressing an opinion, and a hesitant one at that ...
There's nothing *intrinsically* wrong with the data model encapsulating the appearance of "views", if the appearance *is* the data that needs to be manipulated. You may, therefore, have made things hard for yourself in this exercise by choosing a game as your paradigm for investigation. It seems likely to me, in a general sort of way, that a game is indeed going to concerned at the data model level with both the appearance of the views and to some extent the UI interactions the user will face.
The "V" in "MVC" doesn't really refer specifically to views (and the baggage they drag in like windows and input methods, etc), but to the logical concept of a "view" of the data -- an arrangement, a filter, a massaged representation of the underlying data model. It's a pragmatic decision, in any given application, where to draw the line between MVC "V" and MVC "M".
What if you use a different kind of application to investigate Core Animation, one that (Core Animation aside) fits much more easily into the MVC paradigm? I'm thinking of something like a simple catalog (or store) application, where the product database is the data model. There could, of course, be product images or movies in the database, so this example would not be totally devoid of questions about how the display of things interacts with the data model, if it does.
The other thing that comes to mind is that I'm pretty convinced there is no viable MVC pattern, as such, except for the simplest applications. Every real-life example I've worked on has had a "back end" data model (the "M"), but has always had an auxiliary data model embedded within the "C" (such as a window controller) which meditates between the back end and the "V" (the user interface). In this sense, the MVC pattern is really a M(MC)V pattern, and sometimes it's even a M(MC)(MVC) pattern, if the views themselves are complex enough. It's possible that layers properly belong to one of the mediating data models, not to the back end.
Maybe you are worrying too much, but if you figure it out, let us know. :)
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden