0

少なくとも UITableViewDataSource が関連するクラスによって採用されている場合、UITableView を使用してリスト ビューを作成できます。以下の質問があります。

section と row に基づいて、コントロールがデータ ソース メソッドを介して作成され、UITableView インスタンスに返されるように設計されているのはなぜですか。UITableViewDataSource を使用せずに、UITableView インスタンスでこれらすべての情報を提供してみませんか。それはどのような違いをもたらすでしょうか？

EDIT1 : @hermann および @JOhn: MVC パターンを破ると述べました。コントロールのようなカスタム UITableView を自分で作成していると仮定しましょう。データを UITableView に直接渡すのではなく、行とセクションに追加する必要がある関連するサブビューと、関連するヘッダーのみを渡すように設計します。これでMVCが壊れることはないと思います..私は正しいですか? しかし、それでも、現在の UITableView 実装スタイルが解決する問題があります。メモリ使用量を肥大化させる代わりに、コントロールと画像を再利用する機能です。

4

2 に答える 2

1

まず、そうすることで MVC パターンに固執することができます。ビューを意味するUIオブジェクトは、ビジネスデータであるモデルと直接通信するべきではありません。さらに、コントローラーに属するビジネスロジックを実行するべきではありません。

第 2 に、UITableView オブジェクトをサブクラス化する必要がなく、より柔軟です。

第 3 に、完全な概念は、パフォーマンスとメモリ管理の観点から非常に効率的です。テーブル内に表示される可能性のあるすべてのデータを事前にロードする代わりに、「今すぐ知る必要がある」ベースで、フェッチまたは計算することができます。さらに、データ コンテナー、特にイメージのように一度メモリを消費するものは、デリゲート/データ ソース メソッドを使用してデータが提供されるとすぐに解放できます。

もちろん、UITableView のサブクラスでも原則として同じことができます。これにより、コードの保守性が向上したり、時間を節約したり、個別に機能したりすることはないと思います。

MVC に固執したくない場合は、自由にテーブル ビューをサブクラス化し、そのすべてのデータを init メソッドで渡すか、テーブル ビューのサブクラスを有効にして、Web サービスやデータベース、またはデータがどこからでもすべてのデータをロードできるようにします。 . また、問題が発生してガイダンスを求めて Google に戻ってきた場合は、「確立されたベスト プラクティスや MVC パターンに固執しないのはなぜですか?」などの厄介な返信に備えてください。など。

あなたのテーブルがかなり静的な値を表示するだけの場合、たとえば、それが単にナビゲーションのドリルダウンなどのメニューとして機能する場合など、この概念は少しばかげているように見えるかもしれません。でも痛くないです。そして、データ提供のより複雑なタスクに関しては、確かに利点があります。

チャンスを与えてください。試してみる！

于 2013-03-06T15:07:25.497 に答える
1

MVC の場合、モデル、コントローラー、ビューの役割を明確に分離する必要があります。ビュー (テーブルビュー) がデリゲートからデータを要求できるようにすることで、ビューを非常に一般化することができます。

デリゲート パターンを使用すると、コントローラは必要に応じてデータを「ステージング」し、tableView の必要に応じて tableView に渡すことができます。tableView は、データがどこに来るか、どのように変換されたか、どの ADT が使用されているかなど気にしません。データがどこにあるのか、またはそのデータが何であるかについては完全に無知です。このセクションと行のこの場所にこの文字列を表示する必要があることはわかっています。

于 2013-03-06T15:07:36.963 に答える