今まで扱ったことのあるDjangoとRailsとSymfonyをコマンドやソースをとりあげて徹底比較してみた。
| フレームワーク | Django | Rails | Symfony |
|---|---|---|---|
| コマンド | |||
| プロジェクトの作成 | python /usr/local/bin/django-admin.py startproject プロジェクト名 | rails プロジェクト名 | symfony generate:project プロジェクト名 |
| アプリケーションの作成 | python manage.py startapp アプリケーション名 | ruby script/generate アプリケーション名::モデル名(テーブル名の単数形) カラム名:データ型 カラム名:データ型 ...（rails2.0以前） | symfony generate:app アプリケーション名 |
| CRUD機能＋テーブル生成 | アプリケーションディレクトリのmodels.py に class モデル名(models.Model): カラム名と同じ名前の変数 = models.データ型Field(u"編集フォーム上のラベル名", オプション) カラム名と同じ名前の変数 = models.データ型Field(u"編集フォーム上のラベル名", オプション) ... ルートディレクトリのsettings.pyのINSTALLED_APPSに 'プロジェクト名.アプリケーション名',を追加 python manage.py syncdb でテーブルが作成される。 アプリケーションディレクトリにadmin.pyを作成し、 from django.contrib import admin from プロジェクト名.アプリケーション名.models import モデル名 class モデル名Admin(admin.ModelAdmin): pass admin.site.register(モデル名, モデル名Admin) と書くと管理画面にモデルのCRUD機能が追加される。 フロント画面は自分の手で書くしかない。 |
ruby script/generate モデル名(テーブル名の単数形) カラム名:データ型 カラム名:データ型 ... でCRUD機能が作成されるがこの時点ではまだテーブルが作成されてないから、警告が出る。 db/migrateディレクトリの中にあるYYYYMMDDHHiiss_create_テーブル名.rbを開き、サイズや必須等のオプションを編集 rake db:migrate でテーブルが作成され、CRUD機能が使えるようになる。 モデルをフロントと共有した管理画面を作るには、 ここが詳しい。 管理画面を自分の手で書くのが嫌なら、ActiveScaffoldを使うという手もある。 |
config/schema.ymlを編集(書き方はDoctrineかPropelによって異なる) モデルとテーブルを一気に作成するコマンドは symfony doctrine:build --all --and-load --no-confirmation(Doctrineの場合) symfony propel-build-all(Propelの場合) CRUD機能を使えるコントローラとビューを生成するコマンドは symfony doctrine:generate-module --with-show --non-verbose-templates アプリケーション名 モジュール名 モデル名(Doctrineの場合) symfony propel-generate-crud アプリケーション名 モジュール名 モデル名(Propelの場合) ※注意事項 symfonyは他のフレームワークと違い、schema.ymlを変更してモデルを変更するたびに、全テーブルを削除して入れ直すので、変更前には必ずバックアップを取ること。 管理画面の作成 symfony doctrine:generate-admin アプリケーション名 モデル名 --module=モジュール名 このコマンドによって作られた管理画面はレイアウトがシンプルなので、凝ったレイアウトの管理画面を作るプラグインに sfAdminDashPluginというのがあるが、カスタマイズする上で融通が利かないので、あまりお勧めできない。 |
| 使用プログラミング言語の対話型インタプリタの起動 | python | irb | php -a |
| フレームワークの環境変数が設定された対話型インタプリタの起動 | python manage.py shell | ruby script/console | php -a ＜？php define('SF_ROOT_DIR', realpath(dirname(__file__))); define('SF_APP', 'myapp'); define('SF_ENVIRONMENT', 'prod'); define('SF_DEBUG', 0); require_once(SF_ROOT_DIR.DIRECTORY_SEPARATOR .'apps'.DIRECTORY_SEPARATOR .SF_APP.DIRECTORY_SEPARATOR .'config'.DIRECTORY_SEPARATOR .'config.php'); |
| 開発用サーバーの起動法 | python manage.py runserver (0.0.0.0:ポート番号 ※省略した場合は8000番) | ruby script/server (-p ポート番号 ※省略した場合は3000番) | - |
| 注意事項 | 複合主キーはサポート外。 | テーブル名は複数形、モデル名は単数形。複合主キーはサポート外。 | yamlを書き換えたら、必ずsymfony ccを実行すること。 |
| アピールポイント | 管理画面の生成が容易で、カスタマイズも自由自在。 | CRUD機能を一瞬にして作る。カラムの追加、変更も容易。 | PHPしか知らない、でもCakePHPよりはレベルの高いことをしたいという人にお勧め。 |
| IDE（総合開発環境） | Aptana Pydev, Net Beans | Aptana RadRails, Net Beans | Eclipse PDT, Aptana PHP |
結論
管理画面作成にはDjango、フロント画面作成にはRailsが良い。命名規則はテーブル名はDjangoのアプリケーション名_複数形、主キーはid、外部キーはテーブル名_idにしておき、多対多の中間テーブルは主キーにidを付けておこう。(Djangoはこの仕様のため。)先にRailsで中間テーブル以外のテーブルを作成し、それをDjangoでpython manage.py inspectdb > アプリケーション名.pyとやれば既存のDBからモデルを生成してくれる。そこでRailsで作成したDBはschama_migrations以外は全部削除して、Djangoにテーブルを作成させる。その際、models.ForeignKeyとかmodels.ManyToManyFieldとか設定すれば勝手にFKを貼ってくれるので超便利。これでDjangoとRailsでDBを共有化できるわけだ。またDBを共有するに当たってはPostgresqlをお勧めする。MySQLはDjangoやPythonのバージョンによってはWindowsで動くドライバがまだ開発されていないことがあるからだ。また、SQLiteは共有化したらファイルの位置とか設定が煩雑になるのでお勧めしない。
