質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

87.78%

クライアントアプリのモデルについて

解決済

回答 3

投稿 編集

  • 評価
  • クリップ 1
  • VIEW 1,389

score 300

ネイティヴアプリ開発でもjavascriptによるSPAアプリ開発でも同じかとはおもうのですが、MVCのモデルの設計が今ひとつわかりません。

入門書などで勉強中の私の解釈ですと、

・例えばサーバー側のAPIを叩いてデータを取得する際に、コントローラーやビューから直接叩くのではなくモデル経由でデータを取得する形にする。

・データの更新などがある場合も同様に、コントローラーからなどからはモデルを更新する。サーバーへの更新処理はモデルにまかせる。

で、疑問に思ったのが以下のような画面(twitterみたいなイメージ)があるとします

>一覧画面(ユーザーがコメントした一覧がみれる)
・ユーザー名
・コメント(簡易版)
・コメントにいいねされた数

>詳細画面(コメントの詳細がみれる)
・ユーザー名
・コメント(全内容)
・コメントがいいねされた数
・コメントへのいいねボタン

こんな画面があった場合にモデルの設計としては、以下のようなイメージになります。
コントローラ、ビューからは以下のような形になると思います。
・一覧画面はCommentListモデルからデータ取得
・詳細画面からはCommentモデルからデータ取得

で、詳細画面からいいねボタンを押した際の処理はどんな感じになるのでしょうか?
CommentモデルとCommentListモデルのlistの中身のlike_numを両方更新しないといけないと思うのですが、いまいちどんな実装になるのかが想像できません、、、、

class Comment
{
    var user_name;
    var comment;
    var like_num;

    func like()
    {
        // いいね押された時の処理
    }
}

class CommentList
{
    var list // Commentクラスのリストをもつ

    // コンストラクタ
    function CommentList()
    {
        this.list = APIから取得してきたり
    }
}

すみません、上記のコードはプログラミング言語は適当でなんとなく伝わりそうな形で書きました


★追記の質問になります

Userの状態も追加された場合
たとえば、コメントしたユーザにたいしてフォローするなどのアクションを追加するとします。

その場合、フォローしているかどうかも管理しなくてはならなくなるので以下のようなイメージになりますでしょうか?

また、Userはidで一意になるものなので、同じidのUserクラスが作られることを考慮すると、UserManagerクラスみたいなものも作ったりするのでしょうか?


class User {

    var id

    var name

    var is_follow

}

class Comment {

    var id

    var comment

    var like_num

    var user // ★Userクラスの参照

}
  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 3

checkベストアンサー

+2

コメントモデルとコメントリストモデルの2つがあると考えること自体がおかしいです。
それぞれのユーザー名とコメントといいね数は同じものですから、それを2つのモデルで別のデータとして管理してはいけません。今回の場合、ユーザーの集合と、それに対するコメントと、それに対するいいね数が管理されているモデルは1つです。それはサーバーのデータベースで管理されています。そのサーバーのデータベースにアクセスする処理をまとめて1つのモデルクラスにすればいいです。そして、そのモデルをどう見せるかかビューで、1つのモデルから、複数のユーザー名とコメントの一部といいね数を取り出して一覧として表示するビュー(一覧画面)と、同じ1つのモデルから、指定された1つのユーザ名とそのユーザーのコメント全体といいね数を取り出して表示するビュー(詳細画面)の2つがあるということです。
そして、いいねボタンが押された時に、必要な処理を実施するのがコントロールです。いいねボタンが押されたら、コントロールは、モデルに対していいね数のカウントアップを依頼し、現在表示されているビューに対して現在のモデル状態で画面を再表示する依頼をすればいいだけです。

ビュー毎にモデルを作ると、今回の質問のように本来1つのデータなのに別々のモデルに同じデータが存在してしまい、その整合性を気にしないといけなくなり、処理が複雑になります。それはMVCモデルではありません。そういう事態にならないようにするために本来1つのデータは1つのモデルで管理するのがMVCモデルです。

