前のパートに戻る 完了して次のパートへ  

  2-1 設計を考える

アプリの設計を考える


このセクションでは、アプリがどのような機能を持ち、その機能を実現するためにどのようなデータ構造にするべきかを考えていきます。

まずは次の図で、概要を把握してください。

ぐるなびAPIを利用して、ぐるなびから店舗の情報を取得します。 取得した情報には、店舗の名称や概要が含まれます。 アクセスしたユーザーは、会員登録をすることにより、店舗にレビューを記載できます。 レビューに、5点満点のスコアと、コメントが含まれます。

あらかじめ、管理画面からぐるなびで使われている都道府県、業態分類を設定しておきます。 これはぐるなびのデータは膨大すぎるため、ある程度検索時にバックエンド側で絞り込んでおくことを目的としています。 0-2 APIとは で説明したように、APIのコールは1日1,000回という制限があります。 この制限も考慮しています。

最終的なアプリも見てみましょう。

最終形

なんとなくイメージがつかめたでしょうか。

必要な機能(View)


このアプリケーションで実装する機能は次の通りです。

  • ユーザー登録・ログイン・ログアウト機能
  • ぐるなびAPIを利用して、都道府県、業態などで店舗を検索する機能
  • 検索した店舗に対してレビューを投稿(登録・編集・削除)する機能
  • 投稿されたレビューに対して、「いいね!」(登録・削除)をする機能
  • レビューされた店舗の平均点やレビュー数を計算して表示する機能。

画面(Template)


  • ログイン/ログアウト画面
  • トップページ(検索条件の入力)
  • 検索結果表示画面
  • 店舗詳細画面(詳細表示、レビュー表示・投稿)

テーブルの設計(Model)


  • User =>Djangoで自動作成されています。
  • Category =>店舗の業態カテゴリです。内容はぐるなびAPIに準拠します。
  • Pref =>店舗所在地の都道府県です。内容はCategory同様、ぐるなびAPIに準拠します。
  • Review =>店舗に紐づいてレビューを保存。

テーブルはこの4つです。 店の情報を持つテーブルは必要ありません。 その代わりにぐるなびAPIを使うのでしたね。

このコースの評価は?