書いている人間は、お仕事でDjangoをメインにしていて、最近Railsを勉強中という感じです。
なので、バランス悪いのは許してください。
Djangoに比べるとRailsはバージョンアップごとに変化が大きいので取り逃しはかなりありそうです。
内容は気づいたたびに追加していく予定。
設計思想
CoC
設定より規約ってやつ。
Railsを触れば触るほど出来た仕組みだなぁと思う。ほとんどの場合うまくいきそう。Djangoもある程度はあるけど、frameworkとして組み込まれてる感じはない。だから迷う、そして失敗する。
mvc
大きな違いはviewのところ。
Railsは一般的なMVCアーキテクチャーで語られているが、DjangoはわざわざMVTと言っているだけあって、Templateに対する意識が強い。
Djangoとしては、Templateはエンジニアだけではなく、デザイナのような人に任せる可能性がある、だからpythonを持ち込まない、としている。
逆にRailsは積極的にエンジニアに任せようとしている気がしている。
hamlとかsassとか。
Model関係
| 比較対象 | Django | Rails |
|---|---|---|
| 表名 | {アプリケーション名}_{モデル名}(全部小文字) | {モデル名}(全部小文字) |
| 自動で付加されるカラム | id | id created_at updated_at |
| 1対1の関係 | models.OneToOneField(モデルのクラス) | has_one :{モデル名小文字} |
Query関係
参照
いろいろ見てて、そもそもわかったこと。
DjangoはQuerySetという言い方しているこの仕組みは、基本的には遅延評価という仕組みが備わっている。
一方でRailsは基本的にはその場で実行される(たぶん)。
where,all,page,order,includeじゃないときはその場でSQLが実行される。
逆に、find_in_batchesのような仕組みで遅延評価に近い動きをするという感じ。
どちらにしても、気を付ければどちらでもOKだが、書き方がかなり変わってくると思う。
Djangoのfilterはwhereと似ていて、whereの戻り値はActiveRecord_Relationになるので、メソッドチェインで書ける。
| 比較対象 | Django | Rails |
|---|---|---|
| pk参照1件 | 〇.objects.get(pk=1) | 〇.find(1) |
| pk参照複数 | list(〇.objects.filter(pk__in=[1,10])) | 〇.find([1,10]) |
| 指定なし1件 | 〇.objects.all()[0] | 〇.take |
| 最初の1件 | 〇.objects.first() | 〇.first |
| 最後の1件 | 〇.objects.last() | 〇.last |
| 最初の3件 | 〇.objects.order_by('id')[0:3] | 〇.first(3) |
| 条件一致した1件目 | 〇.objects.filter(age=10)[0] | 〇.find_by(age: 10) |
| 全件 | 〇.objects.all() | 〇.all |
| 条件-等価 | 〇.objects.filter(name='AAA') | 〇.where(name: 'AAA') |
| 条件-in | 〇.objects.filter(type__in=[1,2,3] | 〇.where(type: [1,2,3]) |
| 範囲指定 | 〇.objects.filter(pub_date__range=(start_date, end_date)) | 〇.where(pub_date: start_date..end_date) |
Form関係
とは書いたものの、Djangoでは明確にFormとModelは分離されているが、Railsは基本的に概念としては存在してない。
ただ、DjangoのFormの要素は、Modelを利用して表現している場合が多そう。要はValidationとかModelへの加工だったりするので、上手く色々継承して表現するっぽい。
Railsで言う所のViewを省略して書ける機能もDjangoのFormにはあるが、それはRailsにはなく、Gemを使うかHelperの何かしらを使う感じ。