ios - Should views hold model references? -

let's have following classes:

view

@interface articleview : uiview @property iboutlet uilabel *titlelabel; @property iboutlet uilabel *bodylabel; @end 

model

@interface article : nsobject @property nsstring *title; @property nsstring *body; @end 

controller

@interface articleviewcontroller : uiviewcontroller @property article *myarticle; @property articleview *myarticleview; - (void)displayarticle; @end  @implementation - (void)displayarticle {     // option 1     myarticleview.titlelabel.text = myarticle.title;     myarticleview.bodylabel.text = myarticle.body;          // ... or ...      // option 2     myarticleview.article = myarticle; } @end 

option 1

• pro: both view , model aren't coupled each other.
• con: controller needs know details of both model , view.

option 2

• pro: controller code light , flexible (if view or model change, controller code stays same.
• con: view , model coupled , therefore less reusable.

in option 2, articleview have changed hold reference model:

@interface articleview : uiview @property iboutlet uilabel *titlelabel; @property iboutlet uilabel *bodylabel; @property article *article; @end 

the article setter can overwritten update view accordingly, so:

- (void)setarticle:(article *)newarticle {     _article = newarticle;     self.titlelabel.text = _article.title;     self.bodylabel.text = _article.body; } 

so question is, 1 of these 2 options best in terms of oo , ios/mvc best practices?

i've seen both being used. i've seen option 2 used commonly in uitableviewcell subclasses.

i've read views , models should designed reusable , not depend on whereas view controllers meant least reusable of bunch.

my gut feeling use option 1 because i'd rather view controller dirty work of binding model view , let model , view stay independent , unaware of each other. since views designed 1 thing perhaps it's not bad have them tied specific model directly.

i'd love hear opinions on this.

it's not either/or decision. first option more typical of apple's version of mvc; it's true in ios model , view don't talk each other directly, , controller of coordinating between them. however, it's not unreasonable have custom view knows specific classes within larger model. might have articleview knows article, articleview should still receive article displays controller instead of getting directly larger model.

one of goals of mvc make model , view classes more reusable. if keep articleview simple, controller has of work of interpreting article, may losing reusability -- every time want reuse articleview new view controller, have reproduce code interprets article articleview. alternately, use same view controller class manage articleview. neither of these "reusable."

at same time, have acknowledge there's natural coupling between article , articleview virtue of fact articleview designed display relevant details of article, whether gets them directly article or has them set view controller. if article changes, there's strong probability articleview have change whether knows article or not.

so, though article may model class, can okay have view knows it. don't want articleview knows larger model , tries fetch articles model itself. limits articles can display in articleview can found articleview looks -- prevents displaying articles other sources.