25

次のクラスがあるとします。

意見

@interface ArticleView : UIView
@property IBOutlet UILabel *titleLabel;
@property IBOutlet UILabel *bodyLabel;
@end

モデル

@interface Article : NSObject
@property NSString *title;
@property NSString *body;
@end

コントローラ

@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

オプション1

  • PRO:ビューとモデルの両方が互いに結合されていません。
  • CON:コントローラーは、モデルとビューの両方の詳細を知る必要があります。

オプション 2

  • PRO:コントローラー コードは軽量で柔軟です (ビューまたはモデルが変更されても、コントローラー コードは変わりません。
  • 短所:ビューとモデルが結合されているため、再利用性が低くなります。

オプション 2 では、モデルへの参照を保持するように ArticleView を変更する必要があります。

@interface ArticleView : UIView
@property IBOutlet UILabel *titleLabel;
@property IBOutlet UILabel *bodyLabel;
@property Article *article;
@end

次のように、アーティクル セッターを上書きして、それに応じてビューを更新できます。

- (void)setArticle:(Article *)newArticle {
    _article = newArticle;
    self.titleLabel.text = _article.title;
    self.bodyLabel.text = _article.body;
}

私の質問は、OO と iOS/MVC のベスト プラクティスに関して、これら 2 つのオプションのどちらが最適かということです。

私は確かに両方が使用されているのを見てきました。UITableViewCell サブクラスで一般的に使用される OPTION 2 を見てきました。

また、ビューとモデルは再利用可能で、何にも依存しないように設計する必要があることも読みましたが、ビューコントローラーは再利用可能性が最も低いことを意図しています。

私の直感は、ビューコントローラーがモデルをビューにバインドするという汚い仕事をして、モデルとビューを独立させ、お互いを認識させないという単純な理由で、OPTION 1 を使用することです。しかし、一部のビューは 1 つのことだけを行うように設計されているため、それらを特定のモデルに直接関連付けることはおそらくそれほど悪くはありません。

これについてのご意見をお待ちしております。

4

6 に答える 6

3

はい、あなたは主題の理解を示しました。

オプション 1 は MVC の古典的な構造であり、提示された 2 つのデフォルト ルートとしてお勧めします。

オプション 1 がより純粋な定義であるからといって、それを可能な限りどこでも適用する必要があるという意味ではありません。

私が最も頻繁に行う逸脱は、実装が非常に具体的で再利用されていない場合です。実装が非常に小さく、非常に特殊化されており、再利用可能ではなく、大幅に成長しない場合に、専用のコントローラー タイプを導入すると、記述して維持するコードが増えるだけです。プログラムが V と C を 1 つの実装に折りたたむのに適していて、小さなもの (数十行のコードなど) に収まる場合は、OPTION 2 の使用について心配する必要はありません。

現実はそれよりも複雑ですが、要点は次のとおりです: #1 に従う必要があるとは思わないでください。数年間。あるプログラムから別のプログラムに移行すると、出荷されたプログラムに多くの変更が導入される可能性があります。これは回避できたはずです。

オプション 2 の使用は少数派です。不明な場合は、オプション 1 を使用してください。

いずれにせよ、モデルはビューやコントローラーについて知っているべきではないと思います。

私にとって、再利用可能なコンポーネントを作成するときは、厳密に順守することがより重要です。

于 2013-05-13T07:38:26.747 に答える
1

率直に言って、オプション 2 を自分で実行することもあります。しかし、オプション 1 は「規格外」です。

于 2013-05-13T07:25:13.723 に答える
0

他の人が言ったように、オプション 1 はより純粋なアプローチです。コントローラーは、ビューとモデルの間の「ジャンクション ボックス」である必要があります。

ただし、このタイプのアプローチ (たとえば、Microsoft が MVC と呼ぶフレームワーク) の実装の多くは、オプション 2 に適しています。確かに Microsoft の場合、View と Model が互いを認識しているという事実により、IDE は多くのボイラープレート コードを作成できます。 、そしてあなたの「トラブル」を救います。これの利点は、「配線」コードではなく「関数」コードの作成に時間を費やすことです。したがって、純粋であろうとなかろうと、それらがどこから来ているのかを理解できます.

ソフトウェア開発ではよくあることですが、オプション 1 とオプション 2 のどちらを選択するかは、純粋主義か実用主義かにかかっています。

于 2013-05-13T07:41:58.107 に答える
0

このトピックに関する Apple の公式ガイダンスに関しては、Objective-C プログラミングの概念ドキュメントのMVC as a Compound Design Patternセクションで両方のアプローチについて説明していますが、オプション 2 よりもオプション 1 を Apple が好むことを明確に示しています。コンピテンシーには、オプション 1 のみがリストされています。

オプション 1 のアプローチを実装したことを後悔したことはありませんが、手抜きをしてモデルとビューを直接対話させようとしたときに、後で戻ってシステムを変更する必要が生じたときに後悔することがよくありました。

于 2013-05-13T14:45:40.620 に答える
-1

オプション 1 は MVC です。オプション 2 はそうではありません。

OO は実際には異なるレベルにあります。モデル、ビュー、およびコントローラーのオブジェクトがあるため、OO になるためにこれ以上のことはできません。

もちろん、両方のオプションが機能しますが、MVC が存在するのには理由があります (このような一般的な読み取りを既に行っていると思います)。原則に従えば、コードが読みやすく、理解しやすく、再利用しやすいことがわかります。 MVCの。

于 2013-05-13T07:18:04.580 に答える