(10/9 8:43追記)
勘違いされるといけないので、少し補足します。
質問のコードのようにCommentクラスとCommentListクラスの2つを作ること自体は間違いではありません。その2つが別々に存在する別々のモデルであると考えることが誤っています。1つのモデルの中のデータ構造として、Commentクラスインスタンスの集合を持つCommentListクラスインスタンスが1つあると考えるのは正しいです。
例えば、詳細画面を表示するなら、
CommentListクラスに指定ユーザ名を持つCommentクラスインスタンス(CommentListクラス内で保持しているインスタンス)を返却するメソッドを作り、詳細画面のビューからそのメソッドを呼び出しCommentクラスを取得します。そしてCommentクラス内の各プロパティを参照して詳細画面を作ります。そして、いいねボタンが押されたら、Commentクラスのlikeメソッドを呼び出していいね数をカウントアップしてもらえばよいです。その場合カウントアップを依頼したCommentクラスは、CommentListクラス内で管理されているインスタンスですから、CommentListの方にも何か依頼する必要はないかと考える必要はありません。


投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/10/09 12:41

    丁寧にご回答いただきありがとうございます!
    なんとなくわかったのですが、さらに疑問が出てしまって、、、質問に追記しましたのでこちらもあわせてご確認いただけないでしょうか?

    図図してくすみません、、、

    キャンセル

  • 2015/10/09 14:13 編集

    追加で質問されていることは、MVCの考え方というよりもモデル内のデータ構造の設計方法に関する質問です。

    > その場合、フォローしているかどうかも管理しなくてはならなくなるので以下のようなイメージになりますでしょうか?

    データ構造の設計がこれでいいか?と聞かれても基本的にあなたのやりたいこと次第です。あるユーザーが誰にフォローされているか知らないけど誰かにフォローされていることがわかればよいのであればそれでよいと思います。ただ、複数のユーザーにフォローされる設計であれば、少なくともbooleanではなくカウンタにする必要があると思います。
    また、誰にフォローされているかも表したいなら、フォロー元のユーザー一覧をリストとして持つべきだと思います。

    > また、Userはidで一意になるものなので、同じidのUserクラスが作られることを考慮すると、UserManagerクラスみたいなものも作ったりするのでしょうか?

    UserManagerというのが何をするのかわかりませんが、作りたければ作っていいと思います。新しいユーザーを作る際に、これまでに作らているユーザーIDと重複しないかチェックしたいだけであれば、全てのUserの集合を持つUserListのようなものを作るだけでもいいかもしれません。
    他にもいろいろ管理したいことがあるのであればUserManagerという名前がふさわしいのかもしれません。

    キャンセル

  • 2015/10/10 22:21

    なるほど、ありがとうございました!

    キャンセル

0

このような場合、CommentListを文字通りCommentのリストとして持たせることで、両者でデータに齟齬が生じるような事態を避けることができます。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/10/07 01:15

    ご回答ありがとうございます

    例えば一覧を表示する画面が2種類あった場合(例えば1時間以内の投稿一覧と2時間以内の投稿一覧)、CommentListモデルにそれぞれのリストを別プロパティ変数としてもつとします。

    どちらのリストにも存在するデータがある場合に、それぞれのデータを更新するようなロジックになると思うのですがそのような実装が一般的なのでようか?






    

    キャンセル

0

コメントモデル(オブジェクト)がいて、
コメントリストは複数のコメントモデルへの参照を持つ感じになるかと思います。

いいねが押されたらモデルを更新します。モデルリストにいるモデルは参照なので書き換える必要はありません。モデルが書き変わったら、モデルを購読しているビューに通知したりします。

guiのmvcって難しいですよね。僕もよくわかりません。
特にコントローラよくわかりません。
JSだとbackboneあたりの設計が参考になる気がします。オブザーバーパターンで書かれています。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 87.78%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る