Edited at

Symfonyでタスク管理アプリ作ってみた

More than 1 year has passed since last update.

フレームワークの勉強のためにSymfony3でタスク管理アプリを作ってみました。まだ作ってる途中ですが、理解を深めるために作業内容をまとめてみます。少しは何かの参考になるかもしれません。

1.コントローラ編

2.エンティティ編

3.フォーム編

4.サービス編

5.番外編:GuardとEntityを使った認証


方針

作業を始めたときの最新バージョン、Symfony 3.2を利用します。

Symfonyフレームワークを覚えるのが目的なので、JavaScriptはjQueryを軽く使う程度で。古き良きウェブサイトを作ります(SPAではないです)。


参考

参考にしたのはSymfonyのウェブサイト、それと前に購入しておいた「基本からしっかり学ぶSymfony2入門」という本です。利用しているSymfonyはバージョン3ですが、Symfony2入門のコードはほとんど使えた気がします。Symfonyは想像以上に互換性を重視しているみたいです。


正直にいうと、Symfonyのサイトは読みづらい&理解しづらいです。Symfony2入門があると理解が早いと思いました。



インストール

次のようにコマンドを打ってください。


  1. git clone https://github.com/asaokamei/TaskComplete

  2. cd TaskComplete

  3. composer install


  4. TaskComplete/var/sqliteディレクトリに書き込み権限があること。

  5. php bin/console doctrine:schema:update --force

これで動きます。最低限の初期データを登録するには、


  1. run php bin/console server:run

  2. ブラウザーで次のURLにアクセス: http://localhost:8000/settings/initialize

  3. フォームにチェックを入れてボタンをクリック。


セットアップでDBにデータを書き込むより、DoctrineFixturesBundleを使うほうがいいのだろうけれど。



データ構造

少し複雑な構造のアプリを作ってみたかったので、データは3層構造にしました。


ER図

task_project > task_group > task_task

という構造になってます。


プロジェクト詳細画面

プロジェクトの詳細画面を見ると分かりやすいと思います。これは「TaskComplete Application」というプロジェクトの詳細です。

プロジェクト内に複数のターゲット(tasksとtestがあります)があり、さらに複数の作業項目があります。

project > targets > tasks


DB上ではターゲットはGroupになります。途中で名前を変えたのですが、DBまで変更してない…


ターゲットですが、イメージとしてはアジャイルのスプリントみたいな区切りで、だいたい1週間〜1ヶ月ぐらいの作業量というイメージです。


サマリ画面

わざわざ3層構造にしたのは、色々な角度から仕事のプライオリティや進捗具合を見たかったからです。


By-Target画面

ターゲットをずらりと日付順に並べます。今、もっとも緊急の作業は何かひと目で分かるページです。


By-Date画面

作業項目をずらりと日付順に並べます。今日や明日に行いたい作業を把握できます。

個人的なポイントは、24時間以内に終了したタスクは表示してあること。これで、達成感を味わいたいなと。


DB設計してたときは退屈だとしか思えませんでしたが、画面を作ってみたら俄然やる気が出てきました。



その他、色々


Symfonyフレームワーク

現状でのSymfony最新版、バージョン3.2.1を利用してます。インストールはcomposer使った記憶があります。

大事な点として、フレームワークと一緒にSensioFrameworkExtraBundleを利用しています。Symfonyの開発元が作っているバンドルで、Routeアノテーションを利用できるようになります。

ORMとしては、Doctrine2を利用します。Symfonyでは標準のようなORMですね。また、データベースにはsqliteを利用してます。マイグレーションのために、doctrine/doctrine-migrations-bundleもインストールしました。


アーキテクチャー

開発するにあたって、レイヤーアーキテクチャーを念頭に作ってみました。(参考:中規模Web開発のためのMVC分割とレイヤアーキテクチャ)。

アプリケーションを大きく4つの層から考えるのですが、フレームワークでのクラスとの対応をシンプルに書くと、こんな感じになるでしょう。

レイヤー
対応するクラスやパッケージ

プレゼンテーション層
twigテンプレート

アプリケーション層
controller class

ドメイン層
entity class

インフラストラクチャ層
Doctrine2 ORM

このテーブルにあるクラスやサービス以外に、大量のクラスを書いてくことになりますが、作ってるクラスが属するレイヤーはどれかを考えて、上位のレイヤーに依存しないことを念頭に置いて開発します。