Quote:
Originally Posted by colionel
No this is definitly wrong. A widget writing in core data is a big big mistake. A view should never interact with your model !
If you want to follow the MVC pattern....
|
I am following the MVC pattern. I don't think my approach is so wrong, and I think I may be confusing the issue by saying that I am subclassing UIView. I'm only subclassing UIView or UIImageView because these widgets have a skin, but really it should be an NSObject that contains a UIView/UIImageView. (Each of these widgets has subviews, so I felt it was simpler to subclass UIView rather than creating one extra level of objects...I don't think that really matters. The MVC views are created with nibs.)
In my MVC architecture, I simply have an extra controller level: the widget controller. So in my architecture, sometimes the "view controller" (a controller that controls an entire screen) interacts with Core Data, and other times a "widget controller" (a controller that controls only a small functional object on the screen) interacts with Core Data.
The view level is changed by nibs and images, and is still separate from the control level. I just don't see why it is important to pass everything that interacts with a functional object on the screen through the UIViewController subclass. Some functionality affects only a small widget object (and can get info from/set info in Core Data); other functionality impacts the entire screen.
These two levels should be separate. Otherwise your UIViewController subclasses become bloated simply passing data back and forth that has nothing to do with them. They should create the objects that are on the screen, passing them any data they need, and then receive only messages that affect the screen: navigation, modal views, table updates, etc.
